Моделирование. Наш метод

3.2 Создание решения для работы с внешними оценщиками

Подход, который использовался группой System House, разрабатывавшей решение для данного курса, основывался на методах, применяемых сервисными группами IBM в реальных проектах. Группа моделировала бизнес-процесс на семинарах по сбору требований, документировала имеющийся бизнес-процесс и определяла будущий бизнес-процесс. Затем модель из анализа бизнес-процесса была взята в качестве отправной точки для разработки, направляемой бизнесом, которая применялась для проектирования и реализации решения.

Этот метод описывается в следующих разделах:

1. В разделе 3.2.1, "Роли и области ответственности", описываются все роли, занятые в построении решения.
2. В разделе 3.2.2, "Области ответственности и разработка по контрактам", описывается организация проекта и создаваемые продукты.
3. В разделе 3.2.3, "Сбор бизнес-требований на семинарах по моделированию", описывается польза семинаров в данном процессе.
4. В разделе 3.2.4, "Создание базовой архитектуры", показана модель постадийного преобразования детализованной архитектуры в дизайн, за которым следует разработка решения.
5. В разделе 3.2.5, "Многоуровневая модель активов Patterns for e-business", вы познакомитесь со стадиями модели Patterns for e-business, которые используются на первом этапе детализации архитектуры.
6. В разделе 3.2.6, "Процесс использования модели активов Patterns for e-business", предлагается более детальная информация о методе применения многоуровневой модели активов Patterns for e-business к решению по интеграции процессов.
7. В разделе 3.2.7, "Использование разработки, управляемой моделями", обсуждается, какую пользу применение разработки, управляемой моделями (MDD), принесет команде, разрабатывающей решение, при переходе от исходной модели бизнес-процесса к реализации.
8. В разделе 3.2.8, "Цепочки инструментов", описывается планирование MDD через понимание того, как инструменты, используемые разными ролями, участвующими в разработке, интегрируются в платформе разработки программного обеспечения.

3.2.1 Роли и области ответственности

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

1. Устанавливается, кто будет отвечать за связь между бизнес-целями и ИТ-целями. Это важно, поскольку разработка программного обеспечения для бизнеса по требованию рассматривается как бизнес-функция, а не как чисто инженерная процедура.
2. Определяется, кто принадлежит к техническим специалистам, каковы будут их требования к платформе разработки программного обеспечения, кто из них будет зависеть от данных другого и какими артефактами нужно будет обмениваться через платформу разработки.

В разработке участвуют следующие роли:

• Бизнес-куратор. Это руководитель, отвечающий за претензии по автострахованию. Этот человек должен иметь полномочия директорского уровня.

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

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

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

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

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

  Менеджер проекта будет сотрудничать с бизнес-аналитиком и использовать отчеты инструмента Modeler для формирования задач и областей ответственности.
• Ведущий семинаров.

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

  Ответственный за документирование семинаров будет использовать WebSphere Business Integration Modeler или Microsoft Visio для записи моделей процесса. Продвижение в создании модели процесса может записываться после каждого семинара. В качестве альтернативы, если это удовлетворит всех участников, более эффективной будет интерактивная работа с инструментом с использованием проектора или же общего экрана (при дистанционном семинаре).
• Бизнес-аналитик и специалист по процессам.

  Бизнес-аналитик отвечает за бизнес-процессы, существующие в страховой компании LGI. Аналитик отвечает перед бизнес-куратором за достижение целей, поставленных для процесса автоматизации работы с оценщиками.

  Бизнес-аналитик выполняет следующие задачи:

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

  Бизнес-аналитик будет использовать WebSphere Business Integration Modeler. Он также будет использовать инструмент для создания и документирования процесса, определения измеряемых параметров, относящихся к целям, установленным для решения, и для эмуляции бизнес-процесса с целью проверки достижения поставленных целей.
