Содержание


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

Comments

Индустрия здравоохранения представляет собой, вероятно, самую сложную отрасль для внедрения решений в области информационных технологий (ИТ). Причиной этого является сама природа сложных бизнес-процессов здравоохранения, замысловатых медицинских данных, гетерогенных компонентов и фрагментированных программных систем. Бизнес по предоставлению качественных медицинских услуг требует, чтобы решения четко соответствовали бизнес-целям организации, а ИТ-системы обладали высокой степенью интеграции и гибкости для следования динамичным изменениям бизнеса. Для решения этих проблем, как правило, прекрасным подходом является сервис-ориентированная архитектура (Service Oriented Architecture - SOA). Однако вопрос, каким образом организация реализует полное внедрение и развертывание, остается открытым.

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

Проблемы здравоохранения

Глобальной задачей здравоохранения является повышение эффективности работы и снижение затрат при одновременном улучшении качества обслуживания. Рынок здравоохранения стал сложнее, и с момента выхода на него общепринятых сегодня технологий ,нужды и процессы бизнеса сильно изменились. Большинство организаций индустрии здравоохранения обладают разрозненными ИТ-системами и компонентами, которые не сообщаются между собой. Например, доктора в системе амбулаторного обслуживания не могут получить доступ к данным о пациентах в системе стационара, пост медсестер не может эффективно получить полные данные о больных из клиники амбулаторного лечения, и практически все отделы функционируют как закрытые бункеры, которые не намерены работать совместно с другими подразделениями. Это приводит к проблемам с использованием разрозненных систем оплаты, а медицинские страховые требования хранятся в нескольких устаревших системах, к которым нелегко получить доступ и которые неудобны для совместного использования. Такой тип среды сильно снижает продуктивность и эффективность работы медицинских организаций по предоставлению качественных услуг пациентам. Для решения этих проблем требуется разработка и внедрение решений на базе сервис-ориентированной архитектуры (SOA). Индустрия здравоохранения очень медленно перенимает информационные технологии, которые могут революционизировать качество, продуктивность и производительность во многих других отраслях. Причиной этого феномена является огромный разрыв между сферами и бизнеса и ИТ. Бизнес-процессы здравоохранения почти всегда очень сложны, и создание четкой двусторонней связи между профессионалами медицины и ИТ является непростой задачей.

Разработка, стимулированная бизнесом: что это такое и зачем это нужно?

Разработка, стимулированная бизнесом (Business-driven development - BDD) представляет собой сквозной подход к разработке программного обеспечения (ПО), управляемый нуждами бизнеса. BDD обеспечивает быструю разработку и размещение гибких решений, которые удовлетворяют бизнес-требованиям и требуют меньше затрат. Это средство претворения SOA в реальность.

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

  • Управление требованиями (IBM Rational® RequisitePro);
  • Моделирование бизнес-процессов (IBM WebSphere® Business Modeler);
  • Проектирование и разработка архитектуры (Rational Software Architect, Rational Applicaiton Developer);
  • Интеграция процессов (WebSphere Integration Developer и исполняемая среда);
  • Тестирование (средства тестирования Rational);
  • Мониторинг (WebSphere Business Monitor).

На рисунке 1 показан типичный жизненный цикл BDD, а также основные инструментальные средства IBM и их место в представлении компании IBM о SOA Foundation:

Рисунок 1. BDD с ПО IBM поддерживает SOA
BDD с ПО IBM поддерживает SOA
BDD с ПО IBM поддерживает SOA

Разработка, стимулированная бизнесом, представляет собой ролевой бизнес-процесс для разработки SOA-решений. Сбор требований и документирование бизнес-процессов осуществляет бизнес-аналитик. Затем итоговые модели процессов и артефакты могут быть переданы для последующей разработки и внедрения: архитектору для системного проектирования, Java-разработчику для разработки, специалисту по интеграции для хореографии процесса разработки и развертывания, а также инженеру по обеспечению качества для тестирования. Интегрированная программная платформа IBM обеспечивает выполнение каждой роли в среде для совместной работы, что показано на рисунке 2 .

Рисунок 2. Процесс разработки, стимулированной бизнесом, с основными ролями, которые поддерживаются ПО компании IBM
Процесс разработки, стимулированной бизнесом, с основными ролями, которые поддерживаются ПО компании IBM
Процесс разработки, стимулированной бизнесом, с основными ролями, которые поддерживаются ПО компании IBM

