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

Содержание:

ВВЕДЕНИЕ

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

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

Проектирование информационных систем – это сложный и длительный процесс, для которого необходима слаженная работа высококвалифицированных специалистов.

Имеются данные исследований [19], отражающие основные проблемы, возникающие при разработке ИС. Главные тезисы перечислены ниже:

• всего 15–20% проектов завершаются в срок;
• 25–35% проектов заканчиваются неудачно;
• 50–60% проектов выросли в цене более чем на 90%;
• только 50–60% требований были реализованы в завершенных проектах.

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

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

В связи с обозначенной целью в работе решаются следующие задачи:

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

ГЛАВА 1. СУЩНОСТЬ СТРУКТУРНОГО ПОДХОДА К ПРОЕКТИРОВАНИЮ ЭКОНОМИЧЕСКИХ ИНФОРМАЦИОННЫХ СИСТЕМ

1.1 Экономическая информационная система: понятие и требования, предъявляемые к ней

Существует довольно много определений информационной системы. В частности, стандарт ISO/IEC 2382–1 предлагает следующее определение: «Информационная система – система обработки информации, работающая совместно с организационными ресурсами, такими как люди, технические средства и финансовые ресурсы, которые обеспечивают и распределяют информацию». [18] Имеется и такое определение: «Информационная система — взаимосвязанная совокупность средств, методов и персонала, используемых для хранения, обработки и выдачи информации в интересах достижения поставленной цели». Если обратиться к ГОСТ РВ 51987, то информационная система (ИС) предстает как «автоматизированная система, результатом функционирования которой является представление выходной информации для последующего использования». [17]

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

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

Экономическая информационная система (ЭИС) представляет собой совокупность организационных, технических, программных и информационных средств, объединённых в единую систему с целью сбора, хранения, обработки и выдачи необходимой информации, предназначенной для выполнения функций управления. [2]

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

В автоматизированных информационных системах функции управления и обработки данных частично выполняется компьютерами и частично персоналом. [1]

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

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

Отсюда следуют требования, предъявляемые к информационной системе:

• предоставление полной и достаточной информации для функционирования объекта;

• предоставление своевременной и достоверной информации

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

• экономичность, то есть разумные затраты на обработку данных, не превышающие получаемый эффект;

• адаптивность ИС к постоянно изменяющимся потребностям пользователей. [13]

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

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

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

Проектирование и анализ экономических информационных систем – довольно сложная работа, требующая высококвалифицированных специалистов и занимающая много времени. Также важно понимать, что по мере разработки ИС потребности пользователей могут меняться и уточняться, что в свою очередь создает дополнительные трудности. [10]

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

К проектированию экономических информационных систем (ЭИС) существует несколько подходов:

1. Традиционный

Данный подход основан на системном анализе предметной области и последовательном проектировании ЭИС.

1. Структурный

Структурный подход основан на функциональном моделировании систем (диаграммы IDEF0). Также структурный подход включает в себя моделирование данных и их отношений (модели ERD). Это позволяет больше автоматизировать разработку ИС вплоть до описания структур данных и их отношений. Данный пакет реализуется с помощью пакетов BPWIN и ERWIN. На сегодня структурный подход к проектированию ИС более предпочтителен в совместном использовании с технологией RAD.

1. Объектно-ориентированный

Объектно-ориентированный подход использует язык UML для описания функций, событий, данных и связей.

В данной работе будет подробно рассмотрен только структурный подход. [14]

1.3 Сущность структурного подхода к проектированию информационных систем   

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

Структурным подходом называется метод исследования системы, основанный на ее представлении в виде иерархии связанных между собой функций. Описание системы как правило начинается с общего обзора, после чего детализируется, обретая многоуровневую иерархическую структуру. [15]

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

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

Таким образом, суть структурного подхода к созданию ИС заключается в ее декомпозиции на автоматизируемые функции. Система разбивается на функциональные подсистемы, подсистемы делятся на подфункции, подфункции - на задачи. [4]

