(495) 925-0049, ITShop интернет-магазин 229-0436, Учебный Центр 925-0049
  Главная страница Карта сайта Контакты
Поиск
Вход
Регистрация
Рассылки сайта
 
 
 
 
 

Rational Rose, BPwin и другие - аспект анализа бизнес-процессов

Источник: iteam
Павел Сахаров,

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

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

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

В последнее время для целей анализа деятельности предприятий все большее распространение получает средство моделирования IBM Rational Rose компании Rational Software. Подтверждение этому факту легко найти в Internet, проанализировав требования, которые формулируют различные компании к кандидатам на ИТ-вакансии. В большинстве случаев в состав требований обязательно включается знание Rational Rose и унифицированного языка моделирования (UML), на котором оно основано.

Кроме того, часто приходится слышать и читать, что UML и Rational Rose являются универсальными средствами, которые вполне подходят и для моделирования бизнес-процессов.

Так, на сайте компании "Интерфейс Ltd" (партнера фирмы Rational Software) приводятся следующие слова вице-президента Rational Роджера Оберга: "Rational Rose стала стандартом при разработке приложений и бизнес-моделировании." (пресс-релиз от 03.04.2000, http://www.interface.ru/fset.asp?Url=/chapters/news.htm )

Там же среди новостей от 29 мая 2000 года опубликовано следующее сообщение: "Корпорация Rational Software объявила о выходе Rational Rose 2000е - новой версии CASE-средства визуального проектирования информационных систем, позволяющего моделировать как компоненты программного обеспечения, так и бизнес-процессы" ( http://www.interface.ru/fset.asp?Url= /chapters/news.htm ).

Там же опубликована статья Александра Новичкова "Эффективная разработка программного обеспечения с использованием технологий и инструментов компании Rational", в конце которой приводится рекомендация: "Есть смысл приобретать AnalystStudio для проведения бизнес-моделирования. Для данных целей набор содержит все необходимое". Напомню, что AnalystStudio - набор продуктов фирмы Rational Software, рекомендованный аналитикам и включающий в себя Rational Rose как основной продукт, и Rational Unified Process, Rational Requisite PRO, Rational ClearQuest и Rational SoDA как дополнительные.

По мнению автора, предложение использовать IBM Rational Rose в такой неоправданно широкой области - серьезное заблуждение. Во всяком случае, на российском рынке CASE-средств давно присутствуют и успешно используются инструменты, существенно лучше реализующие потребности аналитика при описании и анализе деятельности предприятия.

Ниже приводится попытка сравнения некоторых характеристик и особенностей описания бизнес-процессов, реализованных в программном продукте Rational Rose фирмы Rational Software и продуктах, основанных на методологии IDEF0, наиболее распространенным из которых на российском рынке является CA ERwin Process Modeler (BPwin) 7.3 корпорации Computer Associates .

Выбор для сравнения с Rational Rose продуктов, основанных на методологии IDEF0, обуславливается не желанием автора доказать, что IDEF0 не имеет достойных конкурентов. Существуют и другие методики, вполне пригодные для анализа деятельности предприятий и описания бизнес-процессов. Задачей данной статьи является обоснование точки зрения автора, что существуют CASE-средства (хотя бы одно!), подходящие для целей анализа гораздо лучше, чем Rational Rose. Выбор же IDEF0 обусловлен лишь тем, что автор давно и плодотворно работает именно с IDEF0 и поэтому хорошо знаком с возможностями этой методологии и соответствующих программных средств.

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

Что дает использование средств моделирования и методологии IDEF0

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

  1. Процесс (Activity) изображается прямоугольником.
  2. Стрелки слева (Input) отображают необходимые для исполнения процесса входы.
  3. Стрелки справа (Output) отображают результаты исполнения процесса (выходы).
  4. Стрелки снизу (Mechanism) отображают необходимые для исполнения процесса механизмы, то есть те объекты, которые собственно и исполняют данный процесс. Например: оператор, рабочий, автоматизированная система предприятия и т. п.
  5. Стрелки сверху (Control) отображают объекты, диктующие правила исполнения процесса, но непосредственно для исполнения процесса не необходимые. Это могут быть статьи КЗОТ и/или инструкция по технике безопасности для процесса изготовления детали рабочим, работающим на станке, или инструкция Банка России и/или тот же КЗОТ для процесса оформления платежа банковским работником.
  6. Стрелки могут разветвляться и сливаться, тем самым образуя иерархию данных.
  7. При декомпозиции процесса все стрелки, входящие или исходящие из него, должны быть перенесены на диаграмму нижнего уровня и использованы при ее построении. При этом запрещены всякие новые стрелки, выходящие за пределы новой диаграммы, кроме специальных, так называемых "туннельных" стрелок.

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

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

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

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

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

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

Что предлагает Rational Rose

IBM Rational Rose  не поддерживает ни одну из известных методологий моделирования и анализа бизнес-процессов. Методика построения так называемых "бизнес-моделей", содержащаяся в дополнительном наборе рекомендаций или методике RUP, которая сопровождает пакет Rational Rose, предлагает диаграммы Use Case и Activity для описания бизнес-процессов. Однако автор убежден, что эти диаграммы позволяют описать лишь малую часть сведений, которые нужны для моделирования бизнес-процессов и которые представляются средствами IDEF0. Кроме того, дуги Use Case и Activity диаграмм не имеют тех смысловых типов, которые были указаны для дуг IDEF0. По мнению автора, некие синтаксические соглашения, диктуемые системой при разработке Use Case и Activity-диаграмм, не объединены в законченную и понятную систему; этим диаграммам (что, наверное, главное) не дается никакой интерпретации, объясняющей, как их применять при моделировании. Действительно, что означает, что два процесса соединены стрелкой - просто последовательность их исполнения или, например, то, что второй процесс обрабатывает некоторые (какие?) результаты деятельности первого, а может быть, наоборот, для работы первого процесса необходима некая (какая?) информация, которую подготавливает второй? Точно так же непонятно, как интерпретировать связи "процесс-состояние", "состояние-состояние" и др.

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


Пример синтаксически корректной, но не поддающейся осмысленному объяснению Activity-диаграммы

По этим причинам пользователям Rational Rose при разработке Use Case и Activity-диаграмм приходится придумывать свои оригинальные синтаксические соглашения и давать свою интерпретацию имеющимся, чтобы отразить всю существенную для анализируемого процесса информацию. Например, чтобы имитировать три вида характерных для IDEF0 входящих в процесс стрелок - input, mechanism, control, - можно каждую из них подкрашивать своим цветом, а для того, чтобы отличить входящие документы от исходящих, можно использовать пунктирные и сплошные стрелки. Другими словами, пользователь Rational Rose вынужден разрабатывать свои формализмы для получения методики построения моделей и анализа бизнес-процессов. При этом, возможно, придется не только разрабатывать свою методику, но и отклоняться от стандартов UML. Зачем это делать, если существует апробированная и признанная во всем мире IDEF0 (а также другие вполне подходящие стандарты, средства и языки, например IDEF3), а на преимуществах стандартного подхода я здесь просто не буду останавливаться.

Даже если удастся придумать, как реализовать в Rational Rose соглашения IDEF0, или разработать свою методологию анализа бизнес-процессов, не уступающую IDEF0 и органично реализуемую в Rational Rose, то система все равно не научится "читать" разработанные модели, так как это в ней не заложено изначально, а следовательно, обработка и анализ моделей будут целиком на плечах аналитика. Или же придется разрабатывать свои процедуры выдачи отчетов, которые будут ориентированы на отсутствующие в стандартном UML (но имеющиеся в IDEF0) синтаксические соглашения. Но и это еще не все, поскольку не будет решена задача поддержки и контроля синтаксиса для разработанной пользователем методологии, и, следовательно, не будет никакой гарантии корректности разработанной модели.

Заключение

Из всего вышесказанного следует только один вывод: CASE-средства, реализованные на основе методологии IDEF0 и поддерживающие ее соглашения, уже только благодаря этому имеют неоспоримые и решающие преимущества перед Rational Rose. (Аналогичную оценку преимущества перед Rational Rose можно дать и системам, основанным на стандарте IDEF3, и ряду других.) Поэтому при необходимости проведения работ, где анализ бизнес-процессов играет важнейшую роль, выбор в качестве средства моделирования продуктов фирмы Rational Software, на взгляд автора, является серьезной ошибкой.

Литература

  1. Дэвид А. Маркa, Клемент Макгоуэн. Методология структурного анализа и проектирования (SADT). http://acdwp.narod.ru/ruk1.htm , http://zareg.newmail.ru/prteoria.htm

Ссылки по теме


 Распечатать »
 Правила публикации »
  Написать редактору 
 Рекомендовать » Дата публикации: 29.10.2009 
 

Магазин программного обеспечения   WWW.ITSHOP.RU
Rational ClearCase Multisite Floating User License
erwin Data Modeler Workgroup Edition r9.7 - Product plus 1 Year Enterprise Maintenance Commercial
IBM RATIONAL Clearcase Floating User License + Sw Subscription & Support 12 Months
IBM RATIONAL Rose Enterprise Floating User License + Sw Subscription & Support 12 Months
Rational ClearQuest Floating User License
 
Другие предложения...
 
Курсы обучения   WWW.ITSHOP.RU
 
Другие предложения...
 
Магазин сертификационных экзаменов   WWW.ITSHOP.RU
 
Другие предложения...
 
3D Принтеры | 3D Печать   WWW.ITSHOP.RU
 
Другие предложения...
 
Новости по теме
 
Рассылки Subscribe.ru
Информационные технологии: CASE, RAD, ERP, OLAP
Безопасность компьютерных сетей и защита информации
Новости ITShop.ru - ПО, книги, документация, курсы обучения
CASE-технологии
Мир OLAP и Business Intelligence: новости, статьи, обзоры
Работа в Windows и новости компании Microsoft
Новые программы для Windows
 
Статьи по теме
 
Новинки каталога Download
 
Исходники
 
Документация
 
 



    
rambler's top100 Rambler's Top100