Следует заметить, что данная статья лишь демонстрирует основные программные средства от IBM, которые можно использовать в жизненном цикле SOA.

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

Бизнес-сценарий - процесс амбулаторного ухода

Госпиталь в Нью-Йорке хотел преобразовать свой процесс амбулаторного ухода из системы на основе бумажных медицинских записей в систему электронных медицинских записей (electronic medical record - EMR). Это помогло бы улучшить уход за пациентами, обеспечить эффективность работы и, в конце концов, увеличить прибыль. Однако для принятия решения о внедрении EMR перед организационным комитетом возникли некоторые барьеры. Благодаря разработке бизнес-примера с использованием управления бизнес-процессами в BDD в качестве отправной точки, предложение по EMR было принято организационным комитетом единогласно.

В последующих разделах будет показано, как применять BDD-подход к разработке SOA-решения с использованием процесса "Подготовка визита" (Visit Preparation) в процессе амбулаторного обслуживания.

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

Управление требованиями и оптимизация бизнес-процесса

Госпиталь, со специалистами которого я разговаривал два года назад, в результате своей основной инициативы под названием Health Information Systems (HIS) уже получил полную медицинскую информационную систему, которая представляла собой интегрированную информационную систему, к которой имели доступ доктора, медсестры, фармацевты и администраторы. Год спустя, во время разговора с руководителем отдела ИТ этого госпиталя, я с удивлением узнал, что они собираются переделать всю внедренную ранее систему, поскольку она не поддерживает нужд бизнеса. К сожалению, согласно отчету компании Standish Group, если Вы имеете в производстве четыре ИТ-проекта, три из них в конце концов ожидает схожая судьба. Лишь 28% проектов успешны, хотя американские компании тратят ежегодно более 275 долл. США. на реализацию примерно 200 тыс. проектов по созданию прикладного ПО. Дополнительную информацию можно найти в разделе Ресурсы .

Для того чтобы разрабатываемая информационная система соответствовала бизнес-требованиям организации, еще до вложений средств в разработку кода процесс BDD начинается со сбора требований и анализа бизнес-процесса. В разбираемом случае амбулаторного ухода мы провели интервью со всеми заинтересованными сторонами и задокументировали все ожидания, проблемы, а также вопросы и возможности. Для сбора и организации этой информации по отношению к бизнес-задачам, бизнес-вопросам и возможностям (нефункциональные требования), а также примерам бизнес-использования и использования системы, применялось ПО IBM Rational® RequisitePro. С помощью RequisitePro эти требования были структурированы, проанализированы, и между ними были расставлены приоритеты. Каждое требование было сопоставлено с бизнес-задачами организации, как показано на рисунке 3 и рисунке 4 . Одновременно они были сопоставлены с техническими возможностями и, в свою очередь, четко связаны с продуктами и решениями, как показано на рисунке 5. Например, требование автоматизации задач докторов и медсестер по уменьшению ручной обработки данных было соотнесено с бизнес-целью по повышению эффективности работы, которой был поставлен высокий приоритет, и одновременно это было соотнесено с техническими возможностями совместной работы, а затем связано с решением IBM Workplace Collaboration Services. ПО RequisitePro предоставило специалистам по принятию решений логичное и взаимосвязанное представление, а также, что важнее всего, возможность отслеживать требования, показанные на рисунке 6.

Рисунок 3. Бизнес-требования, собранные в Rational RequisitePro, с приоритетами, статусом и другими важными атрибутами
Бизнес-требования, собранные в Rational RequisitePro, с приоритетами, статусом и другими важными атрибутами
Бизнес-требования, собранные в Rational RequisitePro, с приоритетами, статусом и другими важными атрибутами
Рисунок 4. Требования соотнесены с техническими возможностями
Требования соотнесены с техническими возможностями
Требования соотнесены с техническими возможностями
Рисунок 5. Требования заказчика связаны со средствами
Требования заказчика связаны со средствами
Требования заказчика связаны со средствами
Рисунок 6. Линии от бизнес-задач к нефункциональным требованиям, возможностям ИТ и средствам в RequisitePro
Линии от бизнес-задач к нефункциональным требованиям, возможностям ИТ и средствам в RequisitePro
Линии от бизнес-задач к нефункциональным требованиям, возможностям ИТ и средствам в RequisitePro

