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

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

Объектом исследования является структурные методы анализа и проектирования ЭИС.

Предметом исследования являются методы реализации структурного подхода к проектированию ЭИС.

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

Для достижения поставленной цели необходимо решить ряд задач:

1. Дать определение экономической информационной системы.
2. Рассмотреть жизненный цикл ЭИС.
3. Изучить структурные методы анализа и проектирования ЭИС.
4. Проанализировать программные продукты, автоматизирующие структурные методы анализа и проектирования ЭИС.

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

1.1 Определение экономической информационной системы

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

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

1. Минимизация трудозатрат при осуществлении рутинных информационных процессов и операций.
2. Устранении рутинных операций.
3. Оптимизация процессов обработки и преобразования информации.
4. Расширение возможностей осуществления статистического анализа и повышение точности учетно-отчетной информации.
5. Повышение оперативности и качественного уровня обслуживания пользователей.
6. Модернизация или полная замена элементов традиционных технологий.
7. Расширение возможностей организации и повышение эффективности использования информационных ресурсов.
8. Упрощение возможностей процессов обмена данными, участия в корпоративных и других проектах, способствующих интеграции [16].

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

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

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

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

База данных представляет собой именованную совокупность данных, которая отображает состояние объектов и их отношений в конкретной предметной области. Базой данных является совокупность размещенных в таблицах однородных данных, в которых состояния объектов системы и их отношения отображаются в рассматриваемой предметной области. Управление информационными процессами в базах данных осуществляется с помощью систем управления базами данных (СУБД) [15].

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

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

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

Процесс автоматизации информационных процессов основан на соблюдении следующих принципов:

• Окупаемости;
• Надежности;
• Гибкости;
• Безопасности;
• Дружественности;
• Соответствия стандартам.

АИС делятся на следующие типы:

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

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

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

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

Рисунок 1 – Структура АИС [10]

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

Экономические информационные системы разрабатываются для решения следующих задач:

• обработки данных;
• автоматизации офисных работ;
• поиска информации;
• управления.

Функционирование ЭИС построено на следующих принципах:

Принцип соответствия. ЭИС обеспечивает функционирование объекта с заданной степень эффективности.

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

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

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

Принцип интегральности заключается в однократном вводе информации в ЭИС и ее многократном и многоцелевом использовании.

Принцип адаптивности. ЭИС должна иметь возможность изменения своей структуры и функционирования для достижения оптимального результата при изменяющихся внешних условиях [14].

Особенностями ЭИС являются:

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

1.2 Модели жизненного цикла ЭИС

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

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

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

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

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

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

Рисунок 2. Структура каскадной модели жизненного цикла программного обеспечения [13]

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

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

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

Итерационную модель также называют моделью с промежуточным контролем или моделью с циклическим повторением фаз. Структура итерационной модели представлена на рисунке 3.

Рисунок 3. Итерационная модель жизненного цикла программного обеспечения

При использовании итерационной модели жизненного цикла разработки программного обеспечения существует возможность устранения недостатков проектирования и программирования на более поздних стадиях при частичном возврате на предыдущие стадии. При этом чем позже будет выявлена ошибка, тем дороже ее исправление. Если стоимость усилий, необходимых для обнаружения и устранения ошибок на стадии написания кода, принять за единицу, то стоимость выявления и устранения ошибки на стадии выработки требований будет в 5-10 раз меньше, а стоимость выявления и устранения ошибки на стадии сопровождения – в 20 раз больше [7].

Спиральная модель жизненного цикла программного продукта была разработана Б. Боэмом в 1988. Основу модели составляют лучшие свойства каскадной модели жизненного цикла с учетом процесса макетирования, к которым был добавлен новый элемент – анализ риска, который отсутствовал в этих моделях. Спиральная модель состоит из четырех этапов, которые представлены четырьмя квадрантами спирали. Структура спиральной модели представлена на рисунке 4 [12].

Рисунок 4 – Схема спиральной модели жизненного цикла разработки ПО

Рассмотрим этапы спиральной модели:

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

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

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

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

Представленные модели жизненного цикла программного продукта имеют отличия. Однако между ними есть одно сходство: все они содержат этап проектирования программного продукта. Значение этапа проектирования в процессе разработки программного продукта было описано в каскадной модели. Оно заключается в том, что стоимость усилий, необходимых для обнаружения и устранения ошибок на стадии выработки требований будет в 5-10 раз меньше, а стоимость выявления и устранения ошибки на стадии сопровождения – в 20 раз больше, чем на стадии кодирования. Поэтому важным становится тщательно и всесторонне описать систему на стадии проектирования.

1.3 Сущность структурных методов анализа и проектирования ЭИС

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

Характерными чертами структурных методов являются:

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

Рассмотрим принципы структурного подхода:

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

