Методологии моделирования проблемной области

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

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

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

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

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

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

· понятность для заказчиков и разработчиков на основе применения графических средств отображения модели;

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

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

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

Структурный аспект функционирования ЭИС предполагает построение:

· объектной структуры, отражающей состав взаимодействующих в процессах материальных и информационных объектов предметной области;

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

· структуры управления, отражающей события и бизнес-правила, которые воздействуют на выполнение процессов;

· организационной структуры, отражающей взаимодействие организационных единиц предприятия и персонала в процессах;

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

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

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

· понятность для заказчиков и разработчиков на основе применения графических средств отображения модели;

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

Структурный аспект функционирования ЭИС предполагает построение:

· структуры управления, отражающей события и бизнес-правила, которые воздействуют на выполнение процессов;

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

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

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

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

· время решения задач;

· стоимостные затраты на обработку данных;

· надежность процессов;

· косвенные показатели эффективности, такие, как объемы производства, производительность труда, оборачиваемость капитала, рентабельность и т.д.

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

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

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

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

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

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

Рассмотрим особенности построения моделей проблемной области на трех уровнях детализации.

Объектная структура

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

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

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

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

Функциональная структура

Функция (операция) представляет собой некоторый преобразователь входных объектов в выходные. Последовательность взаимосвязанных по входам и выходам функций составляет бизнес-процесс. Функция бизнес-процесса может порождать объекты любой природы (материальные, денежные, информационные). Причем бизнес-процессы и информационные процессы, как правило, неразрывны, то есть функции материального процесса не могут осуществляться без информационной поддержки. Например, функция отгрузки готовой продукции осуществляется на основе документа «Заказ», который, в свою очередь, порождает документ «Накладная», сопровождающий партию отгруженного товара.

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

На внешнем уровне моделирования определяется список основных бизнес-функций или видов бизнес-процессов. Обычно таких функций насчитывается 15-20.

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

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

Структура управления

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

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

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

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

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

Организационная структура

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

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

На концептуальном уровне для каждого подразделения задается организационно-штатная структура должностей (ролей персонала).

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

Техническая структура

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

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

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

На внутреннем уровне строится модель «клиент-серверной» архитектуры вычислительной сети.

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

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

В функциональных моделях (DFD-диаграммах потоков данных, SADT-диаграммах) главными структурными компонентами являются функции (операции, действия, работы), которые на диаграммах связываются между собой потоками объектов (подробное изложение структурного функционально-ориентированного подхода изложено в гл. 13).

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

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

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

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

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

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

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

Для объектно-ориентированного подхода разработаны графические методы моделирования проблемной области, обобщенные в языке унифицированного моделирования UML [89] (подробное описание объектно-ориентированного подхода представлено в гл. 13). Однако по наглядности представления модели пользователю-заказчику объектно-ориентированные модели явно уступают функциональным моделям.

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

В полной мере комбинированный подход к моделированию проблемной области реализован в инструментальном средстве ARIS-Toolset (Architecture of Integrated Information Systems), содержащем множество различных методологий, соответствующих различным взглядам на проектируемую систему: объекты, функции, организационная структура [46].

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

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

В качестве метода построения интегрированной модели бизнес-процессов используется метод, основанный на управлении событиями (ЕРС - event-driven process chain method), который предполагает зависимость выполнения операций (функций) процесса от происходящих событий (рис. 11.3).

Рис. 11.3. ЕРС-модели бизнес-процесса

При этом все операции процесса четко определены по входу и выходу, а также исполнителям по организационной структуре и техническим средствам. В ЕРС-модели однозначно определяется характер разветвления и соединения путей модели через логические связки X (AND, OR, XOR). От ЕРС-модели можно переходить в дальнейшем как к функционально-ориентированному, так и к объектно-ориентированному программированию системы.

Вопросы для самопроверки

1. Что такое бизнес-процесс и чем управление бизнес-процессами отличается от управления ресурсами?

2. Что такое реинжиниринг бизнес-процессов и чем он отличается от концепции всеобщего управления качеством?

3. Какие задачи решает реинжиниринг бизнес-процессов?

4. Какие требования предъявляются к корпоративной ЭИС?

5. Какие изменения архитектуры КЭИС способствуют реинжинирингу бизнес-процессов?

6. Назовите основные принципы реинжиниринга бизнес-процессов.

7. Каковы основные этапы РБП?

8. Как изменяется модель жизненного цикла ЭИС в связи с РБП?

9. Какие классы инструментальных программных средств используются на различных этапах РБП?

10. Что понимается под моделью проблемной области?

11. Какие требования предъявляются к модели проблемной области?

12. В каких аспектах осуществляется моделирование проблемной области?

13. Какие существуют уровни моделирования проблемной области?

14. Что включает структурный уровень представления модели проблемной области?

15. Какие критерии используются для оценки модели проблемной области?

16. Какие существуют подходы к построению структурных моделей проблемной области на различных уровнях представления?