Введение

Архитектура Unified Method Architecture (UMA, унифицированная архитектура методов) была разработана с целью объединить терминологию и схемы представления всех подходов к разработке процессов в компании IBM, а также обеспечить поддержку важнейших отраслевых стандартов.   Поэтому, как показано на следующей схеме, архитектура UMA была совместно разработана специалистами IBM Rational Unified Process (RUP), IBM Global Services Method (GS Method) и IBM Rational Summit Ascendant.   Помимо этой основной группы, многие другие заинтересованные группы из IBM и других компаний внесли свой вклад в разработку этих спецификаций.   Сама спецификация была направлена в OMG в качестве предложения реализации стандарта SPEM 2.0.   Поскольку метамодель RUP 2003 была разработана на базе текущего стандарта SPEM 1.1, данная предложенная реализация SPEM 2.0 представляет собой следующий этап развития этого стандарта.

Главная цель этой унификации заключалась в разработке единого набора элементов и структур данных, позволяющего описать все методы и процессы без потери их ключевых характеристик.   Например, архитектура UMA должна была поддерживать много моделей жизненного цикла: итерационный цикл разработки RUP, итерационные циклы GS Method, а также итерационный и водопадный жизненные циклы Summit Ascendant.   Кроме того, требовалось унифицировать терминологию: то, что в RUP называлось операцией, в GS Method называлось задачей; артефакты RUP в Summit Ascendant назывались результатами и т.д.

Изменения в UMA для пользователей RUP 2003

В целях разработки единой структуры данных и единой терминологии для всех этих методологий все заинтересованные стороны должны были пойти на определенные компромиссы и согласиться на некоторые изменения. Хотя эти изменения могут вызвать определенные неудобства для текущих пользователей RUP, в долгосрочной перспективе все выиграют от введения унифицированной терминологии и стандартной методики описания методов и процессов. Это позволит оптимизировать обмен информацией о процессах и упростит использование готовых процессов для новых проектов.   В следующем списке перечислены важнейшие изменения в метамодели RUP 2003.   В таблице в конце этой страницы перечислены изменения в терминологии всех ключевых источников UMA.

• Операции стали называться задачами: минимальный распределяемый объем работы стал называться задачей, поскольку этот термин сегодня используется наиболее широко.
• Элементы потоков операций переименованы в операции: потоки операций обычно представлены в виде иерархических структур операций (диаграмм операций на языке UML 2.0).   Хотя в RUP был предусмотрен только один уровень иерархии в структуре потоков операций, UMA поддерживает многоуровневую иерархическую структуру. Поскольку слово "операция" чаще употреблялось для обозначения отдельных элементов диаграмм операций, чем самих диаграмм, мы решили заменить термин "элемент потока операций" термином "операция".   Мы понимаем, что изменение смысла термина "операция" может вызвать определенные неудобства для пользователей RUP.   Однако одна из важнейших задач UMA заключается в унификации терминологии и повсеместном переходе на термины, которые наиболее часто употребляются в описаниях стандартов и в отрасли в целом.  
• Задачи (прежнее название - операции RUP) могут выполняться в различных ролях:  в RUP 2003 операции были смоделированы в качестве атрибутов конкретных ролей.   Проанализировав отзывы клиентов и другие подходы к моделированию процессов, а также изменения в UML 2.0, мы пришли к выводу, что это был не самый оптимальный способ моделирования человеческого поведения.   Такая реализация не позволяла корректно моделировать задания, совместно выполняемые несколькими пользователями в различных ролях.   В UMA задача  реализована  в качестве независимого элемента модели, которой роли могут назначаться в качестве ресурсов.  Таким образом, в UMA задаче можно назначить несколько ролей.  Для совместимости с предыдущими версиями по-прежнему можно указать основную роль  (ответственную за выполнение задачи), а также несколько дополнительных исполнителей.
• Расширение понятия артефакта: в RUP артефакты использовались только для определения объектов, используемых и создаваемых в ходе реализации проекта по разработке программного обеспечения.   В UMA предусмотрена расширенная таксономия для этих концепций.   В этой архитектуре определено общее понятие продукта работы, разделенное на три типа: артефакты (управляемые продукты), результаты (упакованные продукты работы, доставляемые заинтересованным лицам) и исходы (неуправляемые нематериальные продукты работы).
• Различные категории продуктов работы и ролей: в RUP артефакты и роли разделены на категории по дисциплинам.  Однако иногда одни и те же артефакты применялись в нескольких дисциплинах и категориях, и поэтому классификация по дисциплинам приводила к возникновению путаницы.   В UMA для определений заданий (дисциплина для задач и операций), продуктов работы (домены и типы продуктов работы) и ролей (наборы ролей) предусмотрены независимые наборы категорий.  
• Компоненты процессов были переименованы в пакеты методов: понятие компонента используется во многих стандартах и технологиях. Как правило, понятие компонента вводится на уровне абстракции инкапсуляции: компонент представляет собой автономный объект (черный ящик), которым можно пользоваться через определенный интерфейс. Компоненты RUP не удовлетворяли этому определению черного ящика. Кроме того, в стандарте SPEM присутствуют как пакеты, так и компоненты. Для обеспечения соответствия со SPEM и общеупотребительному пониманию термина компонент мы переименовали компоненты процессов в пакеты методов. Технически компоненты представляют собой методы, поскольку в них могут находиться элементы методов и элементы процессов.
• Отделение элементов наполнения методов от элементов процессов: в RUP 2003 для создания процесса нужно определить новую конфигурацию и вручную указать ее отличия от стандартного процесса RUP с помощью артефакта прецедента разработки.   В UMA предусмотрены дополнительные средства настройки процессов, помимо конфигурации процесса.   В модели процесса можно указать, какие задания из наполнения методов должны выполняться на различных этапах жизненного цикла, а также предусмотрены средства добавления, удаления и переупорядочивания элементов в структуре процесса с возможностью многократного использования содержимого методов. Для этого в UMA предусмотрено более четкое отделение наполнения методов (например, задач дисциплин) и параметров применения этого наполнения в процессе (эти параметры задаются с помощью диаграмм операций и структуры заданий) от моделирования процессов (например, создания или адаптации диаграмм операции и структур заданий).   Введено несколько новых понятий, в том числе дескрипторы, применяемые для поддержки такого разделения и реализации новых возможностей по обслуживанию и многократному использованию семейств альтернативных процессов и обработки всех компонентов в рамках одной и той же конфигурации.

Различия в терминологии