В процессе реализации методов структурного анализа и проектирования используется нотация IDEF0, которая была разработана Дугласс Роузом в 1969 году. Нотация IDEF0 представляет собой топологию описания системы в целом в виде множества взаимозависимых действий или функций [8].

Нотация IDEF0 применяется в следующих случаях:

• В процессе проектирования ЭИС на логическом уровне;
• на ранних этапах разработки проекта до моделирования процесса «как есть».

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

Рассмотрим этапы построения модели IDEF0. Сначала необходимо определить назначение модели. Границы моделирования служат обозначением ширины охвата предметной области и глубины детализации и являются логическим продолжением уже определенного назначения модели. Следующим качеством указывается предполагаемая целевая аудитория, для нужд которой создается модель. Затем необходимо определить главную функцию системы. Функции изображаются на диаграммах как поименованные прямоугольники или функциональные блоки, которые носят название глаголов или отглагольных существительных. Любой блок может быть декомпозирован на составляющие его блоки [9].

На рисунке 5 представлена схема модели в нотации IDEF0.

Рисунок 5. Схема модели IDEF0

Рассмотрим компоненты модели:

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

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

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

Также в моделях нотации IDEF0 применяются комбинированные стрелки действия:

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

2. Сравнение инструментов структурных методов анализа и проектирования ЭИС

2.1 Обзор инструментальных средств структурного подхода

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

Программный продукт «BPwin process modeler» от компании «Computer Associates» представляет собой достаточно развитое средство моделирования, которое позволяет проводить анализ, документирование и улучшение бизнес процессов. С помощью этого программного продукта можно осуществить следующие действия:

• моделирование действий в процессах;
• определение порядка выполнения действий;
• определение необходимых ресурсов для выполнения действий.

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

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

• функциональное моделирование (IDEF0);
• моделирование потока работ (IDEF3);
• моделирование потока данных (DFD).

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

Рассмотрим функциональные возможности программного продукта «BPwin»:

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

Модель бизнес-процесса, разработанная в CASE-средстве BPwin представлена на рисунке 6.

Рисунок 6. Модель процесса в CASE-средстве BPwin

Следующим CASE-средством является «Ramus Educational». Это программное обеспечение предназначено для описания бизнес-процессов предприятия с помощью нотаций IDEF0 и DFD с созданием систем классификации и кодирования. Ramus используется при реинжиниринге бизнес-процессов, внедрении процессного подхода к управлению построении систем менеджмента качества, построению систем управления знаниями и др.

К функциональным возможностям системы относятся:

1. Создание моделей бизнес-процессов в методологиях IDEF0 и DFD;
2. Создание систем классификации и кодирования предприятия с внутренними связями и связями с моделями процессов;
3. Возможность импорта/экспорта в формат IDL;
4. Формирование от четности;
5. Генерация сайта для доступа к данным проекта и др.

Интерфейс системы представлен на рисунке 7.

Рисунок 7. Интерфейс системы «Ramus Educational»

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

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

Рисунок 8. Интерфейс системы MS Visio

2.2 Разработка критериев для анализа инструментальных средств

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

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

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

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

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

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

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

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

Основным фактором при выборе инструмента для моделирования бизнес-процессов является поддержка всех нотаций структурного подхода, к которым относятся: IDEF0, IDEF3, DFD.

Также системы могут автоматизировать дополнительные функции при анализе бизнес-процессов. К таким функциям будут относиться: стоимостной анализ, диаграммы FEO, SWIM Lane, Node Tree и организационная диаграмма. Наличие этих функций не является обязательным, но помогает рассмотреть систему с разных сторон в процессе анализа и моделирования.

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

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

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

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

• 1. Простота интерфейса.
  2. Наличие русскоязычной документации.
  3. Качество русификации.
  4. Близость компании-разработчика.
  5. Поддержка системы.
  6. Стоимость системы.
  7. Поддержка нотаций.
  8. Дополнительные инструменты.
  9. Возможность групповой работы над системой.
  10. Кроссплатформенность.
  11. Возможность формирования отчета.

Анализ инструментальных средств структурного подхода

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

Таблица 1

Анализ инструментальных средств структурного подхода

Критерий	BPwin	Ramus	Visio
Простота интерфейса	5	4	5
Наличие русскоязычной документации	5	5	5
Качество русификации	5	5	5
Близость компании-разработчика	3	3	5
Поддержка системы	1	3	5
Стоимость системы	5	4	3
Поддержка нотаций	5	3	3
Дополнительные инструменты	5	2	1
Возможность групповой работы над системой	5	1	1
Возможность формирования отчета	5	3	1
Кроссплатформенность	4	5	1
Максимальный балл	55	55	55
Итого	48	38	35
Итого, %	88	69	64