• ИТ-архитектор.
  • Архитектор решения:

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

    Архитектор решения выполняет следующие задачи:

    • проектирование нового решения, приложения или функции на основе указанных функциональных и нефункциональных требований;
    • определение интерфейса новых бизнес-служб;
    • написание проектных спецификаций приложения, включая четкие спецификации функциональных и нефункциональных требований;
    • изменение существующих служб в соответствии с новыми требованиями;
    • планирование обновлений решения и внедрения новых возможностей (приложений и продуктов);
    • определение ожидаемого поведения службы в смысле производительности, уровня обслуживания и удобства пользования;
    • определение последовательностей (потоков) задач для ввода в действие бизнес-службы;
    • использование аналитических инструментов для описания информации и потоков задач, например BPR-средств (Business Process Re-engineering, Переработка бизнес-процессов), таких, как Holosofx® или OOA-средств (Object Oriented Analysis, Объектно-ориентированный анализ), таких как Rational Rose®;
    • взаимодействие с людьми бизнеса для улучшения понимания конкретного бизнес-процесса или бизнес-требования;
    • взаимодействие с разработчиками приложений для интерпретации бизнес-требований в технических терминах.

    Главный инструмент, который должен применять архитектор решения, – это Rational Software Modeler или Rational Software Architect, а не WebSphere Business Integration Modeler. Архитектор использует WebSphere Business Integration Modeler для понимания модели бизнес-процесса, применяя артефакты, общие с инструментами Rational.
  • Архитектор предприятия/инфраструктуры.

    Главной областью ответственности архитектора предприятия является определение стандартов для ИТ-инфраструктуры и стратегических ИТ-целей для бизнеса. Архитектор инфраструктуры отвечает за понимание стандартов и целей ИТ-инфраструктуры и за обеспечения соответствия новых решений этим стандартам и целям. Кроме этого, данный архитектор отвечает (хотя это и не входит в наш сценарий) за планирование пропускной способности, выполнение требований по времени ответа и уровню обслуживания, за обслуживание ИТ-инфраструктуры, отказоустойчивость, а также за резервное копирование и восстановление системы.
  • Архитектор данных.

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

    В этом тексте мы опустили все вопросы, связанные с моделями данных, поскольку основное внимание мы уделяем интеграции на основе процессов. Когда нам нужно будет выбрать инструменты для моделирования и построения решения, вопросам, связанным с данными, будет уделено самое пристальное внимание.
  • Архитектор безопасности.

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

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

  Главной областью ответственности ИТ-специалистов является экспортирование модели процесса, созданной бизнес-аналитиком (BPEL), из WebSphere Business Integration Modeler, модели, созданной ИТ-архитектором (UML), из Rational Software Architect и реализация компонентов этих моделей с помощью продуктов, с которыми они работают.

Рис. 3.5. Роли, участвующие в создании решения

Разработчики приложений выполняют следующие задачи:

• Разработка бизнес-служб в соответствии с моделью, созданной архитектором.
• Принятие решений по конкретной реализации необходимых потоков задач (рабочих потоков, потоков сообщений и т. п.).
• Написание EJB-компонентов, являющихся оболочками внутренних и внешних ресурсов, или реализация новых служб.
• Создание потоков сообщений и наборов сообщений для реализации посредничества между службами.
• Конфигурирование WebSphere MQ Workflow для выполнения кода FDL и интеграция его с ручными и автоматизированными задачами.
• Преобразование кода BPEL из описания процесса в определение выполнения процесса и интеграция потока BPEL с ручными и автоматизированными задачами.
• Модульное тестирование каждого компонента приложения на соответствие спецификациям, а также тестирование правильности работы и базовой производительности разработанных компонентов приложения.
• Разработка пользовательских интерфейсов, EJB или сервлетных каркасов, чтобы созданные службы можно было применять в других решениях.

  У нас было четыре ИТ-специалиста. Мы объединили роли, связанные с разработкой и обслуживанием рабочей системы, поскольку основное внимание мы уделяем разработке, а единственная задача, относящаяся у нас к рабочей системе, – это ее размещение:

  • Специалист по WebSphere MQ Workflow.

    Специалист по WebSphere MQ Workflow отвечает за то, чтобы заставить новый (создаваемый) процесс обработки претензии, определенный бизнес-аналитиком, или существующий процесс обработки претензии, работающий в WebSphere MQ Workflow, вызывать новый подпроцесс работы с внешним оценщиком.

    Главным инструментом этого специалиста является WebSphere MQ Workflow Buildtime. Однако данный специалист также должен детализировать создаваемый процесс в WebSphere Business Integration Modeler и экспортировать FDL-код, чтобы с ним можно было работать в Workflow Buildtime.
  • Специалист по WebSphere Business Integration Message Broker и WebSphere MQ.

    Этот специалист отвечает за базовую инфраструктуру WebSphere MQ и предлагает потоки сообщений для соединения поставщиков и потребителей служб. Главными инструментами этого специалиста являются рабочая среда WebSphere Business Integration Message Broker и WebSphere MQ explorer.
  • Специалист по WebSphere Business Integration Server Foundation и Web-Sphere Studio Application Development Integration Edition.

    Этот специалист отвечает за реализацию нового BPEL-процесса работы с внешними оценщиками при помощи WebSphere Studio Application Development Integration Edition.
  • Специалист по WebSphere Application Server и WebSphere Studio Application Developer.

    Специалист по WebSphere Application Server отвечает за создание и размещение служб, используемых для автоматизации обработки претензий. Мы употребили для создания служб WebSphere Studio Application Development Integration Edition.