Преимущество использования RequisitePro для управления формальными требованиями на ранней стадии проекта заключается в возможности для бизнес-специалистов, менеджеров, экспертов в различных областях знаний и ИТ-специалистов консолидировать и связывать свои бизнес-представления. Кроме того, это направляет следующий этап проектирования и разработки системы в совместную среду для снижения проектных рисков. Исследование Мансурова и Проберта показало, что если увеличить время, затраченное на этапе управлению требованиями, с 3% до 20%, общее время выпуска продукта на рынок сократится на 30-50%, как показано на рисунке 7.

Рисунок 7. Лучшее управление требованиями сокращает время вывода продукта на рынок
Лучшее управление требованиями сокращает время вывода продукта на рынок
Лучшее управление требованиями сокращает время вывода продукта на рынок

Моделирование бизнес-процессов для перепроектирования процесса

Анализ бизнес-процессов является ключевым для проектирования SOA-решения, которое действительно удовлетворяет бизнес-целям. Записывать и анализировать бизнес-процессы помогает ПО WebSphere Process Modeler.

Прежде всего, существующий основанный на бумажных технологиях процесс амбулаторного ухода (процесс "как есть") был зафиксирован и сымитирован в WebSphere Business Modeler, как показано на рисунке 8. Затем результаты этого моделирования были проанализированы на предмет "узких мест", идентификации сервисов, и определены показатели производительности. Анализ процесса выявил, например, что затребование бумажных медицинских карт из соответствующего подразделения было наиболее затратным по времени и наименее рентабельным процессом. При переходе к EMR этот этап можно исключить. Кроме того, проверка страховки была идентифицирована как услуга, которая может быть предоставлена страховыми компаниями. И более того, благодаря совместному клиническому порталу с единым механизмом регистрации, используемому в качестве центральной платформы для всеобъемлющего представления истории болезни пациента, доктор сэкономит время на ненужных дополнительных задачах и сможет уделить пациенту больше времени. На базе анализа существующего процесса, основанного на бумажных технологиях, и бизнес-требований был представлен переработанный процесс EMR (процесс "как он должен быть") , как можно видеть на рисунке 9. И наконец, сравнили результаты моделирования процессов "как есть" и "как должно быть", что показано на рисунке 10. Как видно, процесс EMR на рисунке 8 и в таблице 1 гораздо более эффективен, чем бумажный процесс. Например, время на подготовку визита сократилось с 30 минут до менее чем 6 минут, что видно на рисунке 10.

Рисунок 8. Существующий процесс амбулаторного ухода на базе бумажных технологий, смоделированный в WebSphere Business Modeler
Существующий процесс амбулаторного ухода на базе бумажных технологий, смоделированный в WebSphere Business Modeler
Существующий процесс амбулаторного ухода на базе бумажных технологий, смоделированный в WebSphere Business Modeler
Рисунок 9. Предложенный процесс амбулаторного ухода на базе системы EMR, смоделированный в WebSphere Business Modeler
Предложенный процесс амбулаторного ухода на базе системы EMR, смоделированный в WebSphere Business Modeler
Предложенный процесс амбулаторного ухода на базе системы EMR, смоделированный в WebSphere Business Modeler
Рисунок 10. Сравнение длительности процесса подготовки визита на базе бумажных технологий и системы EMR
Сравнение длительности процесса подготовки визита на базе бумажных технологий и системы EMR
Сравнение длительности процесса подготовки визита на базе бумажных технологий и системы EMR
Таблица 1. Моделирование сравнения результатов процессов на базе бумажных технологий и EMR
КритерииБумажные технологииEMR
Время цикла30 мин.5,6 мин.
Стоимость цикла$12,47$0,79
Вероятность утери данных50%0%
Ресурсная стоимость медицинской документации$12,470%
Ресурсная стоимость регистрационной стойки$4,80$0,77

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

Моделирование бизнес-процесса для рабочей реализации