Методологии структурного анализа и проектирования предполагают представление моделей разрабатываемых систем в виде диаграмм. Прежде всего разрабатывается функциональная модель системы, которая помогает определить требования к структуре функций ИС. На данном этапе важно понимать цель создания системы, а также определить, какие функции она должна выполнять. Далее создается информационная модель в которой определяется структура и состав необходимых данных, хранимых в ИС. После этого создаются процедуры реализации функций, разрабатываются алгоритмы обработки данных и поведения ИС. Последний этап включает распределение функций по подсистемам и построение модели их распределения по узлам ИС. [3]

Для анализа сложного по структуре объекта или деятельности часто применяют системный анализ. Поскольку главной проблемой, с которой сталкиваются разработчики информационных систем, является именно сложность рассматриваемого объекта, то понимание и осмысление всей системы целиком становится невозможной задачей для одного человека. В этом случае разработчики прибегают к методу построения сложной системы из нескольких крупных частей, которые, в свою очередь, состоят из менее крупных частей – и так далее. Такой подход называется иерархической декомпозицией. [7]

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

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

При этом каждая часть системы должна иметь единый интерфейс с остальными частями. Это позволяет интегрировать отдельные части разных уровней иерархии.

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

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

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

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

• принцип абстрагирования (выявление существенных деталей системы и абстрагирование от несущественных);
• принцип непротиворечивости (элементы системы не должны находиться в противоречии друг с другом);
• принцип структурирования данных (все данные должны быть четко структурированы и организованы иерархически). [11]

ГЛАВА 2.  МЕТОДЫ И СРЕДСТВА АНАЛИЗА И ПРОЕКТИРОВАНИЯ ЭКОНОМИЧЕСКОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ

2.1 Понятие о методах проектирования информационных систем

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

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

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

• они должны комплексно рассматривать процесс проектирования по всем аспектам организации и проведения работ;
• должны быть просты в освоении;
• должны обладать совместимостью;
• должны быть применимы для разных объектов;
• должны обеспечивать экономическую эффективность и адаптивность системы. [11]

Наибольшее распространение среди средств структурного анализа и проектирования получили следующие:

• SADT (Structured Analysis and Design Technique, язык структурированного анализа и проектирования техники). Для вновь создаваемых систем SADT (в нотации IDEF0) применяется для  определения требований (будущих функций) к системе, реализующей выделенные функции. Для уже существующих ИС IDEF0 может применяться с целью анализа функций, осуществляемых системой. В IDEF0 модель представляет собой совокупность взаимосвязанных и иерархически упорядоченных диаграмм, причем вершина этой структуры предоставляет самое общее описание системы. Разбиение системы на фрагменты (функциональная декомпозиция) производится после описания системы в целом.
• DFD (Data Flow Diagrams) - диаграммы потоков данных. Диаграммы DFD предназначены для наглядного изображения работы текущего документооборота организации. Диаграммы DFD являются полезным дополнением к модели, разработанной в IDEF0.
• IDEF3. Методология моделирования IDEF3 позволяет рассматривать процессы с учетом последовательности выполняемых операций, внимание фокусируется на течении этих процессов.
• ER (Entity-Relationship Diagrams) -  диаграммы «сущность - связь», методология описания данных (IDEF1X). [3]

2.2 Методология IDEF

Методы IDEF (Integrated computer-aided manufacturing DEFinition) применяются для моделирования сложных систем, позволяют анализировать и отображать в различных разрезах модели деятельности различных сложных систем. Отображение процессов в системе, глубина и степень детализации определяется разработчиком, таким образом, полученная модель может быть детализирована в нужной степени, соответствующей потребностям. Стандарт IDEF успешно применяется в различных сферах экономики и бизнеса и является эффективным средством анализа и проектирования бизнес-процессов. [16]

