Анализ и оценка средств реализации структурных методов анализа и проектирования экономической информационной системы

Содержание:

Введение

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

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

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

Глава 1. Анализ структурных функциональных методов проектирования информационной системы

1.1 SADT-методология

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

Процесс моделирования может быть разбит на следующие этапы:

1. Создание моделей и диаграмм.

2. Распространение документации.

3. Опрос экспертов.

4. Оценочная деятельность адекватности модели и согласие ее для последующего использования.

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

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

Таким образом, создатели решили проедать формальную форму процессу создания системы, разделив ее на нижеперечисленные этапы:

1. Проектирование – взаимодействие и определение подсистем.

2. Анализ - определение, что система будет исправно работать.

3. Тестирование – проверка работы системы.

4. Эксплуатация – использование системы.

5. Реализация – создание подсистем по отдельности и объединение их в единое целое.

6. Установка – введение системы в работу.

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

В основе SADT-методологии лежат два главных принципа.

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

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

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

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

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

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

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

Если смотреть с точки зрения модели SADT, то можно сосредоточиться на функциях системы, либо на ее объектах. Схожие модели, которые ориентированы на функции, положено называть функциональными моделями, а ориентированные на системные объекты – моделями данных.

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

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

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

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

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

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

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

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

1.2 IDEF0-методология

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

IDEF0 – графическая нотация и методология функционального моделирования, существующая для описания бизнес-процессов и их формализации. Главной особенностью IDEF0 является ее особое внимание на соподчиненность объектов.

IDEF0 рассматривает не временную последовательность логических решений (WorkFlow), а логические отношения между работами.

IDEF0 как стандарт был разработан в 1981 году департаментом ВВС США в рамках программы автоматизации промышленных предприятий. В процессе практической реализации, участники программы ICAM столкнулись с необходимостью разработки новых методов анализа процессов взаимодействия в промышленных системах. При этом кроме усовершенствованного набора функций для описания бизнес-процессов, одним из требований к новому стандарту было наличие эффективной методологии взаимодействия в рамках «аналитик-специалист». Другими словами, новый метод должен был обеспечить групповую работу над созданием модели, с непосредственным участием всех аналитиков и специалистов, занятых в рамках проекта.

В результате поиска соответствующих решений родилась методология функционального моделирования IDEF0. С 1981 года стандарт IDEF0 претерпел несколько незначительных изменений, в основном, ограничивающего характера, и последняя его редакция была выпущена в декабре 1993 года Национальным институтом по стандартам и технологиям США.

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

Рисунок 1. Модули стандарта IDEF0

в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер (рис. 1).

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

Описание методологии IDEF0 содержится в рекомендациях Р 50.1.028-2001 "Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования".

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

Методология IDEF0 может использоваться для моделирования широкого круга систем и определения требований и функций, а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции. Для уже существующих систем SADT может быть использована для анализа функций, выполняемых системой, а также для указания механизмов, посредством которых они осуществляются. Не смотря на то, что в настоящее время появляются десятки новых методологий моделирования деятельности предприятия и взглядов на её архитектуру, IDEF0 сохраняет актуальность для задач усовершенствования предприятий и организаций.

Преимущества методологии IDEF0:

1) Продолжает использоваться и рекомендуется в качестве стандарта описания деятельности предприятия и организации.

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

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

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

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

6) Влияние внешней среды предприятия или системы может быть также объектом моделирования и исследования.

7) Глобальная информатизация общества только усиливает спрос на возможности, которые обеспечиваются.

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

9) Успешное моделирование различных аспектов деятельности предприятия позволяет формально выявить и собрать требования к проектируемой системе, а затем вести разработку системы, которая удовлетворяет этим требованиям.

10) влияние внешней среды предприятия или системы может быть также объектом моделирования и исследования.

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

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

1) Создание модели группой специалистов, относящихся к различным сферам деятельности предприятия. Эта группа в терминах IDEF0 называется авторами (Authors). Построение первоначальной модели является динамическим процессом, в течение которого авторы опрашивают компетентных лиц о структуре различных процессов. На основе имеющихся положений, документов и результатов опросов создается черновик (Model Draft) модели.

2) Распространение черновика для рассмотрения, согласований и комментариев. На этой стадии происходит обсуждение черновика модели с широким спектром компетентных лиц (в терминах IDEF0- читателей) на предприятии. При этом каждая из диаграмм черновой модели письменно критикуется и комментируется, а затем передается автору. Автор, в свою очередь, также письменно соглашается с критикой или отвергает её с изложением логики принятия решения и вновь возвращает откорректированный черновик для дальнейшего рассмотрения. Этот цикл продолжается до тех пор, пока авторы и читатели не придут к единому мнению.

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

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