На основании проведенного анализа наиболее выделенным критериям является программный продукт «BPwin process modeler». Этот программный продукт обладает простым интерфейсом, русскоязычной документацией, качественно русифицирован. Однако его разработчики больше не поддерживают этот программный продукт и находятся за рубежом. Несмотря на это, программный продукт поддерживает все нотации и обладает дополнительными возможностями в виде стоимостного анализа и ряда диаграмм (FEO, SWIM Lane, Node Tree и организационная диаграмма).

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

Одинаковое количество баллов при анализа набрали программные продукты Ramus и MS Visio. К преимуществам программного продукта Ramus относятся следующие качества:

• Эргономичность графического редактора. Ramus обладает быстрой навигацией по модели, шаблонами часто используемых типов диаграмм, возможностью отмены последних действий, «умное» поведение стрелок.
• Инструмент поддерживает неограниченное количество атрибутов различных типов.
• Инструмент обладает возможностью автоматического построения иерархических деревьев в классификаторах на основании значений атрибутов.
• Редактор отчётов поддерживает несколько вариантов настройки: упрощённую (с использованием инструментов редактора и набора ключевых слов) и расширенную (с использованием JavaScript). Шаблоны отчётов могут бытьэкспортированы и импортированы в формате файлов XML.
• Инструмент обладает кроссплатформенностью, поскольку использование технологии Java позволяет устанавливать систему под разными видами операционных систем и аппаратных платформ (MS Windows, Mac OS, Linux и т.д.).

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

ЗАКЛЮЧЕНИЕ

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

Затем было дано понятие жизненному циклу программных продуктов. Были рассмотрены модели жизненного цикла и произведен их анализ, результатом которого является вывод о том, что стоимость усилий, необходимых для обнаружения и устранения ошибок на стадии выработки требований будет в 5-10 раз меньше, а стоимость выявления и устранения ошибки на стадии сопровождения – в 20 раз больше, чем на стадии кодирования. Поэтому важным становится тщательно и всесторонне описать систему на стадии проектирования.

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

Для реализации структурного подхода разработаны инструментальные средства, наиболее используемыми из которых являются: BPwin process modeler, MS Visio и Ramus.

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

В результате анализа наиболее удовлетворяющим критериям продуктом стал BPwin Process Modeler. Этот программный продукт обладает простым интерфейсом, русскоязычной документацией, качественно русифицирован. Однако его разработчики больше не поддерживают этот программный продукт и находятся за рубежом. Несмотря на это, программный продукт поддерживает все нотации и обладает дополнительными возможностями в виде стоимостного анализа и ряда диаграмм (FEO, SWIM Lane, Node Tree и организационная диаграмма).

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

Одинаковое количество баллов при анализа набрали программные продукты Ramus и MS Visio. Эти программные продукты показали среднее соответствие выделенным критериям – 60%.

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Андерсен Бьерн. Бизнес-процессы. Инструменты совершенствования. – Москва, РИА «Стандарты и качество», 2013 г.
2. Марка Д.А., МакГоуэн К. Методология структурного анализа и проектирования. Москва, 2013 г.
3. С.В. Маклаков. BPWin и ERWin. CASE-средства разработки информационных систем. Москва: Диалог-МИФИ, 2015. 256 с
4. В.А. Ивлев, Т.В. Попова. Реорганизация деятельности предприятий: от структурной к процессной организации. Москва: «Научтехлитиздат», 2014 г., 282
5. С.В. Черемных, И.О.Семенов, В.С. Ручкин. Структурный анализ систем: IDEF-технологии. Москва: «Финансы и статистика», 2014. 208 с
6. А. Шматалюк и др. Моделирование бизнеса. Методология ARIS. Практическое руководство. Москва: «Серебряные нити», 2014 г., 327 с.
7. Август-Вильгельм Шеер, Бизнес-процессы: основные понятия, теории, методы, Москва.: Просветитель, 2013.
8. А.М. Вендров. Проектирование программного обеспечения экономических информационных систем. Москва: «Финансы и статистика», 2014 г., 347 стр.
9. А. В. Леоненков. Самоучитель UML. СПб.: БХВ-Петербург, 2014. 304 стр.
10. Гради Буч Объектно-ориентированный анализ и проектирование с примерами приложений, 3 издание, : Пер с англ. М. : ООО «И.Д. Вильямс», 2012.
11. Данилин А., Слюсаренко А. Архитектура и стратегия. «Инь» и «Янь» информационных технологий предприятия/ - М. Интернет-Университет Информационных Технологий, 2015 г.
12. Организация, ориентированная на стратегию. Как в новой бизнес-среде преуспевают организации, применяющие сбалансированную систему показателей. Дейвид П. Нортон, Роберт С. Каплан. Издательство: Олимп-Бизнес », 2004 г.
13. Новиков Д. А. Теория управления организационными системами. –М.: Московский психолого-социальный институт, 2015 г.
14. М. Робсон, Ф. Уллах. Практическое руководство по реинжинирингу бизнес-процессов. - М.: Аудит, 2014.