Для проектирования информационных систем используются перечисленные ниже методы семейства IDEF:

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

• IDEF3 – технология сбора и документирования рабочих процессов, предоставляющая моделирование поведенческих аспектов организации или разрабатываемой системы. Технология IDEF3 позволяет анализировать и создавать сценарии, отражающие последовательность реализации функций, а также, в зависимости от выбранной степени детализации – порядок выполнения подфункций или задач. При этом есть два варианта: функции можно отразить так, как они исполняются в данный момент («как есть», AS-IS) либо «как должно быть» в условиях эксплуатации информационной системы (TO-BE);

• IDEF1X – это метод разработки реляционных баз данных, созданный на основе методологии моделирования баз данных «диаграммы сущность –связь» (метод ER–D). [3]

Принципы построения модели IDEF0

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

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

Функциональную модель IDEF0 можно наглядно представить, как набор функциональных блоков (Activity Box). Каждый из блоков представляет собой «черный ящик», имеющий входы и выходы, механизмы и управление (Рисунок 1).

Рисунок 1. Функциональный блок.

В соответствии с принципом декомпозиции, эти блоки также детализируются до нужного уровня. Наиболее значимая функция располагается в левом верхнем углу. Соединение функций между собой осуществляется с помощью стрелок и описаний блоков. Есть несколько видов стрелок и активностей, все они имеют собственное значение. [9]

Стрелки обозначаются именами существительными («норма», «план»), а блоки – глаголами, поскольку блоки описывают действия («заключить договор», «произвести отгрузку», «создать товар»).

IDEF0 ценен своей простотой и наглядностью описания бизнес-процессов. С помощью IDEF0 возможна эффективная передача информации между разработчиками, пользователями и консультантами. IDEF0 широко распространен, поэтому существует множество инструментов для работы с ним (BPWIN, ERWIN, VISIO, Business studio и другие). Поскольку IDEF0 разрабатывался для бизнес-аналитики, вполне естественно, что создавать функциональную модель с его применением просто и удобно. [16]

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

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

• количество блоков на каждом уровне декомпозиции ограничено (3–6 блоков). Верхний предел (6) вынуждает использовать иерархии декомпозиций при описании сложных объектов, а нижний (3) гарантирует, что на диаграмме достаточно деталей, и ее создание целесообразно;
• количество входящих в один функциональный блок (а также выходящих из одного функционального блока) интерфейсных дуг ограничено четырьмя;
• уникальность меток и наименований блоков (отсутствие повторяющихся названий);
• синтаксические правила для дуг и блоков;
• графическое разделение входов и управлений (позволяет определять роли данных). [11]

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

• Входящие (Input, ставят определенную задачу)
• Исходящие (Output, выводят результат деятельности)
• Управляющие (Control, направлены сверху вниз, обозначают механизм управления)
• Механизмы (Mechanism, направлены снизу вверх, обозначают, посредством чего исполняется работа)

Стрелка, входящая слева («Вход») – это информация или материал, которые будут использованы функцией для получения результата. В некоторых ситуациях функция может не иметь стрелки входа.

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

Стрелка, входящая в блок сверху («Управление») – это правила, стандарты стратегии, которыми должна руководствоваться функция. Каждый блок должен иметь хотя бы одну стрелку управления. [3]

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

Стрелка, входящая в блок снизу («Механизм») – это ресурсы, при помощи которых выполняется функция (оборудование, станки, персонал предприятия и т. д.). По усмотрению разработчика стрелки механизма могут не отображаться в модели.

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

ICOM–коды (Input-Control-Output-Mechanism) – это коды для идентификации стрелок в рамках одной диаграммы, либо всех диаграмм декомпозиции. Код ICOM имеет префикс, который соответствует типу стрелки (I, С, О, М), и уникальный порядковый номер. ICOM-коды часто используются при интеграции локальных моделей в глобальную. [11]

