Эффективное общение между заинтересованными в проекте разработки лицами часто становится проблематичным, особенно если рабочие подразделения территориально рассредоточены или проект ограничен жесткими сроками. ПО IBM Rational способствует автоматизации, интеграции и управлению основным бизнес-процессом поставки программного обеспечения и систем в организациях при помощи платформы IBM Rational Software Delivery Platform. Ядром этой платформы является процесс IBM Rational Unified Process (RUP), гибкая инфраструктура для разработки итеративного бизнес-процесса поставки программного обеспечения и систем. Опираясь на фирменные и заимствованные передовые методы (их количество превышает два десятка), RUP помогает уменьшить риск ошибок в проекте и распространить принципы согласованности, предсказуемости, производительности и эффективности на всю организацию.
Дисциплина RUP Business Modeling предоставляет для бизнес-прецедентов инструменты и нотации, которые способствуют повышению эффективности взаимодействия заинтересованных в проекте лиц и утверждению проекта отраслевыми экспертами. Эта дисциплина предоставляет бизнес-аналитикам возможность использовать для документирования бизнес-процесса те же нотации и инструменты, которые используют разработчики архитектуры и проектировщики для документирования программных решений. Благодаря этому эти две группы специалистов смогут лучше взаимодействовать между собой, что обеспечит соответствие этой программной системы бизнес-требованиям.
Бизнес-прецедент описывает бизнес-процесс, документированный в виде последовательности действий, которые представляют собой наблюдаемую величину для бизнес-деятелей. Бизнес-деятель - это лицо, система или другая сущность, взаимодействующая с предприятием или организацией. В свете вышеперечисленного, для того, чтобы бизнес-прецедент имел ценность в глазах заинтересованных в нем лиц, он должен описывать, что делает предприятие, а именно, его взаимодействия в рамках своего окружения. Чтобы в полной мере понять цели бизнеса и его процессы, нам необходимо знать, кто обуславливает требования к нему и кто заинтересован в его результатах.
Кроме того, можно считать, что бизнес-прецедент документирует конкретный рабочий бизнес-поток. Поток событий, или рабочий поток - это главный элемент бизнес-прецедента. Он описывает, что делает организация для того, чтобы поставить экономическую ценность бизнес-деятелю. Это описание должно быть понятно любому участнику бизнес-процесса. (И, что очень важно, оно не должно быть описанием того, как бизнес решает свои проблемы.)
Независимо от назначения проекта разработки (предоставление новых функций или разработка новой для бизнеса области), согласование и утверждение бизнес-прецедентов является критически важным элементом RUP. Дисциплина RUP Business Modeling (Бизнес-моделирование) способствует более эффективному обсуждению, согласованию и утверждению требований к проекту, предоставляя инструментарий и нотации для работы с бизнес-прецедентами.
Модель бизнес-прецедента представляет собой общую схему с точки зрения бизнес-деятеля. Она описывает бизнес-процесс понятным всем участникам проектной группы способом. Но коллективам разработчиков ПО бизнес-модели нужны и еще по одной причине. Программное обеспечение необходимо разрабатывать быстро, при этом новые этапы разработки должны в большей степени диктоваться экономической ценностью для бизнеса, а не техническими потребностями. Эффективная бизнес-модель предоставляет независимое от конкретной программы описание автоматизируемых процессов, благодаря которому комплекс приоритетов и рисков распространяется и на выбор технологии.
ИТ-коллективы должны иметь в своем распоряжении описания бизнеса, которые позволят специалистам принимать обоснованные решения, в числе прочих документов - спецификацию бизнес-процесса, которая детализирует значимые экономические ценности и не допускает неоднозначных толкований. Бизнес-прецеденты документируются в виде спецификаций, состоящих из словесного описания рабочих потоков и одной или более UML-диаграмм активности. Пример спецификации бизнес-прецедента показан на рисунке 1. Обратите внимание, что на диаграмме слева представлено схематическое изображение структуры рабочего потока, содержащегося в тексте описания бизнес-прецедента справа.
Рисунок 1. Пример спецификации бизнес-прецедента
Соответствующее описание рабочего потока для рисунка 1.
- Интерфейс Customer Sales начинает взаимодействие..
- Если интерфейс Customer Sales определит, что подготовка к представлению задания выполнена, он отправляет запрос-заявку Владельцу проектного предложения.
- В противном случае интерфейс Customer Sales ищет альтернативные варианты.
- Если интерфейс Customer Sales находит альтернативный вариант, переходим к началу схемы.
- Владелец проектного предложения создает план проектного предложения.
- Владелец проектного предложения отправляет план проектного предложения Владельцу квот.
- Владелец квот выделяет квоту.
- Владелец квот отправляет квоту Владельцу проектного предложения.
- Владелец проектного предложения анализирует проектное предложение и завершает работу над ним.
- Владелец проектного предложения создает план поставки проектного предложения.
- Владелец проектного предложения добавляет дополнительную информацию.
- Владелец проектного предложения отправляет проектное предложение интерфейсу Customer Sales.
- Интерфейс Customer Sales представляет проектное предложение клиенту.
- Интерфейс Customer Sales получает решение клиента.
Ниже перечислены компоненты диаграммы, показанной на рисунке 1.
- В столбцах ("дорожках") показано, какой работник какую деятельность выполняет. Сам работник на диаграмме активности для бизнес-прецедента не представлен; он будет показан как компонент реализации бизнес-прецедента.
- Состояния деятельности отражают выполнение деятельности или шага в рабочем потоке.
- Переходы показывают порядок следования деятельностей. Такой тип перехода называется переходом выполнения . Это особый вид перехода, который запускается по выполнении деятельности, которое отражается в состоянии деятельности.
- Все решения имеют определенный набор контрольных условий. Контрольные условия управляют тем, какой именно переход из набора альтернативных переходов будет запущен по выполнении деятельности. Решения и контрольные условия позволяют бизнес-аналитикам указать в рабочем потоке бизнес-прецедента альтернативные пути выполнения.
Бизнес-прецеденты и прототипирование имитаций
Прототипы пользовательских интерфейсов могут в значительной степени способствовать процессу согласования и утверждения бизнес-прецедентов пользователями. Мнения пользователей, полученные в процессе согласования и утверждения интерфейса, должны включаться в спецификацию бизнес-прецедента, но очень важно, чтобы спецификация прецедента была создана до прототипирования. Если предложить имитации пользователю на слишком ранних этапах цикла определения и осмысления требований, мы рискуем не получить полного определения всех проблем, которые необходимо решить. Бизнес-аналитики могут сначала изучить бизнес-прецеденты, чтобы понять проблему, а затем и последовательность выполнения процесса, а уже после этого приступить к проектированию потока страниц. Другими словами, бизнес-аналитикам необходимо понять бизнес-процесс до того, как они приступят к разработке имитаций конкретных страниц.
В то время, как модель прецедента описывает, что происходит между бизнес-деятелем и бизнесом, не делая допущений о структуре бизнеса или о способах достижения целей, цель модели бизнес-анализа описывают, как выполняются бизнес-прецеденты. Модель бизнес-анализа определяет конкретные предлагаемые бизнесом сервисы, внутренних работников бизнеса и информацию, которую они используют, описывает их структурную организацию в независимых единицах и определяет способы их взаимодействия для реализации поведения, описанного в бизнес-прецедентах.
Модель бизнес-анализа описывает реализацию бизнес-прецедентов, предоставляя абстрактную схему того, как должны взаимодействовать бизнес-системы, работники и другие сущности, чтобы выполнить бизнес-прецедент. Кроме того, она определяет внешние для бизнеса сервисы, которые используются бизнес-деятелями при выполнении бизнес-прецедента.
Модель бизнес-анализа используется заинтересованными лицами и аналитиками бизнес-процессов для того, чтобы понять, как работает бизнес на данный момент "как есть"), и проанализировать действие изменений в бизнесе ("как должно быть"). Эта модель используется системными аналитиками для извлечения требований из автоматизированных систем, которые будут использоваться как компоненты бизнес-процессов. Разработчики архитектуры используют модель для определения программной архитектуры, которая наилучшим образом подойдет для данной организации, а также для идентификации классов в моделях анализа ПО и проекта. В результате того, что бизнес-специалисты и специалисты по информационным технологиям используют одну и ту же модель, они "разговаривают на одном языке", тем самым достигается лучшее соответствие реальным потребностям бизнеса.
Бизнес-прецеденты и жизненный цикл разработки программного обеспечения
Хотя моделирование бизнеса может осуществляться либо независимо от работы по перестройке бизнес-процессов, либо как часть этой работы, в любом случае оно вносит свой вклад в процесс разработки программного обеспечения. Особенно моделирование бизнеса помогает в определении требований к системе. Для коллектива разработчиков частью процесса определения требований является анализ проблем, которые необходимо решить. Выполнение этого анализа в более широком контексте бизнеса может помочь построить систему в соответствии с бизнес-целями.
По сути, бизнес-модель, построенная на UML, может быть напрямую использована на входе модели требований. В RUP определено прямое отображение этих двух моделей. При отображении бизнес-модели в модель анализа:
- Бизнес-процесс который необходимо автоматизировать, будет представлен в виде прецедента.
- Бизнес-прецедент становится подсистемой.
- Каждая бизнес-сущность становится объектным классом.
Такое отображение помогает точно определить требования, выполнить анализ рабочих потоков и их разработку. Если организация отличается сложностью и стремится автоматизировать значимые функции, то бизнес-модель может оказать неоценимую пользу. Обеспечение решения организацией правильно поставленных задачи в контексте бизнеса может означать для этой организации расстояние между успехом и неудачей бизнеса. Использование UML для создания моделей бизнеса и требований - лучший способ обеспечить направленное взаимодействие и превосходные результаты проекта.
Поддержка инструментария для бизнес-прецедентов
Поскольку это важно не только для того, чтобы получить правильные требования, но и для того, чтобы обсудить их тем способом, который будет понятен всем членам проектного коллектива, инструменты, автоматизирующие перевод текстовой информации прецедентов в визуальные модели, помогают существенно сэкономить время.
Распространенные ошибки чаще легче выявляются на диаграммах, поэтому возможность быстро сгенерировать визуальное представление письменного прецедента значительно ускоряет итеративный процесс согласования и утверждения требований. Часто проект начинает испытывать проблемы именно из-за того, что бизнес-специалисты все выражают при помощи слов, тогда как разработчики архитектуры и инженеры - при помощи моделей. Этот разрыв в способах общения лучше всего преодолевается, если и текстовое описание и диаграммы работают вместе. Получение готовых требований - и точных визуальных моделей - в самые первые дни проекта представляет собой критически важный момент для достижения успеха на более поздних стадиях цикла жизненного цикла разработки.
На рисунке 2 показано, как популярные определения требований, а также инструменты управления и моделирования вписываются в процесс RUP для разработки приложений.
Рисунок 2. Как популярные определения требований, а также инструменты управления и моделирования вписываются в процесс RUP для разработки приложений
BM Rational RequisitePro® - это инструмент для управления требованиями, который позволяет рабочим группам совместно работать над требованиями, используя знакомые, основанные на использовании документов методы, и в то же время использовать предоставляемые базами данных функции, такие, как трассировка требований и анализ влияния. В результате его применения достигается лучшее взаимодействие специалистов и управление требованиями, а также повышенная вероятность своевременного завершения проекта без превышения бюджета и раньше ожидаемых сроков.
IBM Rational Software Modeler - надежный инструмент визуального моделирования на базе UML 2.0. Он позволяет разработчикам архитектуры, системным аналитикам, проектировщикам и другим специалистам определить и обсудить информацию по процессу разработки с нескольких точек зрения и с различными заинтересованными лицами, и в то же время обеспечить полную поддержку моделирования при помощи UML 2.1.
RAVEN от компании Ravenflow - это проверенный "совместимый с IBM Rational" партнерский продукт, который предназначен для того, чтобы помочь коллективам в разработке, согласовании и утверждении бизнес-прецедентов. Выражение "совместимый с IBM Rational" означает, что RAVEN выполняет рекомендации Rational в отношении интеграции, он без проблем взаимодействует с продуктами Rational и, при использовании в сочетании с ними, создает у пользователя впечатление работы в однородной среде. RAVEN позволяет аналитикам быстро определить и согласовать бизнес-прецеденты со всеми заинтересованными лицами и пользователями путем автоматического создания представлений в виде диаграмм на основе текстовых описаний бизнес-прецедента. Инструмент взаимодействует с Rational RequisitePro, благодаря чему бизнес-прецеденты можно хранить в базе данных RequisitePro.