Стрелки в стандарте IDEF0 не показывают движение данных или последовательность событий, как на DFD- или WFD- диаграммах. Здесь они предназначены для указания данных и объектов, необходимых для осуществления данной функции, и что в результате ее реализации получается. Стрелки могут быть прямыми или ломаными. В последнем случае угол сгиба должен равняться 90°. На схеме они должны располагаться вертикально или горизонтально, но диагонали — не допускается. Концы стрелок должны касаться внешней границы блока, но не заходить за нее. Также недопустимо присоединять стрелку к углу блока, поскольку в зависимости от того, с какой стороны к блоку подходит стрелка, можно определить назначение объекта, который она представляет. В рамках данного стандарта выделяют четыре типа стрелок: входящие (вход, Input), выходящие (выход, Output), стрелки управления (управление, Control), стрелки механизма (механизм, Mechanism).

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

1. Материальный: материалы и комплектующие на входе и готовая продукция на выходе.

2. Клиентский: потенциальный клиент на входе и удовлетворенный на выходе.

3. Финансовый: на входе это обычно инвестиции, платежи клиентов (выручка), кредиты и прочие доходы; на выходе – это платежи поставщикам, налоги, платежи по кредитам и прибыль.

4. Информационный: на входе это все потоки информации о внешней среде (состояние рынка, поведение конкурентов, технологические инновации и пр.), а на выходе – это поток информации, которую компания сообщает о себе миру (вся рекламная информация, а так же все виды отчетности перед контролирующими органами).

1.3 IDEF1-методология

Метод IDEF1, разработанный Т. Рэмей (T. Ramey), также основан на подходе П. Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме.

В настоящее время на основе совершенствования методологии IDEF1 создана ее новая версия - методология IDEF1X. Она разработана с учетом таких требований, как простота изучения и возможность автоматизации. IDEF1X-диаграммы используются рядом распространенных CASE-средств (в частности, ERwin, Design/IDEF).

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

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

Связь может дополнительно определяться с помощью указания степени или мощности (количества экземпляров сущности-потомка, которое может существовать для каждого экземпляра сущности-родителя).

В IDEF1X могут быть выражены следующие мощности связей:

1) каждый экземпляр сущности-родителя может иметь ноль, один или более связанных с ним экземпляров сущности-потомка;

2) каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка;

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

4) каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка.

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

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

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

1.4 IDEF3 - методология

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

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

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

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

4. Содействовать принятию оптимальных решений при реорганизации технологических процессов.

5. Разрабатывать имитационные модели технологических процессов, по принципу "КАК БУДЕТ, ЕСЛИ..."

Существуют два типа диаграмм в стандарте IDEF3, представляющие описание одного и того же сценария технологического процесса в разных ракурсах. Диаграммы относящиеся к первому типу называются диаграммами Описания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD), а ко второму - диаграммами Состояния Объекта в и его Трансформаций Процессе (Object State Transition Network, OSTN). Предположим, требуется описать процесс окраски детали в производственном цеху на предприятии. С помощью диаграмм PFDD документируется последовательность и описание стадий обработки детали в рамках исследуемого технологического процесса. Диаграммы OSTN используются для иллюстрации трансформаций детали, которые происходят на каждой стадии обработки.

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

1.5 DFD - методология

DFD - общепринятое сокращение от англ. Data Flow Diagrams — диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ.

Диаграмма потоков данных (data flow diagram, DFD) - один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Несмотря на имеющее место в современных условиях смещение акцентов от структурного к объектно-ориентированному подходу к анализу и проектированию систем, «старинные» структурные нотации по-прежнему широко и эффективно используются как в бизнес-анализе, так и в анализе информационных систем.

Исторически сложилось так, что для описания диаграмм DFD используются две нотации - Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson), отличающиеся синтаксисом.

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

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

Кроме того, нотация DFD поддерживает понятие подсистемы - структурной компоненты разрабатываемой системы.

Нотация DFD - удобное средство для формирования контекстной диаграммы, то есть диаграммы, показывающей разрабатываемую АИС в коммуникации с внешней средой. Это - диаграмма верхнего уровня в иерархии диаграмм DFD. Ее назначение - ограничить рамки системы, определить, где заканчивается разрабатываемая система и начинается среда.

Стандарт описания бизнес-процессов DFD – Data Flow Diagram переводится как диаграмма потоков данных и используется для описания процессов верхнего уровня и для описания реально существующих в организации потоков данных.

Созданные модели потоков данных организации могут быть использованы при решении таких задач, как:

1. определение существующих хранилищ данных (текстовые документы, файлы, система управления базой данных — СУБД);

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

3. подготовка к созданию модели структуры данных организации, так называемой ERD-модели (IDEF1X);

4. выделение основных и вспомогательных бизнес-процессов организации.

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

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

Глава 2. Функциональный анализ деятельности организации

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

Помимо самого процесса продаж, к деятельности дилера также относятся:

1. работа с поставщиками;

2. обеспечение безопасности интернет ресурсов;

3. сервисное обслуживание продаваемой техники.

Рассмотрим диаграмму А0, представленную на рисунке 2. Основной деятельностью является «продажа товара». Входные данные: информация о покупателях, информация о товаре. Управляющей информацией являются закон о правах потребителей и устав магазина, управляющим механизмом – обслуживающий персонал. Выходные данные представляются в виде сопроводительной документации.