Еще одним важным понятием методологии IDEF0 является интерфейсная дуга (Arrow). Часто также можно встретить названия «поток» или «стрелка». Интерфейсная дуга обозначает элемент, который обрабатывается функциональным блоком либо оказывает другое воздействие на функцию, отображенную этим функциональным блоком (Рисунок 2).

Рисунок 2. Интерфейсные дуги (Arrows)

Интерфейсная дуга изображается в виде однонаправленной стрелки и должна иметь свое уникальное название (Arrow label). Данное название должно быть оборотом существительного.

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

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

Модель IDEF0 может включать четыре вида диаграмм:

• контекстная диаграмма (в каждой модели может содержаться только одна контекстная диаграмма);
• диаграммы декомпозиции;
• диаграммы дерева узлов;
• диаграммы «только для экспозиции» (FEO). [16]

Модель IDEF0 начинается с создания целостного представления системы в виде одного функционального блока с интерфейсными дугами, которые выходят за пределы рассматриваемой области. Такая диаграмма, представляющая наиболее абстрактное описание системы, называется контекстной («Top») и имеет идентификатор «А-0». Важным моментом при составлении контекстной диаграммы является необходимость четко определить, что будет входить в систему, а что нет, соответственно, что будет в дальнейшем являться компонентами системы, а что будет рассматриваться как внешнее воздействие.

В пояснении к контекстной диаграмме должна быть отмечена цель построения диаграммы («Purpose») и обозначена точка зрения («Viewpoint»), то есть должна быть определена область моделирования («Scope»).

При определении области нужно учитывать широту и глубину. Широта задает границы (то есть то, что будет рассматриваться внутри системы). Глубина определяет уровень детализации. При этом важно учитывать ограничения времени, поскольку трудоемкость создания модели увеличивается в геометрической прогрессии в зависимости от глубины декомпозиции. [11]

Определение цели разработки модели IDEF0 («Purpose») также крайне важно. Цель определяет области, на которых прежде всего необходимо фокусироваться.

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

Иногда при выборе точки зрения необходимо зафиксировать альтернативные точки зрения. Для этого предназначены диаграммы FEO (For Exposition Only). [3]

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

Функциональный блок, отображающий в контекстной диаграмме в целом, посредством декомпозиции обретает детализацию в другой диаграмме. Каждая диаграмма размещается на отдельном листе и считается единицей описания. Данная диаграмма соответствует декомпозиции второго уровня и обозначается идентификатором А1. Она включает функциональные блоки, представляющие основные подфункции блока контекстной диаграммы, и называется дочерней по отношению к нему («Child diagram»). Соответственно, все функциональные блоки, отраженные на дочерней диаграмме, называются дочерним блоком («Child Box»), а функциональный блок – родитель называется «Parent Box» по отношению к дочерней диаграмме. [11]

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

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

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

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

Диаграммы для экспозиции («For Exposition Only», FEO) создаются для отражения отдельных фрагментов модели, для отражения альтернативных точек зрения, а также для отражения функциональных деталей, демонстрация которых невозможна с использованием IDEF0. Диаграммы для экспозиции могут дополняться поясняющим текстом и не обязаны учитывать ограничения стандарта IDEF0. Диаграммы FEO не являются частью иерархической модели, но при этом могут быть ассоциированы с любой диаграммой модели.[9]

Еще один термин технологии IDEF0 - глоссарий («Glossary»). Для интерфейсных дуг подразумевается создание набора соответствующих определений, описаний, ключевых слов, которые характеризуют отображенный объект. Этот набор получил название «глоссарий». Например, для интерфейсной дуги «приказ об оплате» глоссарий может включать перечень полей соответствующего ей документа. За счет внесения дополнительной текстовой информации глоссарий качественно дополняет графический язык диаграмм. [11]

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

2.2 Методология DFD

