Предоставление инструкций по процессу
При выборе решения определения требований организации нуждаются в инструменте, который бы поддерживал используемые ими практики. При использовании Rational Requirements Composer для определения требований вы можете использовать встроенные в ПО практики для решения типичных проблем с требованиями. Вы также можете сделать эти практики конфигурируемыми с помощью IBM Rational Method Composer, чья библиотека процессов содержит уже готовые практики, а также инструменты для создания ваших собственных практик. Кроме того, вы можете расширить ваши возможности, воспользовавшись преимуществами технологий IBM для более простой адаптации новых техник и стилей нотаций, и IBM покажет вам способ объединения этих нотаций. Например, сотрудникам, привыкшим к работе с прецедентами использования, можно предложить работу с текстом. Но этот подход должен дополняться такими визуальными техниками, как раскадровки, диаграммы бизнес-процессов и прецедентов использования.
Rational Requirements Composer предоставляет контекстно-зависимые инструкции по процессу, поэтому вы можете переходить от одного редактора к другому, работая с различными функциями этого ПО. Эти практики базируются на методологии IBM Rational Unified Process® (RUP®) и инфраструктуре Open Unified Process (OpenUP). При использовании Rational Method Composer, вам становятся доступны возможности авторинга и доступа к библиотеке процессов, что повышает удобство использования Rational Requirements Composer, включая инструкции по процессу от IBM и OpenUP, или же вы можете создать ваш собственный набор наилучших практик.
Rational Requirements Composer предоставляет различные техники определения требований, организационные возможности и инструкции по процессу, формируя платформу для совместной работы и помогая эффективно поставлять ПО более высокого качества.
Различные техники определения требований, возможности сотрудничества, организационные возможности и инструкции по процессу, имеющиеся в Rational Requirements Composer, предназначены для помощи в определении тех областей разработки, которые могут оказывать наиболее сильное влияние на точность определения требований. Уделяя этим областям особое внимание, вы можете согласовать бизнес-цели с ИТ-возможностями, снизить необходимость в переработке и ускорить время выхода на рынок, повысить производительность и степень повторного использования, а также гарантировать, что требования по проекту имеют достаточно высокий уровень качества для успеха проекта и эффективной поставки программного обеспечения.
Создание схемы бизнес-процессов
Диаграмма бизнес-процесса изображает направленный поток видов деятельности, указанных с использованием подмножества Business Process Modeling Notation (BPMN).
Создаём диаграмму, выбирая Business Process Diagram из выпадающего меню Create Artifact. Задаём имя в поле Name и указываем куда сохранять (в папку Processes). В разделе Options существует два типа процесса: Simple Process (используется для представления внутренних процессов, которые происходят в течение одного подразделения или хозяйствующих субъектов) и Business-to-Business Process (используется для представления глобального процесса, который охватывает более одного подразделения или хозяйствующих субъектов).
В нашем случае выбираем Simple Process и нажимаем кнопку Next. В следующем окне указаны атрибуты, с которыми мы уже знакомы. По нажатию кнопки Finish появляется рабочая область. Для создания диаграммы, перетащите элементы процесса из палитры, в редактор, нажав на соответствующий значок. Затем подключите элементы, используя разъем элемента.
Ниже приведён пример построенной диаграммы.
Диаграммы Деятельности В Rational Requirements Composer
Рисунок 2.2 – Диаграмма деятельности «Регистрация пользователя»
Рисунок 2.3 – Диаграмма деятельности «Выбор товара»
Рисунок 2.4 – Диаграмма деятельности «Работа оператора»
Рисунок 2.5 – Диаграмма деятельности «Оформление покупки товара»
Рисунок 2.6 – Диаграмма деятельности «Администрирование системы»
BPMN Collaboration diagrams
Сollaboration diagrams состоят из набора участников, которые представлены пулами. Взаимодействия пулов представлены потоками сообщений, также они могут включать в себя процессы в пулах.
Сollaboration diagram как правило, содержит два или более пула, которые представляют участников в схеме. Обмен сообщениями между участниками представляет собой поток сообщений, который соединяет два пула или объектов в пулах.
На следующей Сollaboration diagrams BPMN, представлены два участника: клиент и банк. Задачи для каждой из них показаны в каждом пуле и в сообщениях, отправленных каждому участнику.