Продажа товара

Рис. 2. Диаграмма А0

Теперь проведем декомпозицию полученной диаграммы.

Деятельность «продажа товара» можно представить как последовательность следующих действий (рис. 3):

1. предподготовка;

2. оформление;

3. получение;

4. постсервис.

Рис. 3. Декомпозиция диаграммы А0

Проведем дальнейшую декомпозицию. Деятельность «предподготовка» включает следующие действия (рис. 3):

1. консультация;

2. выбор товара;

3. проверка наличия на складе.

Рис. 4. Декомпозиция деятельности «предподготовка»

Проведем декомпозицию «оформление». Деятельность «оформление» включает следующие действия (рис. 4):

1. оплата;

2. заявка на склад;

3.оформление документации.

Рис. 5. Декомпозиция деятельности «оформление»

В «получение» входят функции (рис 6):

1. передача товара;
2. оформление гарантии;
3. выдача сопроводительной документации.

Рис. 6. Декомпозиция деятельности «получение»

В «постсервис» входят функции (рис. 7):

1. проверка наличия неисправностей;

2. осуществление ремонта;

3. проверка гарантии;

4. выдача товара.

Рис. 7. Декомпозиция деятельности «постсервис».

После построения информационной модели сформируем древо целей (рис. 8)

Рис. 8. Древо целей информационной системы.

Таким образом мы рассмотрели анализ деятельности организации на рисунках и диаграммах.

Глава 3. Практическая часть

Разработка логической и физической модели начинается с проведения процесса системного моделирования для предметной области с помощью инструментальной среды CA Erwin Process Modeler.

Процесс построения информационной модели состоит из следующих шагов:

1. определение сущностей;

2. определение атрибутов сущностей;

3. задание первичных и альтернативных ключей;

4. определение зависимостей между сущностями;

5. приведение модели к требуемому уровню нормальной формы;

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

7. генерация базы данных.

CA Erwin Process Modeler создает визуальное представление (модель данных) для решаемой задачи. Это представление может использоваться для детального анализа, уточнения и распространения как части документации, необходимой в цикле разработки. Однако CA Erwin Process Modeler далеко не только инструмент для рисования. CA Erwin Process Modeler автоматически создает базу данных (таблицы, индексы, хранимые процедуры, триггеры для обеспечения ссылочной целостности и другие объекты, необходимые для управления данными).

Основные компоненты диаграммы CA Erwin Process Modeler - это сущности, атрибуты и связи. Каждая сущность является множеством подобных индивидуальных объектов, называемых экземплярами. Каждый экземпляр индивидуален и должен отличаться от всех остальных экземпляров. Построение модели данных предполагает определение сущностей и атрибутов.

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

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

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

В модели дилера продажи товара я выделил следующие сущности и атрибуты:

1. «Информация о товаре» с атрибутами: код товара, стоимость, наименование, характеристики, срок гарантии, комплектация, наличие на складе.

2. «Накладная» с атрибутами: номер накладной, код товара, дата, ФИО кассира, поставщик, количество товара.

3. «Информация о покупателе» с атрибутами: код покупателя, ФИО покупателя, паспортные данные, адрес.

4. «Гарантийный талон» с атрибутами: номер талона, код покупателя, наименование продавца, ФИО покупателя, производитель товара, срок гарантии.

5. «Чек» с атрибутами: номер чека, код товара, количество товара, сумма,

дата.

Рисунок 9. Логическая модель ИС дилер по продаже товаров.

Заключение

В данной курсовой работе мной была реализована организационная система на примере дилера по продажам товара при использовании инструментов: AllFusion Process Modeler и CA Erwin Process Modeler. Созданная система помогает осуществить полное функционирование как целой сети, так и отдельного дилера. Создание информационной системы я разделил на следующие этапы:

1) создание функциональной модели

2) создание физической и логической модели информационной системы

3) углубленной изучение предметной части.

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

Основное назначение информационной системы – это создание современной инфраструктуры для управления организацией, учреждениям или предприятием.

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

Список литературы

CA Erwin Process Modeler. (2011). Получено из Erwin Data Modeler: https://erwin.com/

IDEF0. (б.д.). Получено из Wikipedia: https://ru.wikipedia.org/wiki/IDEF0

IDEF1. (б.д.). Получено из Wikipedia: https://ru.wikipedia.org/wiki/IDEF1

IDEF3. (б.д.). Получено из Wikipedia: https://ru.wikipedia.org/wiki/IDEF3

Optima WorkFlow. (2011). Получено из Оптима: http://www.optima.ru/

А., П. (2001). Обзор информационных систем.

А.М., В. (2002). Проектирование программного обеспечения экономических информационных систем.

Б., В. Л. (б.д.). Разработка сложных программных изделий.

И.Т., Б. (2002). Современные моделирования. Санкт-Петербург: Основы.

Моделирование бизнеса и архитектура информационной системы. (2011). Получено из Interface: http:/interface.ru

Моделирование ИС. (2011). Получено из ITru: http://www.it.ru/

Управление организации. (2008). Opensys #11.