DFD (data flow diagram) – один из важнейших инструментов структурного анализа. Относится к методологиям графического структурного анализа. В DFD отображаются внешние по отношению к системе источники данных, адресаты данных, потоки и хранилища данных. [5]

В настоящее время одной из наиболее распространенных является нотация Гейна-Сарсона.

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

Нотация DFD включает понятие подсистемы — структурного компонента проектируемой системы.

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

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

DFD сфокусирована на потоках данных, которые передаются между операциями, а также их хранении для достижения максимальной доступности и скорости ответа. [11]

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

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

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

Внешняя сущность – это материальный объект или физическое лицо, являющееся источником либо приемником информации. Это могут быть персонал, поставщики, склад и так далее. Внешние сущности в модели DFD соответствуют управлению и механизмам в контекстной диаграмме IDEF0. [11]

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

Как и в IDEF0, у каждого процесса на диаграмме DFD должен быть хотя бы один входящий и минимум один выходящий поток. Процесс должен быть запущен на выполнение через обрабатываемый или через управляющий поток данных. Каждый процесс должен завершаться определенным результатом. [9]

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

Data Flow Diagrams – удобное средство для анализа и описания информационного пространства системы. Позволяет быстро и наглядно создавать описания процессов обработки информации и документооборота в компании. Диаграммы DFD являются важным и полезным дополнением к функциональной модели бизнес-процессов предприятия, разработанной в IDEF0. [11]

2.4 Методология IDEF3

Нотация IDEF3 (Integrated DEFinition for Process Description Capture Method) - моделирование потоков работ, позволяет разобрать процесс, составляющие его операции и точки принятия решений, которые оказывают на него влияние.

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

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

• Process Flow Description Diagrams, PFDD – диаграмма описания последовательности этапов процесса
• Object State Transition Network, OSTN - диаграмма сети трансформаций состояния объекта.

В отличие от IDEF0, в нотации IDEF3 стороны прямоугольника, представляющего работу, не предназначены для привязки входов различного типа. В IDEF3 в прямоугольник может входить и выходить только одна стрелка. [16]

Как инструмент моделирования, IDEF3 фиксирует следующие детали процесса:

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

Описательные методы нотации IDEF3 позволяют:

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

Нотация IDEF3, предназначенная для описания потоков работ, при построении моделей бизнес-процессов, зачастую используется совместно с описанными выше нотациями. IDEF3 имеет прямую связь с методологией IDEF0, каждая функция которой может быть рассмотрена в виде отдельного процесса средствами IDEF3. IDEF3 позволяет работать с данными, необходимыми для анализа системы с целью выявления слабых мест в согласованности рабочих процессов во времени. [9]

2.5 CASE-средства на примере BPwin и ERwin

Термин «CASE-средства» (Computer Aided Software Engineering) обозначает программные средства, которые поддерживают все основные процессы жизненного цикла информационных систем: создание (включая анализ и формирование требований), сопровождение ИС, проектирование прикладного программного обеспечения, написание кода, тестирование ИС, документирование, управление проектом и конфигурацией и многие другие процессы. [1]

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

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

Преимущества использования CASE-технологии:

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

CASE-технологии включают в себя методы, с помощью которых на основе графической нотации создаются диаграммы, которые поддерживаются инструментальной средой. Структурная методология реализуется с помощью CASE-средств Design/IDEF, BPwin, ERwin.

Средства Design/IDEF и BPWin предназначены для создания функциональной модели, которая представляет из себя иерархически структурированное отображение функций производственной системы, а также ее связей со средой и семантики, отражающей эти функции (IDEF0, IDEF3). [9]

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

Все CASE-средства обладают следующими характеристиками:

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

Особенности CASE-средств BPwin и ERwin

