Главная страница
Форум
Промиздат
Опережения рынка
Архитектура отрасли
Формирование
Тенденции
Промстроительство
Нефть и песок
О стали
Компрессор - подбор и ошибки
Из истории стандартизации резьб
Соперник ксерокса - гектограф
Новые технологии производства стали
Экспорт проволоки из России
Прогрессивная технологическая оснастка
Цитадель сварки с полувековой историей
Упрочнение пружин
Способы обогрева
Назначение, структура, характеристики анализаторов
Промышленные пылесосы
Штампованные гайки из пружинной стали
Консервация САУ
Стандарты и качество
Технология производства
Водород
Выбор материала для крепежных деталей
Токарный резец в миниатюре
Производство проволоки
Адгезия резины к металлокорду
Электролитическое фосфатирование проволоки
Восстановление корпусных деталей двигателей
Новая бескислотная технология производства проката
Синие кристаллы
Автоклав
Нормирование шумов связи
Газосварочный аппарат для тугоплавких припоев
|
Главная страница / Архитектура отрасли Моделирование бизнес процессов - UML Окончание. Начало в № 6,7/2005 UML В последние годы активно развивается спецификация UML, предназначенная для описания функционирования сложных программных продуктов, основанных на объектно-ориентированных языках программирования. Хотя в рамках этой методологии рассматривается ряд диаграмм (например, Activity Diagram), которые можно использовать для описания процессов, в целом UML не применяется для описания бизнес-процессов организации. В то же время концепция UML принципиально отличается от «традиционных» технологий (в частности, от блок-схем и электронных таблиц). Вместо того чтобы иллюстрировать изолированные части процесса, UML отдает предпочтение диаграммам верхнего уровня, позволяющим разработчикам скрывать детали и концентрироваться на функциональных особенностях, а не на последовательности действий. Данный подход предоставляет возможность начать с формирования общего взгляда на приложение, детали же раскрываются позже. Язык UML предлагает набор инструментальных средств, позволяющих проводить всесторонний анализ сложных проектов как с технической точки зрения, так и с точки зрения потребностей бизнеса. Данный язык упрощает процесс проектирования, снижает его стоимость и повышает эффективность. Подход, выбранный разработчиками UML (которые создавали язык моделирования, а не язык программирования), позволяет архитекторам систем эффективно описывать классы, методы и связи между ними. UML имеет четырехуровневую архитектуру: - мета-метамодель; - метамодель; - модель; - пользовательские объекты. Пользовательские объекты определяют объекты конкретной предметной области. Модель является определенным взглядом на предметную область. В UML существуют следующие модели (каждая модель представлена соответствующим типом диаграммы): - модель вариантов использования (Use Case Model). Предназначена для описания требований к системе и подсистемам; - модель классов (Class Model). Служит для описания статической структуры системы: иерархии классов и отношений между ними; - модель взаимодействий: объекты (Collabo-ration Model) и сценарии (Sequence Model). Служит для описания механизмов взаимодействия объектов системы, реализующих ту или иную функцию; - поведенческая модель диаграммы переходов и состояний (Behavior Model). Предназначена для описания алгоритмов поведения объектов системы; - модель процессов: физическая архитектура системы (Deployment Model). Описывает распределение процессов по процессорам в физическом проекте системы; - модель программных модулей (Component Model). Описывает распределение классов и объектов системы по модулям в физическом проекте системы; - модель действий (Activity Model). Предназначена для описания алгоритмов системы (для методов классов, нескольких классов) и является вариантом поведенческой модели без сообщений. Метамодель определяет язык описания моделей. В UML метамодель описывается с помощью диагруровне мета-метамодели рассматривается классификация подходов разработки программного обеспечения (ПО). Наибольшее распространение получили два семейства методов: структурные методы проектирования программных систем и объектно-ориентированные, приобретающие все большую популярность в последние годы. Каждая из диаграмм, используемых в UML, позволяет рассматривать бизнес-процессы под определенным углом. К примеру, бизнес-пользователи при помощи данных диаграмм могут оценить основные положения бизнес-сценария и разобраться в том, кто за что отвечает. Разработчики же применяют диаграммы классов и объектов для получения точного представления о том, как встраивать данные компоненты в свой код. Диаграммы объектов и классов описывают статическое состояние элементов системы в каждый конкретный момент, показывают структуру объектов, их атрибуты и взаимные связи. Диаграммы действий отображают управляющие потоки, идущие от одного действия к другому, а диаграммы вариантов использования иллюстрируют элементы, находящиеся за пределами системы. Последовательность и взаимные связи диаграмм отражают интерактивные процессы: представлены не только объекты и классы, но и сообщения, которыми они обмениваются. Таким образом, с помощью системы можно моделировать ситуации, применяя обычную в таких случаях технологию «что, если» (what if). Диаграммы состояния используются для описания динамических объектов, часто отправляющих и принимающих сообщения. Наконец, диаграммы компонентов и развертывания предназначены для физического представления системы (в том числе исполняемых модулей, библиотек и интерфейсов). Инструментальные пакеты UML (например, комплект разработчика IBM Rational Rose) содержат инструментальные средства, позволяющие легко создавать модели UML для бизнес-процессов и генерировать код на различных языках программирования (в том числе на Java, C++ и Visual Basic). Моделирующее программное обеспечение используется и для обратного проектирования уже существующих систем. Последний вариант спецификаций UML содержит ряд улучшений, к которым относятся новые семантические конструкции, усовершенствованная организация и улучшенная читабельность документов, а также поддержка нового интерфейса XMI (XML Metadata Interchange). Блок-схемы Простейшим, но важным на практике способом описания бизнес-процессов является методика составления блок-схем. Данный подход имеет много общего с графическими языками описания алгоритмов программного обеспечения. С точки зрения методологии формирование блок-схем выполняется так же, как в нотации IDEF3, хотя в целях упрощения символы логики можно опустить. Для разработки блок-схем используют стандартные офисные программные продукты, например MS Word или Visio. Блок-схемы удобно строить на листе, располагая их вертикально. При этом справа от блок-схемы процесса остается место для описания выполняемых функций, результатов их выполнения, исполнителей, номеров входящих и исходящих документов. Опивания бизнес-процессов (IDEF, ARIS, UML, блок-схемы) разрабатывались без учета специфики конкретных вертикальных рынков. Однако необходимо отметить, что организация деятельности компании в индустрии телекоммуникаций и ИТ будет существенно отличаться, например, от организации деятельности предприятия FMCG. Поэтому на рынке представлены программные продукты, построенные на основе лучшей практики в той или иной отрасли. Так, в области телекоммуникаций подобной методологической основой по праву считается Enhanced Telecom Operations Map (eTOM). eTOM Методология eTOM (Enhanced Telecom Operations Map) была разработана некоммерческой интернациональной организацией TeleManagement Forum (TMF), созданной в целях оптимизации управления организациями в области ИТ и телекоммуникаций. TMF объединяет более 340 компаний, в том числе традиционных операторов проводной связи и относительно недавно вышедших на рынок операторов мобильной связи, разработчиков программного обеспечения и потребителей телекоммуникационных услуг. Вот уже более 13 лет TMF хорошо известна в сфере информационных и телекоммуникационных услуг. В отличие от других методологий моделирования бизнес-процессов, eTOM представляет собой скорее набор директив и лучшего опыта по организации бизнес-процессов организации. Для поставщиков услуг eTOM предлагает описание всех необходимых бизнес-процессов предприятия и анализирует их с различной степенью детализации в соответствии со значимостью того или иного процесса для бизнеса в целом. Для поставщиков программного обеспечения eTOM определяет потенциальные границы модулей программных продуктов с учетом типовых требований клиентов, необходимых функций, потоков входной и выходной информации, которые должны поддерживать разрабатываемые продукты. Согласно eTOM все бизнес-процессы разбиты на три крупные группы (см. рисунок). - Strategy, Infrastructure & Product (стратегия, инфраструктура и продукт). В данную область объединены бизнес-процессы, связанные с разработкой стратегии, обязательствами предприятия, построением инфраструктуры, разработкой и управлением продуктами, а также созданием и управлением каналов сбыта. - Operations (операции) – центральная часть всей методологии eTOM. Эта область охватывает все процессы, связанные с поддержкой и управлением обслуживания клиентов: поддержка операций, операционной готовности, управление продажами, взаимоотношениями с поставщиками / партнерами, обеспечение качества, биллинг. - Enterprise Management (управление организацией). Данная область включает основные бизнес-процессы, необходимые для поддержки деятельности любой компании: управление финансами, человеческими ресурсами, рисками и т. п. Специально для компаний, работающих в области телекоммуникаций и ИТ, выпускаются инструменты автоматизации моделирования бизнес-процессов, использующие в процессе моделирования лучшую практику методологии eTOM. Одним из таких продуктов является Casewise eTOM. Casewуемое для проектирования деятельности телекоммуникационных компаний, позволяет при помощи различных диаграмм выстраивать карту бизнес-процессов. При этом все необходимые для компании процессы описываются и разделяются на разные уровни детализации в зависимости от их важности для бизнеса. На основе ключевых параметров определяется структура бизнес-процессов и выстраивается иерархическая декомпозиция. С помощью Casewise еTOM могут быть выявлены процессы, имеющие одинаковую функциональность, устранено дублирование и ускорена разработка новых процессов. Также предоставляется возможность оценить стоимостные и производительные характеристики бизнес-процесса. Отношения с поставщиками и партнерами могут быть облегчены с помощью выявления и классифицирования бизнес-процессов, обеспечивающих такое взаимодействие. Результаты анализа бизнес-процессов компании могут быть также использованы для внутреннего реинжиниринга, сотрудничества и совместных проектов с другими провайдерами услуг. Данное решение позволяет выстроить стратегию, полностью ориентированную на интересы клиента, что в условиях насыщенного рынка является одним из ключевых факторов успеха. Структура бизнес-процессов может быть представлена как в виде графической модели, так и в виде непосредственного описания. Для представления структуры бизнес-процессов используется графическая модель и непосредственное описание структуры в виде документации. Итак, оптимизация бизнес-процессов представляет собой один из основных путей повышения эффективности деятельности телекоммуникационной компании. Для оптимизации бизнес-процессов можно использовать различные методологии и инструментальные средства автоматизации, выбор которых определяется устанавливаемыми в рамках проектов по оптимизации целями, спецификой организации (размером компании, опытом использования той или иной методологии и т. п.) и иными факторами. Однако независимо от выбора методологии и инструмента моделирования необходимо помнить, что они призваны помочь решить проблемы организации или поднять ее эффективность на новый уровень, но не являются самоцелью. Полностью с материалами статьи можно ознакомиться в печатной версии журнала Материалы предоставлены НП «ЦИПРТ» Главная страница / Архитектура отрасли |