В дополнение к фиксации бизнес-процесса для анализа, другим преимуществом моделирования процесса является упрощение проектирования и разработки системы. Благодаря преобразованию бизнес-спецификаций в ИТ-спецификации, ПО WebSphere Business Modeler позволяет легко передать задачу от бизнес-специалистов в ИТ. Прежде всего, на этапе проектирования архитектуры ПО/решения модель процесса преобразуется в унифицированный язык моделирования (Unified Modeling Language - UML). Это делается ИТ-архитектором с помощью ПО Rational Software Architect, а затем разработчики для написания кода будут использовать Rational Application Developer. Во-вторых, модель процесса преобразуется в исполняемый язык бизнес-процессов (Business Process Executable Language - BPEL) и передается специалисту по интеграции для хореографии процесса разработки. Кроме того, в модели определяется главный индекс производительности (key performance index - KPI), который может использоваться для контроля над исполнением процесса с помощью WebSphere Business Monitor и его последующего улучшения.

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

  • Создание условий для ветвления выходных артефактов. Эти условия необходимы при переводе бизнес-модели в BPEL-диаграмму, которую может разработчик интеграции использовать для хореографии процесса разработки. Без определения этих условий BPEL-диаграмма не будет полной и будет переведена с ошибками;
  • Бизнес-элементы необходимо определять на более детальном уровне с атрибутами. Когда модель процесса переносится в Rational Software Architect и Rational Application Developer, такие бизнес-элементы, как медицинская карта пациента (Patient Medical Record), будут переведены в соответствующие Java-™ объекты с атрибутами. Что составляет элемент Patient Medical Record, должно определяться экспертом в предметной области в ПО Modeler, чтобы эта информация могла быть корректно передана архитектору ПО, и он понял бизнес на техническом уровне и установил связь этих объектов с использованием UML;
  • Ресурсы необходимо определять на более детальном уровне. Когда модель процесса переносится в Rational Software Architect и Rational Application Developer, индивидуальные и массовые ресурсы будут переведены в соответствующие Java-объекты с атрибутами. Следовательно, хорошей практикой будет как можно более подробное определение атрибутов этих объектов на бизнес-уровне. Например, атрибуты объекта Front Desk Personnel ("персонал стойки регистрации") в среде амбулаторного ухода для моделирования должны быть предоставлены экспертом в этой предметной области, чтобы затем эту информацию можно было передать архитектору ПО, который работает над проектированием системы;
  • Сервисы представляют собой повторяемые бизнес-задачи или совместно используемые компоненты в бизнес-процессе. Их необходимо определять в средствах моделирования на уровне бизнес-процесса, чтобы при передаче модели ИТ-архитекторам и разработчикам они могли с помощью технологии Web-служб создать соответствующее ПО/решение;
  • Если для мониторинга процесса после его размещения решено использовать WebSphere Business Monitor, то в Modeler необходимо идентифицировать и определить ключевые показатели бизнес-эффективности (KPI), создав модель бизнес-метрик (Business Measures);
  • Когда процесс готов для передачи разработчикам и последующей интеграции в WebSphere Integration Developer (WID), его необходимо экспортировать с помощью мастера экспорта WebSphere Business Modeler. Если процесс содержит бизнес-метрики, то необходимо выбрать тип экспорта WebSphere Business Monitor (из BPEL-процесса). Если процесс не содержит бизнес-метрики, то необходимо выбрать тип экспорта WebSphere Business Modeler project (.zip).

Преобразование модели бизнес-процесса в UML для архитектурного проектирования и разработки приложений

После проверки модели процесса на бизнес-уровне ее можно передать в отдел ИТ и начать проектирование и разработку системы. Модель процесса импортируется в Rational Software Architect в формате только для чтения с сохранением оригинальной структуры, но все элементы переводятся в UML-эквиваленты. Например, процессы (Processes) переводятся в примеры бизнес-использования (Business Use Cases), а ролевые (Role) бизнес-задачи переводятся в элементы типа Actor с операциями, индивидуальный ресурс переводится в Java-класс, бизнес-элемент (Business Item) переводится в бизнес-сущность (Business Entity), который представляется Java-классом с атрибутами. Rational Software Architect также обеспечивает интегрированное представление требований (Requirement), что позволяет архитектору просматривать и связывать бизнес-требования, установленные ранее в RequisitePro. Также архитекторы могут применять шаблоны, предоставляемые для сценария в Rational Software Architect. Такой тип отображения бизнеса на ИТ предоставляет архитекторам механизм для понимания специфичных для данной предметной области знаний, причем на знакомом им языке. При этом удается избежать неформальных "коридорных" переговоров, которые часто приводят к несогласованности действий бизнес-подразделений и отделов ИТ. Проектирование хорошей архитектуры для поддержки бизнес-целей при таком подходе становится гораздо проще. На рисунке 11 показана диаграмма классов UML, созданная в Rational Software Architect на основе бизнес-процесса подготовки визита к пациенту (Visit Preparation). Рисунок 12 демонстрирует интегрированное представление бизнес-модели, требований, а также UML-диаграмму примеров бизнес-использования в Rational Software Architect.