Программы BPwin и ERwin были созданы фирмой Logic Works, после чего Logic Works была поглощена компанией Platinum Technology, а пакет, включающий обе эти программы, стал называться AllFusion ERwin Data Modeler. В 1999 году компания была выкуплена Computer Associates. В 2011 году появился новый пакет программных продуктов для моделирования данных, который включал: CA ERwin Data Modeler, CA ERwin Data Model Validator, CA ERwin Data Profiler и CA ERwin Data Modeler Saphir Option for ERP.

BPwin – удобный инструмент моделирования, анализа, документирования и реорганизации бизнес-процессов. Модель, созданная с помощью BPwin, позволяет документировать все важные действия, способы их реализации, необходимые ресурсы и так далее. Тем самым создается целостная картина работы предприятия. [11]

Модели бизнес-процессов являются отличным средством документирования потребностей при разработке ПО. Для разработчиков и системных аналитиков BPwin – это мощное средство моделирования процессов при разработке корпоративных информационных систем.

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

Древовидные диаграммы позволяют получить общее представление модели. При помощи FEO диаграмм можно проанализировать вариации модели, не изменяя основную модель. [9]

Несомненным достоинством BPwin является автоматизация вспомогательных задач при построении модели процесса. BPwin отслеживает

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

Отличительными чертами BPwin являются:

• интуитивно доступный графический интерфейс
• автоматизация процесса проектирования, использование подсветки для исключения распространенных ошибок при моделировании
• поддержка ссылочной целостности, что гарантирует отсутствие противоречий в отношениях между объектами
• возможность настройки сбора информации, существенной для конкретного бизнеса
• настраиваемый интерфейс электронных таблиц
• разнообразие диаграмм (контекстные, декомпозиционные, организационные диаграммы)
• поддержка диаграммы Swim Lane для визуализации и эффективной оптимизации сложных бизнес-процессов
• поддержка средств моделирования функций (IDEF0), потоков работ (IDEF3) и потоков данных (DFD).
• наличие генератора отчетов Report Template Builder, поддерживающего множество форматов
• поддержка функционально-стоимостного анализа (ABC). [11]

ERwin – CASE-средство, позволяющее создавать, сопровождать и документировать базы данных, хранилища и витрины. ERwin Data Modeler дает возможность визуализировать структуру данных, управлять данными в ходе внедрения изменений, в условиях меняющихся технологий.

Удобная графическая среда ERwin Data Modeler облегчает процесс разработки базы данных, автоматизируя сложные задачи, ускоряя тем самым разработку качественных транзакционных баз данных и хранилищ данных.

Важно отметить, что ERwin поддерживает нотацию IDEF1X.

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

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

Методология IDEF1X вместе с тем имеет важный недостаток: она не позволяет представить адекватное и полное описание предметной области, и, как следствие, не позволяет разработать эффективное приложение со строгой бизнес-логикой.

Главные особенности IDEF1X и ERwin:

• Поддержка прямого и обратного проектирования (то есть создания базы данных на основе модели и генерации модели из имеющейся базы данных) для большого количества различных СУБД
• Поддержка более 25 различных СУБД: настольные, реляционные и прочие
• Поддержка SADT, IDEF0 и IDEF3
• Автоматизация рутинных процедур
• Доступный интерфейс
• Поддержка документирования структуры базы данных
• Возможность повторного использования созданных ранее моделей и их составляющих
• Возможность совместной работы разработчиков
• Возможность переноса структуры базы данных из одной СУБД в другую. [9]

Таким образом, ERwin – не только средство проектирования, но также и инструмент разработки с возможностями автоматического создания таблиц и генерации текста хранимых процедур для основных СУБД. Технология «Complete – Compare» («Завершить – Сравнить») предоставляет возможность итеративной разработки, обеспечивая непрерывную согласованность модели с базой данных. Интеграция ERwin со всеми основными средами разработки программного обеспечения ускоряет процесс генерации модели в среду целевой СУБД. [11]

ЗАКЛЮЧЕНИЕ

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

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

