Реферат Схема Захмана представление архитектуры информационной системы
Работа добавлена на сайт bukvasha.net: 2015-10-28Поможем написать учебную работу
Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
от 25%
Подписываем
договор
ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ
Филиал Санкт-Петербургского государственного инженерно-экономического университета в г.Чебоксары
Кафедра инженерных наук и информационных технологий
КУРСОВОЙ ПРОЕКТ
по дисциплине «Проектирование информационных систем»
на тему:
«Схема Захмана: представление архитектуры информационной системы»
Выполнил: студент
группы 92-06
А.А.Егорченко
Руководитель:
ст. преп. А.А.Алякина
Чебоксары -2010
Оглавление
Введение………………………………………………………………..………..…..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
Приложения………..……………………………………………………………..…50
Введение
Технология создания информационных систем представляет особые требования к методикам реализации и программным инструментальным средствам, а именно:
Реализация проектов по созданию ИС из стадии анализа, проектирования, непосредственного кодирования, тестирования и сопровождения. Известно, что исправления ошибок, допущенных на предыдущей стадии, обходиться примерно в 10 раз дороже, чем на текущей, откуда следует, что наиболее критическими являются первые стадии проекта.
Проект по созданию сложной ИС не возможно реализовать в одиночку. Коллективная работа существенно отличается от индивидуальной, поэтому при реализации крупных проектов необходимо иметь средства координации и управления коллективом разработчиков.
Жизненный цикл сложной ИС сопоставим с ожидаемым временем ее эксплуатации.
Вследствие значительного жизненного цикла может оказаться, что в процессе создания системы внешние условия изменились. Обычно изменение проекта на поздних стадиях – весьма трудоемкий и дорогостоящий процесс.
На современном рынке средств разработки ИС достаточно много систем, в той или иной степени удовлетворяющих перечисленным требованиям.
Глава 1. Экономические информационные системы
1.1. Понятие и классификация ЭИС
Методологическую основу проектирования ЭИС составляет системный подход, в соответствии с которым любая система представляет собой совокупность взаимосвязанных объектов (элементов), функционирующих совместно для достижения общей цели.
Для системы характерно изменение состояний объектов, которое с течением времени происходит в результате взаимодействия объектов в различных процессах и с внешней средой. В результате такого поведения системы важно соблюдение следующих принципов:
• эмерджентности, то есть целостности системы на основе общей структуры, когда поведение отдельных объектов рассматривается с позиции функционирования всей системы;
• гомеостазиса, то есть обеспечения устойчивого функционирования системы и достижения общей цели;
• адаптивности к изменениям внешней среды и управляемости посредством воздействия на элементы системы;
• обучаемости путем изменения структуры системы в соответствии с изменением целей системы.
С позиций кибернетики процесс управления системой как направленное воздействие на элементы системы для достижения цели можно представить а виде информационного процесса, связывающего внешнюю среду, объект и систему управления. При этом внешняя среда и объект управления информируют систему управления о своем состоянии, система управления анализирует эту информацию, вырабатывает управляющее воздействие на объект управления, отвечает на возмущения внешней среды и при необходимости модифицирует цель и структуру всей системы.
Структура экономической системы (промышленного предприятия, торговой организации, коммерческого банка, государственного учреждения и т.д.) с позиций кибернетики представлена на рис. 1.1, где основные информационные потоки между внешней средой, объектом и системой управления помечены метками над стрелками ИП1, ИП2, ИПЗ, ИП4 и связаны с поддерживающей их экономической информационной системой (ЭИС).
В экономической системе объект управления представляет собой подсистему материальных элементов экономической деятельности (на промышленном предприятии: сырье и материалы, оборудование, готовая продукция, работники и др.) и хозяйственных процессов (на промышленном предприятии: основное и вспомогательное производство, снабжение, сбыт и др.).
Система управления представляет собой совокупность взаимодействующих структурных подразделений экономической системы (например, на промышленном предприятии: дирекция, финансовый, производственный, снабженческий, сбытовой и другие отделы), осуществляющих следующие функции управления:
планирование - функция, определяющая цель функционирования экономической системы на различные периоды времени(стратегическое, тактическое, оперативное планирование);
учет - функция, отображающая состояние объекта управления в результате выполнения хозяйственных процессов;
контроль - функция, с помощью которой определяется отклонение учетных данных от плановых целей и нормативов;
оперативное управление - функция, осуществляющая регулирование всех хозяйственных процессов с целью исключения возникающих отклонений в плановых и учетных данных;
анализ - функция, определяющая тенденции в работе экономической системы и резервы, которые учитываются при планировании на следующий временной период.
Рис. 1.1 Структура экономической системы
Экономическая информационная система (ЭИС) представляет собой совокупность организационных, технических, программных и информационных средств, объединенных в единую систему с целью сбора, хранения, обработки и выдачи необходимой информации, предназначенной для выполнения функций управления. ЭИС связывает объект и систему управления между собой и с внешней средой через информационные потоки:
ИШ - информационный поток из внешней среды в систему управления, который, с одной стороны, представляет поток нормативной информации, создаваемый государственными учреждениями в части законодательства, а, с другой стороны, - поток информации о конъюнктуре рынка, создаваемый конкурентами, потребителями, поставщиками;
ИП2 - информационный поток из системы управления во внешнюю среду, а именно: отчетная информация, прежде всего финансовая информация в государственные органы, инвесторам, кредиторам, потребителям; маркетинговая информация потенциальным потребителям;
ИПЗ - информационный поток из системы управления на объект управления (прямая кибернетическая связь), представляющий совокупность плановой, нормативной и распорядительной информации для осуществления хозяйственных процессов;
ИП4 - информационный поток от объекта управления в систему управления (обратная кибернетическая связь), который отражает учетную информацию о состоянии объекта управления экономической системой (сырья, материалов, денежных, энергетических, трудовых ресурсов, готовой продукции и выполненных услугах) в результате выполнения хозяйственных процессов.
ЭИС накапливает и перерабатывает поступающую учетную информацию и имеющиеся нормативы и планы в аналитическую информацию, служащую основой для прогнозирования развития экономической системы, корректировки ее целей и создания планов для нового цикла воспроизводства.
К обработке информации в ЭИС предъявляются следующие требования:
полнота и достаточность информации для реализации функций управления;
своевременность предоставления информации;
обеспечение необходимой степени достоверности информации в зависимости от уровня управления;
экономичность обработки информации: затраты на обработку данных не должны превышать получаемый эффект;
адаптивность к изменяющимся информационным потребностям пользователей.
В соответствии с характером обработки информации в ЭИС на различных уровнях управления экономической системой (оперативном, тактическом и стратегическом) выделяются следующие типы информационных систем (рис. 1.2):
· системы обработки данных (EDP)
· информационная система управления (MIS)
· система поддержки принятия решений (DSS)
Рис 1.2 Обобщенная технологическая схема жизненного цикла ЭИС
Системы обработки дачных (СОД) предназначены для учета и оперативного регулирования хозяйственных операций, подготовки стандартных документов для внешней среды (счетов, накладных, платежных поручений). Горизонт оперативного управления хозяйственными процессами составляет от одного до несколько дней и реализует регистрацию и обработку событий, например оформление и мониторинг выполнения заказов, приход и расход материальных ценностей на складе, ведение табеля учета рабочего времени и т.д. Эти задачи имеют итеративный, регулярный характер, выполняются непосредственными исполнителями хозяйственных процессов (рабочими, кладовщиками, администраторами и т.д.) и связаны с оформлением и пересылкой документов в соответствии с четко определенными алгоритмами. Результаты выполнения хозяйственных операций через экранные формы вводятся в базу данных.
Информационные системы управления (ЦСУ) ориентированы на тактический уровень управления: среднесрочное планирование, анализ и организацию работ в течение нескольких недель (месяцев), например анализ и планирование поставок, сбыта, составление производственных программ. Для данного класса задач характерны регламентированность (периодическая повторяемость) формирования результатных документов и четко определенный алгоритм решения задач, например свод заказов для формирования производственной программы и определение потребности в комплектующих деталях и материалах на основе спецификации изделий. Решение подобных задач предназначено для руководителей различных служб предприятий (отделов материально-технического снабжения и сбыта, цехов и т.д.)- Задачи решаются на основе накопленной базы оперативных данных.
Системы поддержки принятия решений (СППР) используются в основном на верхнем уровне управления (руководства фирм, предприятий, организаций), имеющего стратегическое долгосрочное значение в течение года или нескольких лет. К таким задачам относятся формирование стратегических целей, планирование привлечения ресурсов, источников финансирования, выбор места размещения предприятий и т.д. Реже задачи класса СППР решаются на тактическом уровне, например при выборе поставщиков или заключении контрактов с клиентами. Задачи СППР имеют, как правило, нерегулярный характер.
Для задач СППР свойственны недостаточность имеющейся информации, ее противоречивость и нечеткость, преобладание качественных оценок целей и ограничений, слабая формализованность алгоритмов решения. В качестве инструментов обобщения чаще всего используются средства составления аналитических отчетов произвольной формы, методы статистического анализа, экспертных оценок и систем, математического и имитационного моделирования. При этом используются базы обобщенной информации, информационные хранилища, базы знаний о правилах и моделях принятия решений.
Идеальной считается ЭИС, которая включает все три типа перечисленных информационных систем. В зависимости от охвата функций и уровней управления различают корпоративные (интегрированные) и локальные ЭИС.
Корпоративная (интегрированная) ЭИС автоматизирует все функции управления на всех уровнях управления. Такая ЭИС является многопользовательской, функционирует в распределенной вычислительной сети.
Локальная ЭИС автоматизирует отдельные функции управления на отдельных уровнях управления. Такая ЭИС может быть однопользовательской, функционирующей в отдельных подразделениях системы управления.
Одним из основных свойств ЭИС является делимость на подсистемы, которая имеет ряд достоинств с точки зрения разработки и эксплуатации ЭИС, к которым относятся:
· упрощение разработки и модернизации ЭИС в результате специализации групп проектировщиков по подсистемам;
· упрощение внедрения и поставки готовых подсистем в соответствии с очередностью выполнения работ;
· упрощение эксплуатации ЭИС вследствие специализации работников предметной области.
Обычно выделяют функциональные и обеспечивающие подсистемы. Функциональные подсистемы ЭИС информационно обслуживают определенные виды деятельности экономической системы (предприятия), характерные для структурных подразделений экономической системы и (или) функций управления. Интеграция функциональных подсистем в единую систему достигается за счет создания и функционирования обеспечивающих подсистем, таких, как информационная, программная, математическая, техническая, технологическая, организационная и правовая подсистемы.
1.2. Жизненный цикл ЭИС
Потребность в создании ЭИС может обусловливаться либо необходимостью автоматизации или модернизации существующих информационных процессов, либо необходимостью коренной реорганизации в деятельности предприятия (проведении бизнес-реинжиниринга), Потребности создания ЭИС указывают, во-первых, для достижения каких именно целей необходимо разработать систему; во-вторых, к какому моменту времени целесообразно осуществить разработку; в-третьих, какие затраты необходимо осуществить для проектирования системы.
Проектирование ЭИС - трудоемкий, длительный и динамический процесс. Технологии проектирования, применяемые в настоящее время, предполагают поэтапную разработку системы. Этапы по общности целей могут объединяться в стадии. Совокупность стадий и этапов, которые проходит ЭИС в своем развитии от момента принятия решения о создании системы до момента прекращения функционирования системы, называется жизненным циклом ЭИС.
Суть содержания жизненного цикла разработки ЭИС в различных подходах одинакова и сводится к выполнению следующих стадий:
1.Планирование и анализ требований (предпроектная стадия) -системный анализ. Исследование и анализ существующей информационной системы, определение требований к создаваемой ЭИС, оформление технико-экономического обоснования (ТЭО) и технического задания (ТЗ) на разработку ЭИС.
2.Проектирование (техническое проектирование, логическое проектирование), Разработка в соответствии со сформулированными требованиями состава автоматизируемых функций (функциональная архитектура) и состава обеспечивающих подсистем (системная архитектура), оформление технического проекта ЭИС.
3.Реализация (рабочее проектирование, физическое проектирование, программирование). Разработка и настройка программ, наполнение баз данных, создание рабочих инструкций для персонала, оформление рабочего проекта.
4.Внедрение (тестирование, опытная эксплуатация). Комплексная отладка подсистем ЭИС, обучение персонала, поэтапное внедрение ЭИС в эксплуатацию по подразделениям экономического объекта, оформление акта о приемо-сдаточных испытаниях ЭИС.
5.Эксплуатация ЭИС (сопровождение, модернизация). Сбор рекламаций и статистики о функционировании ЭИС, исправление ошибок и недоработок, оформление требований к модернизации ЭИС и ее выполнение (повторение стадий 2 - 5).
Часто второй и третий этапы объединяют в одну стадию, называемую техно-рабочим проектированием или системным синтезом. На рис. 1.3 представлена обобщенная блок-схема жизненного цикла ЭИС. Рассмотрим основное содержание стадий и этапов на представленной схеме.
Системный анализ. К основным целям процесса относится следующее:
• сформулировать потребность в новой ЭИС (идентифицировать все недостатки существующей ЭИС);
• выбрать направление и определить экономическую целесообразность проектирования ЭИС.
Системный анализ ЭИС начинается с описания и анализа функционирования рассматриваемого экономического объекта (системы) в соответствии с требованиями (целями), которые предъявляются к нему (блок 1). В результате этого этапа выявляются основные недостатки существующей ЭИС, на основе которых формулируется потребность в совершенствовании системы управления этим, объектом, и ставится задача определения экономически обоснованной необходимости автоматизации определенных функций управления (блок 2), то есть создается технико-экономическое обоснование проекта. После определения этой потребности возникает проблема выбора направлений совершенствования объекта на основе выбора программно-технических средств (блок 3). Результаты оформляются в виде технического задания на проект, в котором отражаются технические условия и требования к ЭИС, а также ограничения на ресурсы проектирования. Требования к ЭИС определяются в терминах функций, реализуемых системой, и предоставляемой ею информацией.
Системный синтез. Этот процесс предполагает:
• разработать функциональную архитектуру ЭИС, которая отражает структуру выполняемых функций;
• разработать системную архитектуру выбранного варианта ЭИС, то есть состав обеспечивающих подсистем;
• выполнить реализацию проекта.
Этап по составлению функциональной архитектуры (ФА), представляющей собой совокупность функциональных подсистем и связей между ними (блок 4), является наиболее ответственным с точки зрения качества всей последующей разработки.
Рис 1.3 Обобщенная технологическая схема жизненного цикла ЭИС
Построение системной архитектуры (СА) на основе ФА (блок 5) предполагает выделение элементов и модулей информационного, технического, программного обеспечения и других обеспечивающих подсистем, определение связей по информации и управлению между выделенными элементами и разработку технологии обработки информации.
Этап конструирования (физического проектирования системы) включает разработку инструкций пользователям и программ, создание информационного обеспечения, включая наполнение баз данных (блок 6).
Внедрение разработанного проекта (блоки 7 - 10). Процесс предполагает выполнение следующих этапов: опытное внедрение и промышленное внедрение.
Этап опытного внедрения (блок 7) заключается в проверке работоспособности элементов и модулей проекта, устранении ошибок на уровне элементов и связей между ними.
Этап сдачи в промышленную эксплуатацию (блок 9) заключается в организации проверки проекта на уровне функций и контроля соответствия его требованиям, сформулированным на стадии системного анализа.
Эксплуатация и сопровождение проекта. На этой стадии (блоки 11 и 12) выполняются этапы: эксплуатация проекта системы и модернизация проекта ЭИС.
Рассмотренная схема жизненного цикла ЭИС условно включает в свой состав только основные процессы, реальный набор которых и их разбиение на этапы и технологические операции в значительной степени зависят от выбираемой технологии проектирования, о чем более подробно будет сказано в последующих разделах данной работы.
Важной чертой жизненного цикла ЭИС является его повторяемость «системный анализ - разработка - сопровождение -системный анализ». Это соответствует представлению об ЭИС как о развивающейся, динамической системе. При первом выполнении стадии «Разработка» создается проект ЭИС, а при повторном выполнении осуществляется модификация проекта для поддержания его в актуальном состоянии.
Другой характерной чертой жизненного цикла является наличие нескольких циклов внутри схемы:
• первый цикл, включающий блоки 1 - 12, - это цикл первичного проектирования ЭИС;
• второй цикл (блоки: 7 - 8, 6 - 7) - цикл, который возникает после опытного внедрения, в результате которого выясняются частные ошибки в элементах проекта, исправляемые начиная с 6-го блока;
• третий цикл (блоки: 9 - 10,4 - 9) возникает после сдачи в промышленную эксплуатацию, когда выявляют ошибки в функциональной архитектуре системы, связанные с несоответствием проекта требованиям заказчика, по составу функциональных подсистем, составу задач и связям между ними;
• четвертый цикл (блоки: 12,5 - 12) возникает в том случае, когда требуется модификация системной архитектуры в связи с необходимостью адаптации проекта к новым условиям функционирования системы;
• пятый цикл (блоки: 12, 1 - 12) возникает, если проект системы совершенно не соответствует требованиям, предъявляемым к организационно-экономической системе ввиду того, что осуществляется моральное его старение и требуется полное перепроектирование системы.
Чтобы исключить пятый цикл и максимально уменьшить необходимость выполнения третьего и четвертого циклов, необходимо выполнять проектирование ЭИС на всех этапах первого, основного цикла разработки ЭИС в соответствии с требованиями:
• разработка ЭИС должна быть выполнена в строгом соответствии со сформулированными требованиями к создаваемой системе;
• требования к ЭИС должны адекватно соответствовать целям и задачам эффективного функционирования экономического объекта;
• созданная ЭИС должна соответствовать сформулированным требованиям на момент окончания внедрения, а не на момент начала разработки;
• внедренная ЭИС должна развиваться и адаптироваться в соответствии с постоянно изменяющимися требованиями к ЭИС. С точки зрения реализации перечисленных аспектов в технологиях проектирования ЭИС модели жизненного цикла, определяющие порядок выполнения стадий и этапов, претерпевали существенные изменения. Среди известных моделей жизненного цикла можно выделить следующие модели:
• каскадная модель (до 70-х годов) - последовательный переход на следующий этап после завершения предыдущего;
• итерационная модель (70 - 80-е годы) - с итерационными возвратами на предыдущие этапы после выполнения очередного этапа;
• спиральная модель (80 - 90-е годы) - прототипная модель, предполагающая постепенное расширение прототипа ЭИС. Каскадная модель. Для этой модели жизненного цикла характерна автоматизация отдельных несвязанных задач, не требующая выполнения информационной интеграции и совместимости, программного, технического и организационного сопряжения. В рамках решения отдельных задач каскадная модель жизненного цикла по срокам разработки и надежности оправдывала себя. Применение каскадной модели жизненного цикла к большим и сложным проектам вследствие большой длительности процесса проектирования и изменчивости требований за это время приводит к их практической нереализуемости.
Итерационная модель. Создание комплексных ЭИС предполагает проведение увязки проектных решений, получаемых при реализации отдельных задач. Подход к проектированию «снизу-вверх» обусловливает необходимость таких итерационных возвратов, когда проектные решения по отдельным задачам комплектуются в общие системные решения и при этом возникает потребность в пересмотре ранее сформулированных требований. Как правило, вследствие большого числа итераций возникают рассогласования в выполненных проектных решениях н документации. Запутанность функциональной и системной архитектуры созданной ЭИС, трудность в использовании проектной документации вызывают на стадиях внедрения и эксплуатации сразу необходимость перепроектирования всей системы. Длительный жизненный цикл разработки ЭИС заканчивается этапом внедрения, за которым начинается жизненный цикл создания новой ЭИС.
Спиральная модель. Используется подход к организации проектирования ЭИС «сверху-вниз», когда сначала определяется состав функциональных подсистем, а затем постановка отдельных задач. Соответственно сначала разрабатываются такие общесистемные вопросы, как организация интегрированной базы данных, технология сбора, передачи и накопления информации, а затем технология решения конкретных задач. В рамках комплексов задач программирование осуществляется по направлению от головных программных модулей к исполняющим отдельные функции модулям. При этом на первый план выходят вопросы взаимодействия интерфейсов программных модулей между собой и с базой данных, а на второй план - реализация алгоритмов.
В основе спиральной модели жизненного цикла лежит применение прототипной технологии или КАО-технологии (rapid application development - технологии быстрой разработки приложений) - J. Martin. rapid application development. New York: Macmillan, 1991. Согласно этой технологии ЭИС разрабатывается путем расширения программных прототипов, повторяя путь от детализации требований к детализации программного кода. Естественно, что при прототипной технологии сокращается число итераций и меньше возникает ошибок и несоответствий, которые необходимо исправлять на последующих итерациях, а само проектирование ЭИС осуществляется более быстрыми темпами, упрощается создание проектной документации. Для более точного соответствия проектной документации разработанной ЭИС все большее значение придается ведению общесистемного репозитория и использованию САSЕ-технологий (см. гл. 13).
Жизненный цикл при использовании КАО-технологии предполагает активное участие на всех этапах разработки конечных пользователей будущей системы и включает четыре основные стадии информационного инжиниринга:
• анализ и планирование информационной стратегии. Пользователи вместе со специалистами-разработчиками участвуют в идентификации проблемной области;
• проектирование. Пользователи принимают участие в техническом проектировании под руководством специалистов-разработчиков;
• конструирование. Специалисты-разработчики проектируют рабочую версию ЭИС с использованием языков 4-го поколения;
• внедрение. Специалисты-разработчики обучают пользователей работе в среде новой ЭИС.
Глава 2. Схема Захмана представление архитектуры ИС
В 1987 году Джон Захман опубликовал полезную схему развития архитектуры информационной системы. Захмановская схема создает контекст для описания различных представлений архитектуры разрабатываемой системы. Эти представления соответствуют тому, как видят систему ее заказчик, проектировщик и разработчик, причем в разрезе трех выбранных аспектов. Эти три аспекта: данные, функции и сетевая структура. В схеме Захмана строке соответствует точка зрения какого-либо участника проекта по созданию системы. Аспекты представлены в схеме колонками.
Архитектурное представление - это ячейка таблицы, соответствующая пересечению выбранного столбца и выбранной строки. Например, с точки зрения разработчика (технологическая модель) информационное архитектурное представление (данные) - это проект структуры данных. Взгляд какого-либо лица - это совокупность ячеек в пределах одной строки (точки зрения), то есть совокупность архитектурных представлений с выбранной точки зрения, соответствующая выбранным аспектам системы.
Захман определяет архитектуру как представление конечного продукта (в данном случае информационной системы) с точки зрения одного из заинтересованных лиц. Таким образом, существует не одна архитектура, а некое множество архитектур. В зависимости от того, кем вы являетесь и на каком аспекте фокусируете внимание, вы видите архитектуру системы по-разному. В следующих пяти разделах приводится более развернутое описание подхода Захмана. Изложение сделано на основе (П7).
1.1 Точки зрения
Точки зрения отражают значение и области ответственности заинтересованных лиц в процессе создания системы. Заказчик видит систему с точки зрения общих стратегических и тактических аспектов. Эти аспекты могут лежать в очень широкой области (бизнес в целом или, напротив, его часть) и не всегда могут быть определены точно. Архитектурные представления, соответствующие точке зрения заказчика, находятся в двух верхних строках таблицы. Начальное планирование бизнеса и анализ обычно определяют первые уровни детализации для этих архитектурных представлений. Определенно установленные цели бизнеса и его требования к системе полностью детализируют каждое из представлений.
Представления проектировщика, несмотря на то, что рассматривается одна и та же система, существенно отличаются от представлений заказчика, причем не только дополнительными деталями. Представления проектировщика - это проект системы, обеспечивающей удовлетворение требований, которые, в свою очередь, описываются представлениями заказчика. Во многом представление проектировщика добавляет точность, необходимую для тех, кто будет реализовывать систему, но представления проектировщика и заказчика остаются независимыми от технологий, которые будут использоваться при реализации. Структурный анализ, информационное моделирование и некоторые виды прототипирования являются методами, которые могут быть использованы для формирования архитектурного представления проектировщика. Точке зрения проектировщика соответствует третья строка в схеме Захмана.
Проекты, связанные с созданием систем, наиболее успешны, когда компоненты каждого из технологически независимых взглядов, соответствующие данным, функциям и сетевой структуре (три верхних строки) разрабатываются одновременно командой, хорошо понимающей бизнес и имеющей опыт в разработке приложений и сетей, а также в администрировании данных. Хотя каждый участник может представлять свою точку зрения (заказчик или проектировщик) или фокусироваться на своих аспектах (данные, функции или сети), каждый вносит свой набор знаний. Эти наборы знаний в совокупности дают хорошую общую картину требуемой системы. В достаточной степени проектировщики должны понимать точку зрения заказчика и наоборот. Заказчик и проектировщик не могут развивать свои взгляды независимо. Физическое воплощение логических требований зависит от характеристик аппаратно-програмной базы, выбранной для реализации системы. В отличие от желаемых логических связей, реальные связи зависят от физических ограничений. Таким образом, необходимо знать, что мы хотим, перед тем, как делать вывод о невозможности чего-либо. Технология ограничивает решения задач, а не их условия.
Технологические соображения начинают играть роль при формировании точки зрения разработчика. Взгляды заказчика и проектировщика отражают потребности бизнеса. Взгляд разработчика отражает множество решений, ограниченных технологией, временем и стоимостью. Точки зрения разработчика соответствуют четвертой и пятой строкам в схеме. Как и ранее, это не просто следующий уровень детализации взглядов проектировщика. Они представляют сдвиг точки зрения с логического уровня (требования) на физический уровень (решения).
Существует еще одна отдельная точка зрения оператора системы. Деятельность оператора - это, с одной стороны, ежедневная поддержка работоспособности системы и ее мониторинг, с другой - повседневное использование системы в бизнесе. Точка зрения оператора представлена последней строкой схемы.
Важно помнить, что строки схемы представляют разные точки зрения, а не разные уровни детальности представления. Для каждой ячейки таблицы может быть сделано многоуровневое описание. Необходимо понимать, что могут быть ситуации, в которых важно понятие взгляда, то есть совокупности архитектурных представлений, находящихся в пределах одной строки. Разным строкам соответствует разное понимание предмета. Чтобы сформировать взгляд, отражающий другую точку зрения, необходим некий переход.
1.2 Аспекты
Три аспекта, рассмотренных в схеме, приводят к различным архитектурным представлениям каждой из точек зрения. Аспекты соответствуют вопросам "что", "как" и "где", относящимся к конечному продукту (информационной системе). Каждому аспекту соответствуют разные методы формирования представления.
Колонка данных соответствует вопросу "что". В строительной промышленности, например, она соответствует списку материалов и частей, используемых при строительстве здания, и взаимосвязям между этими частями. Внимание концентрируется на том, из чего строится здание, а не как и где оно строится. Для информационных систем вопрос "что" относится к сущностям данных и их связям.
Колонка функций соответствует вопросу "как". Она описывает, как работают отдельные части системы. В информационных системах функции обычно определяются входами (элементы данных), процессами (преобразования) и выходами (элементы данных). Внимание уделяется не столько отдельным частям и их связям, сколько тому, как эти части взаимодействуют при выполнении общей задачи.
Колонка сетевой структуры соответствует вопросу "где". Архитектурные представления в этой колонке описывают местоположение элементов системы и механизмы их взаимодействия.
1.3 Названия строк и столбцов
Схема Захмана является простым, но достаточно мощным средством. Эта мощность особенно хорошо видна при попытке ее расширения. В этом разделе приведены краткие дополнительные соображения о схеме, а также некоторые моменты, о которых следует помнить при ее использовании.
Важно понимать, что схема Захмана не является каким-либо алгоритмом действий, она лишь направляет наши соображения по нужному пути. Благодаря своей простоте, схема позволяет понять, как должна быть спроектирована и разработана информационная система, не только в терминах методов проектирования и разработки, но и в терминах набора элементов системы.
При использовании схемы Захмана требуется четко представлять, что означают строки и столбцы в таблице. В каждой ячейке представлен вид конечного продукта (архитектурное представление) с точки зрения некоторой группы лиц, участвующих в разработке системы. Строки представляют их точки зрения, и хотя процесс разработки системы является последовательным выполнением действий, характерных для каждой из этих групп (от заказчика к проектировщику, от проектировщика к разработчику), Захман выступает против рассмотрения строк как уровней детальности представления.
Важное замечание по поводу архитектурных представлений состоит в том, что все они имеют различную природу. Это не просто набор представлений, уровень детальности которых увеличивается с прохождением каждого нового этапа. Уровень детальности - это независимая переменная, меняющаяся внутри каждого архитектурного представления.
Здесь используются следующие термины описания строк. Строка является точкой зрения. Точка зрения отражает область интереса или ответственности группы заинтересованных лиц. Все точки зрения относятся к одному и тому же продукту. Они согласуются с понятием взгляда заказчика, проектировщика и разработчика. Таким образом, точки зрения разных участников проектной группы различаются. Взгляд охватывает часть ячейки, всю ячейку или несколько ячеек в пределах одной строки. Взгляд может быть порожден любой точкой зрения (хотя он может быть шире или уже по размеру предметной области) и может быть представлен на любом подходящем уровне детальности. Взгляд отражает интересы конкретного участника проекта, ограниченные рамками выбранных аспектов.
1.4 Характеристика взгляда состоит из двух частей:
Описание взгляда, включающее:
- Точку зрения (статус человека, имеющего данный взгляд);
- Что показывает взгляд (аспект);
- Техника или язык, описывающий данный взгляд (например, IDEF1X для аспекта данных, IDEF0 или диаграмма потока данных для функционального аспекта);
- Уровень детальности (высокий или низкий);
- Предметную область (узкая или широкая);
- Предполагаемое использование (как будет использоваться взгляд);
- Пользователя (кто будет использовать взгляд);
- Граничные предположения (предположения по поводу интеграции этого взгляда с другими).
Управляющая информация о взгляде:
- Как был разработан взгляд;
- С кем контактировать для управления изменениями;
- Статус (насколько взгляд полон и насколько определен);
- Составные части (например, диаграммы, глоссарии, тенденции, критические для успеха факторы).
Представление предметной области подразумевает представление аспекта. В качестве аналогии рассмотрим процесс фотографирования (получения взгляда) с определенной точки зрения. Когда мы фотографируем автомобиль, пытаемся ли мы сфокусироваться на его составных частях (множестве материалов), на том, как он ездит (процесс), на его форме (связи), или мы пытаемся отразить все эти аспекты на одном о том же снимке? В фотографии, так же, как и в архитектуре, трудно дать детальное представление многих аспектов одновременно с помощью одного взгляда.
Аспект представляется колонкой таблицы. Мы связываем аспект данных с моделями данных, аспект функций с функциональными моделями и аспект сетей - с сетевыми моделями. Иными словами, мы связываем аспекты разных объектов с соответствующими объектными моделями.
Взгляд не может содержать архитектурные представления, находящиеся в разных строках, хотя он может быть шире или уже по количеству аспектов. Тем не менее, может быть произведена трансформация одного взгляда в другой. Под этим понимается преобразование взгляда с одной точки зрения во взгляд с другой точки зрения. Преобразование - это переход от одной строки к другой.
Наконец, схема Захмана является контекстом для изучения различных взглядов на одну и ту же систему. Схема поддерживает множество взглядов, отражающих разные аспекты конечного продукта. Эти взгляды важны для разных людей и созданы с их точек зрения. Схема представляет всем участникам CASE-проекта контекст для описания информационной системы на понятном и приемлемом для каждого участника языке.
1.5 Дополнение схемы
И наконец, введем еще несколько аспектов в дополнение к трем, лежащим в основе схемы Захмана. Начальный вид схемы был разработан для представления архитектуры информационной системы с учетом трех ее аспектов, так что естественно рассуждать о том, что произойдет с названиями и описаниями столбцов и строк, когда количество аспектов будет увеличено.
До сих пор мы рассматривали информационную систему, ориентированную на полную автоматизацию, в то время как на самом деле в систему поддержки бизнеса могут входить ручные процедуры, описание и смысл которых должны отражаться в архитектурных представлениях. Поэтому естественно попытаться дополнить схему Захмана аспектами, соответствующими вопросам "кто", "когда" и "почему".
Наилучшим решением было бы использование для столбцов названий "что", "как", "где", "кто", "когда" и "почему", но даже такая схема не будет универсальной. Потеря универсальности может быть большей или меньшей в зависимости от того, насколько конкретный смысл мы вкладываем в каждый из аспектов.
Расширение схемы требует некоторого пересмотра названий строк. Предметная область и моделирование бизнеса остаются в первых двух строках. Если мы определим систему как частично автоматизированную, частично ручную, модель информационной системы трансформируется в модель системы вообще. Поскольку учитываются человеческие и другие ресурсы, технологическая модель становится моделью распределения ресурсов. Детальное представление сохраняет название.
Название нижней строки таблицы может варьироваться. Если можно определить одну или несколько точек зрения (например, точку зрения оператора системы), которые будут сильно отличаться от точек зрения проектировщика, разработчика или владельца, то название "функционирование системы" является вполне уместным.
Выбор хороших названий для столбцов и строк является более важной проблемой, чем может показаться с первого взгляда. Одна из сильнейших сторон захмановской схемы это то, что в ней используются аналогии, а также термины, знакомые различным категориям пользователей (заказчики, проектировщики, разработчики).
1.6 Замечания о полноте.
При использовании схемы в качестве вспомогательного инструмента необходимо понимать, полностью ли покрывает рассматриваемая схема все архитектурные представления системы. Другими словами, требуется четкое понимание того, все ли аспекты системы покрываются множеством аспектов схемы. Если схема полна, добавление столбца должно выразиться в удалении из всех остальных столбцов аспектов системы, затрагиваемых новым столбцом. Например, если мы добавляем столбец "правила", то все, что касается правил, должно быть исключено из других столбцов; другие столбцы должны быть переопределены, чтобы избежать дублирования информации.
С другой стороны, представляется разумным дополнять схему всякий раз, когда без особых затруднений можно сопоставить некоторому аспекту системы в точности одну колонку схемы.
1.7 Интеграция схемы Захмана с методами моделирования бизнеса.
Выше мы рассмотрели два подхода к моделированию потребностей бизнеса, необходимому для разработки поддерживающей бизнес информационной системы. В каждом из подходов предполагается использование упомянутых выше технологий моделирования. Рассмотрим различия этих подходов.
В подходе Баркера ИС развивается со временем, в процессе последовательного прохождения различных этапов жизненного цикла системы. Каждому этапу приписан набор методик, обязательных или необязательных для использования.
В подходе Захмана не делается акцент на динамике развития ИС. При переходе от одной строки таблицы к другой меняется лишь точка зрения, с которой рассматривается система, причем эта точка зрения не обязана быть связана с уровнем детальности рассмотрения. В схеме Захмана отражены три аспекта системы, приблизительно соответствующие некоторым методикам моделирования (информационное моделирование, диаграмма потоков данных и т.д.).
Представляет интерес составить схему, аналогичную схеме Захмана, в которой в качестве аспектов при формировании архитектурных представлений используется хотя бы часть методик, представленных на диаграмме Баркера. Три основные части диаграммы: функциональное моделирование, информационное моделирование и событийное моделирование. Их пересечения - диаграммы потоков данных, анализ состояний, информационная динамика и функциональная логика.
Рис.2. Инструментальные средства.
Каждая из перечисленных на Рис. 2 методик, кроме последней, имеет программную поддержку. Семейство методологий IDEF является альтернативой использования некоторых средств Oracle CASE*Method. Прочерк в строке, соответствующей методике CM, указывает на отсутствие методологических стандартов. Эта методика используется в различных проектах в зависимости от ситуации. Схема применения методики создается в организации, выполняющей заказ по созданию системы, на основе накопленного опыта работы. Построим теперь схему Захмана, основанную на семи перечисленных аспектах и различных точках зрения (рис. П8 и П9)
Использование интегрированной схемы даст возможность применять ее на всех этапах жизненного цикла системы для формирования точек зрения всех участников CASE проекта, причем каждый участник или группа участников проекта получат четкое представление о том, что от них требуется. Предложенная схема, так же, как и схема Захмана не является немедленным руководством к действию. Ее назначение состоит в том, чтобы обеспечить понимание архитектуры информационной системы на разных стадиях разработки и с точки зрения разных участников проекта.
Глава 3. Разработка модели бизнес-процессов организации в среде BPwin
На начальных этапах автоматизации бизнес-процесса необходимо понять, как работает организация, как организован процесс, который нужно автоматизировать. Для описания работы предприятия необходимо построить модель. Такая модель должна быть адекватна предметной области, следовательно, она должна содержать в себе знания всех участников бизнес-процессов организации.
Все это позволяет осуществить CASE-средство BPwin.
В данном курсовом проекте мы рассматриваем деятельность отдела компьютерной фирмы (далее ОКФ), занимающегося гарантийным обслуживанием компьютерной техники и комплектующих.
Рассматриваемый нами ОКФ осуществляет следующие операции:
1. обслуживание клиентов;
2. гарантийный и платный ремонт;
3. замена товара;
Каждая из этих операций является бизнес-процессом и детализирует основную деятельность ОКФ.
Основным входом модели являются поступающие заявки от клиентов. Именно этот факт вызывает начало выполнения основных процессов. Помимо этого входом является заказ деталей, которые необходимы для осуществления ремонта, но которых может не оказаться на складе.
При выполнении процессов используются ресурсы. Основные ресурсы модели – это персонал отдела, необходимый для осуществления ремонта и тестирования инструментарий, детали и зап.части имеющиеся на складе.
В качестве управляющего воздействия выступают нормативные документы по ремонту компьютерной техники и оказанию услуг.
Выходом модели являются выполненные операции.
2.1 Построение модели бизнес-процесса в нотации IDEF0
Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм.
Основанием модели является контекстная диаграмма, абстрактно описывающая диаграмму в целом (рис. 3.1).
Рис.3 Контекстная диаграмма
Далее я декомпозировал деятельность предприятия на четыре бизнес – процесса, а именно: прием неисправной техники, ведение ремонтных работ, тестирование и выдача техники клиенту, склад. Графическое изображение представлено на рис. 3.2.
Рис. 3.1 Декомпозиция контекстной диаграммы
| Название работ | Описание |
| Прием КТ | Прием заявок от клиентов |
| Склад | Заказ, поиск и хранение деталей, а также компьютерной техники |
| Ведение ремонтных работ | Выявление неполадки, осуществление ремонта и замены детали, также замена товара по гарантийным обязательствам |
| Тестирование и выдача техники клиенту | Проверка работоспособности отремонтированной техники и выдача ее клиенту,в случае если она удовлетворяет запросам клиента. |
Далее подробно рассматривается декомпозиция работы «Ведение ремонтных работ» (рис. 3.3), остальные диаграммы декомпозиции в приложениях. Данная диаграмма содержит в себе : выявление поломки, ремонт поломки, замена деталей и возврат производителю.
Рис. 3.2 Декомпозиция работы «Ведение ремонтных работ»
| Название работ | Описание |
| Выявление поломки | Определяется наличие поломок в технике ,а также причина ее возникновения |
| Ремонт техники | Осуществление ремонта техники |
| Замена деталей | В случае полного отказа какой-либо детали происходит ее замена |
| Возврат производителю | Отправка техники производителю в том случае если товар бракованный |
Далее декомпозируем работу «Ремонт техники » (рис. 3.4).
Рис. 3.3 Диаграмма «Ремонт техники»
| Название работ | Описание |
| Ремонт системных плат | Ремонт материнских плат, плат ОЗУ и HDD |
| Ремонт мониторов | Ремонт экранов, корпусов,электро-проводки |
| Ремонт оргтехники | Ремонт принтеров,сканеров,копировальных устройств и т.д. |
| Ремонт прочих компьютерных устройств | Компьютерные мыши,клавиатуры,блоки питания,модемы |
Далее подробнее рассмотрим работу «Ремонт прочих компьютерных устройств» (Рис. 3.5.), т.к. для ремонта используются разное оборудование и технологии.
Рис. 3.4 Диаграмма «Ремонт прочих компьютерных устройств»
2.2 Построение диаграммы узлов и FEO диаграммы
При помощи диаграммы дерева узлов показана вся деятельность отдела компьютерной фирмы, занимающегося гарантийным обслуживанием компьютерной техники(Рис. 3.6).
Рис. 3.5 Дерево узлов
В качестве FEO-диаграммы я выбрал диаграмму декомпозиции блока «ремонтная деятельность» (рис. 3.7). Данная диаграмма отражает альтернативный взгляд на процесс осуществления ремонтной деятельности.
Рис. 3.6 FEO-диаграмма
2.3 Построение IDEF3 диаграммы
В нотации IDEF3 я описал прием неисправной техники (Рис. 3.8.).
При приеме заявки необходима контактная информация о клиенте, после определяется какой вид работ будет производится: гарантийный или платный. Далее происходит идентификация неполадки, затем клиента уведомляют с условиями выбора, а именно: отправить технику на ремонт или вернуть обратно.
Рис. 3.7 IDEF3 диаграмма «Прием неисправной техники»
2.4 Построение DFD-диаграммы
Диаграммы потоков данных используются для описания документооборота и обработки информации. В виде DFD-диаграммы я решил изобразить работы по оформлению и ведению складских операций.
На рис. П 3.1 изображена диаграмма «Склад». На ней размещены четыре работы:
- «Поиск детали». Данная работа выполняется при приеме заявки на деталь;
- «Прием деталей». Здесь отображается весь товар, который предлагают поставщики или заказывают на складе;
- «Выдача деталей». Тут происходит прием необходимых деталей для ремонта.
- «Хранение отремонтированной техники и деталей». Здесь учитываются все выданные и принятые детали, а также прием и выдача отремонтированной техники.
В результате на выходе мы получаем базу данных «Выдача детали» и «Списание со склада КТ и подготовка к тесту».
2.5 Стоимостной анализ
Стоимостный анализ представляет собой соглашение об учете, используемое для сбора затрат, связанных с работами, с целью определить общую стоимость процесса.
С помощью стоимостного анализа можно решить такие задачи, как определение действительной стоимости производства продукта, поддержки клиента.
Основные статьи расходов описаны в таблице 3.1.
| Статья затрат | Определение |
| Детали | Затраты на закупку материалов, деталей и комплектующих |
| Персонал отдела | Затраты на оплату работ сотрудников отдела |
| Управление | Затраты на управленческую деятельность, такую как организация работ, соблюдение всех правил проведения ремонта и техники безопасности |
| Инструменты | Затраты на покупку или использование инструментов в ремонтной деятельности отдела |
Таблица 3.1. Статьи затрат бизнес-процесса
Затраты 1 месяца работы отдела гарантийного обслуживания в рублях отображены в таблице (П 4.1.)
Оценив стоимость всех работ я получил следующие цифры.
Основная деятельность обходится в 5329200,00 рублей. Эта сумма распределяется между статьями затрат следующим образом:
1. осуществление деятельности – 3449000,00 рублей;
2. персонал – 223850,00 рублей;
3. управление – 55 800,00 рублей.
Самой дорогостоящей операцией является основное занятие отдела –ремонт компьютерной техники, так как здесь использовано больше всего инструментов, а также задействована большая часть персонала.
2.6 Реинжиниринг бизнес-процесса
После составления модели «как есть» она анализируется и выявляются недостатки, которые предполагается исправить, построив модель «как должно быть».
Исходя из этого я решил добавить еще одну услугу,которая бует являться скорее дополнительной, нежели одной из основных. Эта услуга будет называться «Сбор компьютеров». Результатом этой работы является сборка дорогих игровых компьютеров, сборка дешевых офисных компьютеров, сборка компьютеров для учебных заведений (рис. 3.9). Таким образом при небольших затратах появляется ощутимая прибыль.
Рис. 3.8 модель TO-BE
Декомпозировав данную модель, получаем следующее (Рис. 3.10.)
Рис. 3.9 «Сборка компьютеров»
Соответственно после этого диаграмма дерева узлов изменяется, она представлена в (П.1).
Глава 4. Разработка информационной модели организации в среде Erwin
Erwin используется для построения модели данных, и имеет два уровня представления – логический и физический. На логическом уровне данные представляются так, как они выглядят в реальном мире (рис. П5.1). Физический уровень данных – это отображение системного каталога, который зависит от конкретной реализации СУБД (рис. П5.2).
Далее я опишу, как взаимодействуют сущности на диаграмме отдела гарантийного обслуживания в компьютерной фирме.
Каждый сотрудник выполняет ту или иную работу. Существуют администратор, мастера и директор.
При подаче клиентом заявки она сразу же выполняется при условии, что все необходимые ресурсы имеются в наличии, если какой либо детали нет, то сразу оформляется заказ на ее поставку.
4.1 Проектирование логической модели базы данных
Логическая модель данных основана на сущностях и их атрибутах.
Описание сущностей и атрибутов логической модели приведено ниже (таблицы 4.1 – 4.7).
| Атрибут | Описание атрибута | РК | FК |
| ID Мастера | Идентификационный номер работника | Да | Нет |
| ФИО | ФИО | Нет | Нет |
| | e-mail работника | Нет | Нет |
| Телефон | Номер телефона сотрудника | Нет | Нет |
Таблица 1. Сущность «Мастера»
| Атрибут | Описание атрибута | РК | FК |
| ID поставщика | Идентификационный номер поставщика | Да | Нет |
| Наименование фирмы | Наименование фирмы | Нет | Нет |
| Телефон | Телефон фирмы | Нет | Нет |
| Адрес | Адрес фирмы | Нет | Нет |
| Эл. почта | Адрес электронной почты | | |
Таблица 2. Сущность «Поставщики»
| Атрибут | Описание атрибута | РК | FК |
| ID клиента | Идентификационный номер клиента | Да | Нет |
| ФИО | ФИО клиента | Нет | Нет |
| Телефон | Телефон клиента | Нет | Нет |
| | Электронный адрес клиента | | |
| Адрес | Адрес клиента | Нет | Нет |
Таблица 3. Сущность «Клиент»
| Атрибут | Описание атрибута | РК | FК |
| ID детали | Идентификационный номер детали | Да | Да |
| Количество | Количество деталей | Нет | Нет |
| Название | Название деталей | Нет | Нет |
| Цена | Цена детали | Нет | Нет |
Таблица 4. Сущность «Склад»
| Атрибут | Описание атрибута | РК | FК |
| ID заказа | Идентификационный номер детали | Да | Нет |
| ID детали | Идентификационный номер детали | Нет | Да |
| ID поставщика | Идентификационный номер поставщика | Нет | Да |
| Название | Наименование детали | Нет | Нет |
| Количество | Количество деталей заказа | Нет | Нет |
| Цена | Цена продажи | Нет | Нет |
Таблица 5. Сущность «Заказ детали»
| Атрибут | Описание атрибута | РК | FК |
| ID мастера | Идентификационный номер мастера | Да | Нет |
| ID клиента | Идентификационный номер клиента | Нет | Да |
| ID заявки | Идентификационный номер заявки | Нет | Да |
| ID детали | Идентификационный номер детали | Нет | Да |
| Цена | Стоимость работ | Нет | Нет |
| Наименование | Наименование проводимых работ | Нет | Нет |
Таблица 6. Сущность «Ремонт»
Заключение
Работая с большим количеством информации, которая ,как правило, добытая из разных источников, всегда есть потребность в ее организации. Для координации всех этих данных необходимы определённые знания и организационные навыки. Что, собственно, содержат в себе BPWin и ERWin.
BPWin -дает возможность наглядно представить любую деятельность или структуру в виде модели, что позволит оптимизировать работу организации, проверить ее на соответствие стандартам ISO9000, спроектировать оргструктуру, снизить издержки, исключить ненужные операции, повысить гибкость и эффективность. Являясь стандартом де-факто, BPwin поддерживает сразу три нотации моделирования: IDEF0 (федеральный стандарт США), IDEF3 и DFD. ERWin - CASE-средство для проектирования и документирования баз данных, которое позволяет создавать, документировать и сопровождать базы данных, хранилища и витрины данных. Модели данных помогают визуализировать структуру данных, обеспечивая эффективный процесс организации, управления и администрирования таких аспектов деятельности предприятия, как уровень сложности данных, технологий баз данных и среды развертывания.
С их помощью данном проекте была спроектирована функциональная структура компьютерной фирмы, вернее одного из отделов- гарантийного обслуживания. Был использован стоимостной анализ, отображены диаграммы узлов, а также FEO, DFD и IDEF3 диаграммы. И для получения большей прибыли, был произведен реинжениринг бизнес процессов.
Подытоживает проект, спроектированные логическая и физическая модель базы данных в ERWin.
Список использованной литературы
1. Смирнова Г. Н. Проектирование экономических информационных систем / Москва Финансы и статистика, 2003 – 511с.
2. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных: Учебник / под ред. А.Д. Хомоненко. – СПб.: КОРОНА-Век, 2009. – 736с.;
3. Емельянова Н.З. Проектирование информационных систем: Учебное пособие / Н.З. Емельянова, П.Л. Партыка, И.И. Попов. – М.: ФОРУМ, 2009. – 432с.;
4. Маклаков С.В. Моделирование бизнес-процессов BPwin 4.0. - Москва: ДИАЛОГМИФИ, 2002. – 218с.;
5. Маклаков С.В. BPwin и ERwin: CASE-средства для разработки информационных систем;
6. Пущин М.Н. Проектирование информационных систем: Учебное пособие. – М.: Изд-во МИЭТ, 2008. – 234с.;
7. Танаев В.М., Карнаух И.И. Восьмая нота менеджмента или бизнес как он есть на самом деле: Практическое руководство по эффективному использованию человеческого ресурса в бизнесе, 2002 – 396с.;
8. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – М.: Финансы и статистика. – 2004;
9. www.intuit.ru;
10. www.betec.ru;
11. www.sql.ru;
12. www.twirpx.com.
13. www.citforum.ru
14. www.eduworld.ru
15. www.inftech.ru
16. http://inter-solar.ru
Приложения
Приложение 1
Рис. П. 1. Диаграмма древа узлов
Приложение 2
Рис. П 2.1. IDEF3-диаграмма «Замена деталей»
Рис. П 2.2. IDEF3-диаграмма «Тестирование и выдача техники клиенту»
Приложение 3
Рис. П3. DFD-диаграмма «Склад»
Приложение 4
Таблица П4. Стоимостной анализ
| Activity Name | Activity Cost (RUS\Рубль) | Cost Center | Cost Center Cost (RUS\Рубль) | |
| Деятельность отдела сервисного обслуживания КТ | 3 728 650,00 | Детали | 1 450 000,00 | |
| Инструменты | 1 999 000,00 | |||
| Персонал отдела | 223 850,00 | |||
| Управление | 55 800,00 | |||
| Прием неисправной техники | 17 300,00 | Инструменты | 8 800,00 | |
| | Персонал отдела | 5 850,00 | ||
| | Управление | 2 650,00 | ||
| Реквизиты клиента | 350 | Персонал отдела | 150 | |
| | Управление | 200 | ||
| Прием заявки | 6 950,00 | Инструменты | 6 500,00 | |
| | Персонал отдела | 200 | ||
| | Управление | 250 | ||
| Ремонт за счет клиента | 350 | Персонал отдела | 150 | |
| | Управление | 200 | ||
| Ремонт по гарантии | 350 | Персонал отдела | 150 | |
| | Управление | 200 | ||
| Определние поломки | 3 500,00 | Инструменты | 1 000,00 | |
| | Персонал отдела | 1 500,00 | ||
| | Управление | 1 000,00 | ||
| Уведомить клиента | 1 500,00 | Инструменты | 1 300,00 | |
| | Персонал отдела | 100 | ||
| | Управление | 100 | ||
| Отправить в ремонт | 2 150,00 | Персонал отдела | 1 800,00 | |
| | Управление | 350 | ||
| Вернуть клиенту | 2 150,00 | Персонал отдела | 1 800,00 | |
| | Управление | 350 | ||
| Склад | 1 034 700,00 | Детали | 1 000 000,00 | |
| | Инструменты | 20 200,00 | ||
| | Персонал отдела | 8 500,00 | ||
| | Управление | 6 000,00 | ||
| Прием деталей | 507 000,00 | Детали | 500 000,00 | |
| | Инструменты | 3 500,00 | ||
| | Персонал отдела | 2 000,00 | ||
| | Управление | 1 500,00 | ||
| Поиск деталей | 11 000,00 | Инструменты | 7 500,00 | |
| | Персонал отдела | 2 000,00 | ||
| | Управление | 1 500,00 | ||
| Хранение отремонтированной КТ и деталей | 513 900,00 | Детали | 500 000,00 | |
| | Инструменты | 8 900,00 | ||
| | Персонал отдела | 3 000,00 | ||
| | Управление | 2 000,00 | ||
| Выдача деталей | 2 800,00 | Инструменты | 300 | |
| | Персонал отдела | 1 500,00 | ||
| | Управление | 1 000,00 | ||
| Ведение ремонтных работ | 2 093 500,00 | Детали | 450 000,00 | |
| | Инструменты | 1 400 000,00 | ||
| | Персонал отдела | 200 000,00 | ||
| | Управление | 43 500,00 | ||
| Выявление поломки | 57 000,00 | Инструменты | 50 000,00 | |
| | Персонал отдела | 5 000,00 | ||
| | Управление | 2 000,00 | ||
| Ремонт техники | 1 665 000,00 | Детали | 450 000,00 | |
| | Инструменты | 1 050 000,00 | ||
| | Персонал отдела | 110 000,00 | ||
| | Управление | 55 000,00 | ||
| Ремонт системных плат | 720 600,00 | Детали | 450 000,00 | |
| | Инструменты | 200 000,00 | ||
| | Персонал отдела | 45 000,00 | ||
| | Управление | 25 600,00 | ||
| Ремонт мониторов | 300 000,00 | Детали | 210 000,00 | |
| | Инструменты | 45 000,00 | ||
| | Персонал отдела | 30 000,00 | ||
| | Управление | 15 000,00 | ||
| Ремонт принтеров,сканеров, копировальных устройств | 424 000,00 | Детали | 300 000,00 | |
| | Инструменты | 88 000,00 | ||
| | Персонал отдела | 22 000,00 | ||
| | Управление | 14 000,00 | ||
| Ремонт прочих компьютерных устройств | 220 400,00 | Детали | 140 000,00 | |
| | Инструменты | 40 000,00 | ||
| | Персонал отдела | 30 400,00 | ||
| | Управление | 10 000,00 | ||
| Ремонт компьютерных мышей | 49 400,00 | Детали | 30 000,00 | |
| | Инструменты | 15 000,00 | ||
| | Персонал отдела | 3 400,00 | ||
| | Управление | 1 000,00 | ||
| Настройка или ремонт модемов | 51 700,00 | Детали | 35 000,00 | |
| | Инструменты | 10 000,00 | ||
| | Персонал отдела | 5 600,00 | ||
| | Управление | 1 100,00 | ||
| Ремонт клавиатур | 44 500,00 | Детали | 28 500,00 | |
| | Инструменты | 11 000,00 | ||
| | Персонал отдела | 3 600,00 | ||
| | Управление | 1 400,00 | ||
| Ремонт БП | 74 800,00 | Детали | 42 000,00 | |
| | Инструменты | 12 000,00 | ||
| | Персонал отдела | 15 800,00 | ||
| | Управление | 5 000,00 | ||
| Возврат производителю | 6 500,00 | Персонал отдела | 5 500,00 | |
| | Управление | 1 000,00 | ||
| Замена деталей | 365 000,00 | Детали | 70 000,00 | |
| | Инструменты | 250 000,00 | ||
| | Персонал отдела | 30 000,00 | ||
| | Управление | 15 000,00 | ||
| Заявка на деталь | 2 000,00 | Персонал отдела | 1 500,00 | |
| | Управление | 500 | ||
| Заменяемая деталь | 17 500,00 | Детали | 15 000,00 | |
| | Персонал отдела | 1 500,00 | ||
| | Управление | 1 000,00 | ||
| Нерабочая КТ | 2 000,00 | Персонал отдела | 1 500,00 | |
| | Управление | 500 | ||
| Замена детали | 338 700,00 | Инструменты | 320 000,00 | |
| | Персонал отдела | 10 000,00 | ||
| | Управление | 8 700,00 | ||
| Тестирование детали | 3 000,00 | Персонал отдела | 2 000,00 | |
| | Управление | 1 000,00 | ||
| Удалить деталь | 1 800,00 | Персонал отдела | 1 500,00 | |
| | Управление | 300 | ||
| Тестирование и выдача техники клиенту | 583 150,00 | Инструменты | 570 000,00 | |
| | Персонал отдела | 9 500,00 | ||
| | Управление | 3 650,00 | ||
| Оповещение клиента | 600 | Персонал отдела | 500 | |
| | Управление | 100 | ||
| По e-mail | 250 | Персонал отдела | 150 | |
| | Управление | 100 | ||
| По телефону | 250 | Персонал отдела | 150 | |
| | Управление | 100 | ||
| Ознакомление с правилами проведения ремонтных работ | 350 | Персонал отдела | 200 | |
| | Управление | 150 | ||
| Тестирование КТ (производительность) | 183 000,00 | Инструменты | 180 000,00 | |
| | Персонал отдела | 2 000,00 | ||
| | Управление | 1 000,00 | ||
| Тестирование КТ (работоспособность) | 395 000,00 | Инструменты | 390 000,00 | |
| | Персонал отдела | 3 500,00 | ||
| | Управление | 1 500,00 | ||
| Оценка работы | 3 000,00 | Персонал отдела | 2 000,00 | |
| | Управление | 1 000,00 | ||
| Отправка на повторный ремонт | 600 | Персонал отдела | 500 | |
| | Управление | 100 | ||
| Выдача КТ клиенту | 600 | Персонал отдела | 500 | |
| | Управление | 100 | ||
| Оплата работы | 0 | | |
Приложение 5
Рис. П5.1. Логическая модель магазина в Erwin
Рис. П5.2. Физическая модель магазина в Erwin
Приложение 6
Рис.П6.1 Схема базы данных в Access
Рис.П6.2 Обратное проектирование
Приложение 7
Рис. П7. Схема Захмана.
Приложение 8
Рис.П8. Интегрированная схема архитектуры информационной системы, первые три столбца.
Приложение 9
Рисунок 4. Интегрированная схема архитектуры информационной системы ( Окончание )