После завершения архитектурного проектирования Java-разработчики могут использовать Rational Application Developer для быстрого создания таких ресурсов многократного использования, как службы, Web-контент и базы данных (БД). Для повторно используемых ресурсов разработчик может применить EJB-преобразование в Rational Software Architect и сгенерировать компоненты Enterprise Java™ Beans (EJB), которые можно затем распространять и неоднократно использовать. После того, как основа кода уже создана, разработчики могут заняться реализацией основной логики для выполнения отдельных бизнес-операций. Это значительно повышает производительность труда и качество ПО, и одновременно сокращает дальнейшие усилия по тестированию. В процессе подготовки визита к пациенту элемент "Проверка страховки" ("Verify Insurance"), определенный в бизнес-процессе как повторяемая задача (сервис), был преобразован в сессионный компонент "Система страхования" ("Insurance System") в качестве Web-службы. Бизнес-сущность "Адрес" ("Address") пациента была преобразована в компонент управления данными. Для создания Web-контента разработчики могут перетащить Java Bean под названием "Patient", для которого ранее в бизнес-модели были определены символы, так что можно быстро создать страницу JSP для ввода и передачи данных о пациенте, как показано на рисунке 13. Кроме того, поскольку атрибуты бизнес-сущностей, такие как "Примечание о визите пациента" (Patient Visit Note), были уже определены на бизнес-уровне и преобразованы в компоненты управления данными, можно автоматически создать соответствующие таблицы БД, как показано на рисунке 14.

Рисунок 11. Диаграмма классов в Rational Software Architect для бизнес-процесса Visit Preparation
Диаграмма классов в Rational Software Architect для бизнес-процесса Visit Preparation
Диаграмма классов в Rational Software Architect для бизнес-процесса Visit Preparation
Рисунок 12. Требования и бизнес-процесс интегрированы в Rational Software Architect с UML-диаграммой примеров бизнес-использования
Требования и бизнес-процесс интегрированы в Rational Software Architect с UML-диаграммой примеров бизнес-использования
Требования и бизнес-процесс интегрированы в Rational Software Architect с UML-диаграммой примеров бизнес-использования
Рисунок 13. JSP можно легко создать перетаскиванием компонента Java Bean на страницу
JSP можно легко создать перетаскиванием компонента Java Bean на страницу
JSP можно легко создать перетаскиванием компонента Java Bean на страницу
Рисунок 14. Схему БД можно создать в Rational Software Architect на основе бизнес-сущностей, определенных в модели
Схему БД можно создать в Rational Software Architect на основе бизнес-сущностей, определенных в модели
Схему БД можно создать в Rational Software Architect на основе бизнес-сущностей, определенных в модели

Преобразование бизнес-модели в BPEL для хореографии процесса

Два других артефакта модели бизнес-процесса -- это исполняемый язык бизнес-процессов (Business Process Executable Language - BPEL) и язык описания Web-служб (Web Services Definition Language - WSDL). Их можно создать просто путем экспорта бизнес-модели, выбрав в мастере экспорта тип экспорта WebSphere Business Monitor (из BPEL-процесса). Полученные в итоге пакеты, содержащие BPEL и WISDL, содержат всю информацию о процессе и могут быть переданы специалисту по интеграции для хореографии процесса разработки с использованием WID.

WID, с одной стороны, берет артефакт BPEL из WB Modeler, а с другой стороны использует такой артефакт, как созданные в Rational Software Architect и в Rational Application Developer службы. С помощью WID разработчик интеграции собирает кусочки (сервисы) в интегрированное решение, а затем развертывает его в рабочей среде WebSphere Process Server (WPS). Рисунок 15 демонстрирует файлы BPEL и WSDL для процесса VisitPreparation, созданные из модели бизнес-процесса. Рисунок 16 показывает тот же процесс, представленный диаграммой BPEL в WID.

Интегрированный процесс Visit Preparation был развернут и выполнен на базе WPS, как показано на рисунке 17.

Рисунок 15. Экспортированные файлы BPEL and WSDL для процесса Visit Preparation
Экспортированные файлы BPEL and WSDL для процесса Visit Preparation
Экспортированные файлы BPEL and WSDL для процесса Visit Preparation
Рисунок 16. Диаграмма процесса Visit Preparation в WID для хореографии процесса разработки
Диаграмма процесса Visit Preparation в WID для хореографии процесса разработки
Диаграмма процесса Visit Preparation в WID для хореографии процесса разработки
Рисунок 17. Процесс, развернутый в исполняемой среде
Процесс, развернутый в исполняемой среде
Процесс, развернутый в исполняемой среде