Наиболее значимые различия между средствами структурного анализа и проектирования заключаются в их функциональности. Отдельные нотации имеют различные достоинства и недостатки. Простота, наглядность, отсутствие разночтений, высокая скорость разработки, поддержка коллективной работы при помощи CASE-средств – несомненные плюсы. Есть и минусы, связанные, к примеру, со сложностью получения объективного представления о бизнесе от руководителя предприятия, что в свою очередь приводит к сложностям создания полноценной модели. Также существенным недостатком структурного подхода считается привязка к организационной структуре, поскольку структура имеет свойство изменяться, что требует внесения изменений в проект ИС, и как следствие, влечет за собой дополнительные трудовые, временные и финансовые затраты.

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

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

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

Существенно ускоряет процесс анализа и проектирования информационных систем использование CASE-средств, которые также были рассмотрены в данной работе на примере BPwin и ERwin.

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1. Алешин Л.И. Руководство по изучению дисциплины «Автоматизированные информационные системы». – Москва, 2006
2. Бодров О.А., Медведев Р.Е. Предметно-ориентированные экономические информационные системы: учебник. – М.: Горячая линия – Телеком, 2013. – 243 с.
3. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – М.: Финансы и статистика, 2002. – 352 с.
4. Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем. – М.: ИУИТ, 2012. – 300 с. 
5. Калянов Г.Н. Консалтинг: от бизнес-стратегии к корпоративной информационно-управляющей системе: Учебник для вузов. 2-е изд., доп. М.: Телеком, 2011. – 210 с.
6. Калянов Г.Н. Теория и практика реорганизации бизнес-процессов. Серия «Реинжиниринг бизнеса». – М.: СИНТЕГ, 2000. – 212 с.
7. Каменнова М., Громов А., Ферапонтов М., Шматалюк А. Моделирование бизнеса. - М.: Весть-Метатехнология, 2001. – 327 с.
8. Когаловский М. Р. Перспективные технологии информационных систем. — М.: ДМК Пресс; Компания АйТи, 2003. – 288 с. 
9. Маклаков С.В. BPwin и ERwin. CASE-средства разработки информационных систем. – М.: ДИАЛОГ-МИФИ, 2001.– 304 с.
10. Малков О.Б. Проектирование экономических информационных систем: Учебное пособие для выполнения курсовой работы. – Омск: Изд-во ОмГТУ, 2003. – 88 с.
11. Методология структурного проектирования информационных систем: Монография / Н.Е. Суркова, А.В. Остроух. Красноярск: Научно-инновационный центр, 2014. –190 с.
12. Мишенин А.И. Теория экономических информационных систем. – М.: Финансы и статистика, 2007. –240 с.
13. Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем: Учебник. – М.: Финансы и статистика, 2002. –512 с.
14. Усольцев А.А. Информационные системы в экономике: Конспект лекций. Новокузнецкий филиал Томского политехнического университета, 2009. –69 с.
15. Файзрахманов В.А., Селезнев К.А. Структурно функциональный подход к проектирование ИТ и автоматизированных систем с использованием CASE-средств: Учебное пособие к практическим занятиям «Структурно функциональный подход к проектирование ИТ и автоматизированных систем с использованием CASE –средств»/ Перм. гос. тех. ун-т. –Пермь, 2005. –245с.
16. Черемных С.В., Семенов И.О., Ручкин В.С. Моделирование и анализ систем IDEF-технологии: практикум. – М.: Финансы и статистика, 2002. –192 с.
17. Российский ГОСТ РВ 51987
18. Стандарт ISO/IEC 2382-1
19. Севостьянова А.В., Макашова В.Н., Столяров А.И. Предпроектная стадия ИТ-проекта «Комплексного внедрения национального ИТ-решения электронной очереди в поликлинике» // Современные научные исследования и инновации. 2016. № 4 [Электронный ресурс]. URL: http://web.snauka.ru/issues/2016/04/66160 (дата обращения: 15.08.2017).