Тест решения с помощью средств Rational

С помощью BDD инженеры перед завершением разработки ПО могут выполнять различные действия по тестированию с использованием инструментальных средств Rational. Средства тестирования Rational интегрированы с инструментами по управлению требованиями RequisitePro. Это позволяет инженерам по тестированию понять бизнес-требования и заблаговременно создать план проверки и контрольные примеры на основе собранных примеров использования, к которым они могут получить доступ. Когда ПО готово для тестирования, инженеры проводят тесты на соответствие требованиям, чтобы убедиться, что решение соответствует бизнес-целям. В данном примере для создания тест-плана и контрольных примеров для процесса Visit Preparation было использовано ПО Rational Test Manager, что показано на рисунке 18. Для выполнения ручных тестов и управления ими было использовано ПО Rational Manual Tester, как видно на рисунке 19. Инженеры по тестированию также могут использовать Rational Performance Tester для оценки и проверки производительности Web-службы. Они могут определить, как служба функционирует под различными нагрузками.

Рисунок 18. Контрольный пример, созданный и выполненный в Rational Test Manager
Контрольный пример, созданный и выполненный в Rational Test Manager
Контрольный пример, созданный и выполненный в Rational Test Manager
Рисунок 19. Ручное тестирование было выполнено с помощью Rational Manual Tester
Ручное тестирование было выполнено с помощью Rational Manual Tester
Ручное тестирование было выполнено с помощью Rational Manual Tester

Мониторинг для постоянного улучшения процесса

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

WebSphere Business Monitor позволяет производить такой мониторинг процесса в реальном времени и осуществлять сбор данных в качестве обратной связи для непрерывного совершенствования процесса. Связью между бизнес-моделью и средствами контроля служит компонент модели Business Measure, встроенный в WB Modeler. Модель Business Measure позволяет определять для процесса метрики производительности, счетчики, секундомеры и триггеры, а затем использовать их для дальнейшего определения KPI. Артефакт модели Business Measure затем экспортируется в формат XMI и используется для WebSphere Business Monitor. Как показано на рисунке 20, KPI, определенные для процесса Visit Preparation, включают в себя время ожидания пациента (Patient Waiting Time), время проверки страховки (Time for Verifying Insurance) и количество принятых пациентов (Number of Patient Received). Данные периода исполнения собираются на сервере процессов WebSphere Process Server, а затем обрабатываются и визуально отображаются в WB Monitor в среде WebSphere Portal. Владельцы процесса, такие как врачи и оперативные руководители, могут взглянуть на панель мониторинга и увидеть производительность процесса в реальном времени, что позволяет им предпринять соответствующие меры.

Рисунок 20. KPI, определенные в WB Modeler для процесса Visit Preparation
KPI, определенные в WB Modeler для процесса Visit Preparation
KPI, определенные в WB Modeler для процесса Visit Preparation

Заключение

Разработка, стимулированная бизнесом, является ключевой методологией для создания решений на базе технологии SOA в сфере здравоохранения. На примерах из реальной жизни данная статья описывает фундаментальные принципы применения BDD во время реализации подобных решений. Она иллюстрирует возможности инструментальных средств и делает акцент на том, как они взаимодействуют друг с другом в жизненном цикле BDD для создания SOA. Эта иллюстрация начинается с требований и бизнес-процессов на базе комплексной платформы разработки IBM, и продолжается описанием проектирования и разработки системы, интеграции, тестирования и мониторинга. Все это демонстрирует, как бизнес связывается с ИТ, стимулирует внедрение ИТ-решений, обеспечивает соответствие этих решений бизнес-задачам, с результирующим улучшением оперативности бизнеса и сокращением затрат времени и сил.

Страница References

1. The Standish Group, "Хроники CHAOS II, 2001 г.," Хроники CHAOS II, 2001 г., т. Том II, 2001 г.

2. Н.Н.Мансуров (N.N. Mansurov) и Р.Л.Проберт (R.L. Probert), "Сокращение времени вывода продуктов на рынок с помощью средств и методик SDL," Computer Networks, т. 35, стр. 667-691, 2001 г.


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=WebSphere
ArticleID=185560
ArticleTitle=Создание SOA-решений для организаций в сфере здравоохранения с помощью разработки, стимулированной бизнесом
publish-date=02122007