Компания Rational Software сформулировала три основные определения Rational Unified Process (RUP):
- Совокупность основополагающих принципов для успешной разработки программного обеспечения. На этих принципах основана методология разработки программного обеспечения.
- Среда многоразового содержимого метода и строительных блоков процесса. Определенное и усовершенствованное Rational Software на постоянной основе, семейство RUP модулей метода определяет среду метода, в которой создаются собственные конфигурации метода и специализированные процессы. Это определение подчёркивает, что методология относится к разряду Agile методологий, то есть гибких методологий.
- Лежащий в основе язык определения методов и процессов. В основе всего лежит унифицированная метамодель архитектуры метода. Эта модель предоставляет язык описания процессов и содержимого методов. Этот новый язык представляет собой объединение различных языков разработки методов и процессов, включая язык моделирования UML.
Компания Rational Software разработала базу знаний под названием RUP Database, которая включает в себя опыт и рекомендации ведущих компаний-разработчиков для успешного создания крупных систем. Данная база постоянно пополняется и совершенствуется с учетом передового опыта. Компания выпустила целую линейку продуктов, которые являются основными инструментами для применения методологии RUP.
На рисунке 1 представлена краткая история развития методологии RUP.
Рисунок 1. История развития RUP
Развитие RUP с 1995 по 1998 года представлена на рисунке 2.
Рисунок 2. Генеалогическое дерево RUP
Методология разработки программного обеспечения является приемником Rational Objectory Process версии 4.
В этой методологии описаны основные аспекты таких областей, как инженерия данных, бизнес-моделирование, управление проектами и управление конфигурацией системы.
Данная методология позволяет интегрировать функции инструментальных средств Rational Software.
В результате объединения в 1995 году двух корпораций Rational Software Corporation и Objectory AB появилась методология Rational Objectory Process, являющаяся результатом интеграции двух продуктов Rational Approach и Objectory process версии 3.
Методология Objectory process создана в 1987 в Швеции Иваром Якобсоном в процессе его работы в шведской компании Ericsson, занимающейся производством телекоммуникационного оборудования.
В результате он применил методологию Objectory process для создания его продукта в компании Objectory AB. В основе этой методологии лежала концепция применения вариантов использования и объектно-ориентированный метод проектирования.
В 1992 года Якобсон задокументировал процесс разработки программного обеспечения, который получил название OOSE. Благодаря этому эта методология быстро получило признание в индустрии разработки ПО. Она была адаптирована и интегрирована многими известными компаниями в области разработки. Упрощенная версия методологии Objectory process была описано в книге Ивара Якобсона в 1992.
RUP является более конкретным и детализированными примером более общего процесса, который описали Ивар Якобсон, Гарди Буч и Джеймс Рамбо.
Джеймс Рамбо известен своей работой над созданием технологии объектного моделирования (OMT) и языка моделирования UML.
Иван Якобсон, Град Буч и Джеймс Рамбо совместно разработали язык моделирования UML. Впоследствии на основе OMT, OOSE и метод Буча они разработали единую методологию Rational Unified Process (RUP). В 2003 году ее приобрела корпорация IBM.
В истории RUP важным элементом является развитие нотации UML, которое представлено на рисунке 3.
Рисунок 3. История развития UML
В истории UML выделяют три основных периода: до UML 1.x, UML 1.x, UML 2.x.
Цели методологии включают в себя следующее:
- Гарантировать высокое качество программной системы, отвечающей потребностям Заказчиков, в пределах предсказуемого бюджета и графика
- Предоставить общий каркас (framework) процесса разработки ПО
- Обеспечить возможность формирования процесса разработки на базе адаптации RUP под конкретный проект
- Реализовать промышленный подход к выпуску ПО на основе многократного использования рабочих методик, описывающих общий каркас
- Гарантировать четкий контроль хода выполнения проекта на основе информационной поддержки всех фаз ЖЦ за счет дисциплины управления проектами и уменьшения плана итераций
- Снять барьеры непонимания между участниками проекта за счет единой терминологии
- Привести документооборот к стандарту ISO 9000 на основе предоставления специальных шаблонов документов
Выделяют десять основных приоритетов методологии:
- Разработка концепции.
- Создание плана.
- Идентификация и смягчение рисков.
- Установка и отслеживание проблем.
- Анализ прецедентов.
- Разработка компонентой структуры.
- Инкрементное создание и тестирование продукта.
- Проверка и оценка результатов.
- Управление и контроль изменений.
- Обеспечение поддержки пользователей.
Водопадная модель, классический подход разработки ПО, является идеальным решением для проектов, не обладающих повышенной сложности, не несущие новизну и не требующие использование специальных технологий.
Применение классического подхода разработки ПО может привести к следующим проблемам:
- Проекты почти никогда не укладываются в запланированные сроки и бюджет.
- Созданные в результате этого процесса система почти никогда полностью не удовлетворяют требованиям пользователей.
- Исследовательская компания Standish Group оценивает процент успешности разработки проекта порядка 26 %.
Источники и причины таких проблем:
- Потребности клиентов почти всегда опережают возможности разработчиков.
- Разработчики пренебрегают присущим индустриям системным принципам: массовое производство, повторяемость процессов и компонентов, надежность, следование методологическим и технологическим принципам.
- Узкая специализация затрудняет взаимопонимание между Заказчиками.
Для решения вышеописанных проблем методология RUP предлагает использовать лучшие практики в качестве решения проблем. Лучшие практики (Best Practices) – это набор проверенных на практике принципов, методов и процессов качественной и производительной работы над проектами по созданию ПО
Примеры реализации с использованием этих практик:
1) Rational Unified Process (IBM Rational)
2) MSF (Microsoft Solutions Framework)
3) ALM (Borland Application Lifecycle Management)
4) Enterprise Component Modeling (Platinum Technology)
Лучшие практики включают в себя следующее:
- Итеративная разработка.
- Эффективное управление требованиями.
- Визуальное моделирование.
- Компонентная архитектура.
- Проверка качества ПО на протяжении всего жизненного цикла.
- Контроль изменений, вносимых в ПО.
Для того, чтобы разработать систему, необходимо большую часть времени уделять составлению требований и спецификаций к системе. Исследовательская компания Standish Group в своем докладе 2001 года высказала следующее: “Изменение требований – это как смерть и налоги”. Освоение управления меняющимися требованиями имеет решающее значение для успеха проекта, и эта практика непосредственно влияет на жизнь разработчиков.
Техническое задание является инструкцией, которая является основной при создании любого продукта. Если составлению технического задания уделено очень мало времени, разработчики не смогут успешно создать проект. Управление требованиями основано на процессе трассировки задач, который представлен на рисунке 5 ниже.
Рисунок 5. Процесс трассировки требований
Задачи трассировки требований включают следующее:
- Оценка влияния изменений в проекте на требование.
- Оценка влияния неудачно завершённого теста на требования.
- Управление всеми аспектами проекта.
- Проверка соответствия реализации системы всем поставленным требованиям.
- Проверка соответствия работоспособности системы ее целям и предназначению.
- Управление изменениями.
Компания IBM дает следующие рекомендации для эффективного управления требованиями:
- Участие в процессе утверждения запроса на изменение.
- Умение говорить «Нет» Заказчику на очередной запрос об изменении.
- Создание регулярного обзора спецификаций требований и участие в нем команды.
- Ведение глоссария.
- Формирование проектного видения для понимания содержимого проекта.
- Демонстрация вариантов использования для иллюстрирования функций системы Заказчику.
Для обеспечения доступности требований всей команде компания IBM разработала специальный инструмент RequisitePro. RequsitePro является эффективным инструментом для осуществления процесса трассировки требований автоматизированными способами.
Компания IBM разработала концепцию автоматизации выполнения лучших практик. Она предполагает использование коммерческих специализированных инструментальных средств, входящих в пакет IBM Rational Suite, без которых невозможно внедрение RUP в различные корпоративные подразделения
Таким образом, применяя лучшие практики методологии RUP, у компаний есть возможность создавать успешные системы благодаря итеративному подходу. Стоит отметить, что в России эта методология не получила широкого распространения в силу того, что отсутствует утвержденная русскоязычная терминология и качественно переведенная документация по RUP. Однако, например, в США эта методология успешно применяется для разработки программного обеспечения в различных крупных корпорациях.
Библиографический список
- Jim Conallen. Developing Applications for the Web Service Era, A Rational Software whitepaper from IBM, No. 10/03, p. 11.
- Rational Unified Process. Best Practices for Software Development Teams, A Rational Software whitepaper from IBM, No. 11/01, p. 21.
- Claudio Marinelli, Alex Donatelli, Agostino Colussi, The IBM Rational Unified Process solution at the Tivoli Rome Laboratory: A RUP pilot implementation, The IBM Rational Unified solution in action, June 2007, p. 52.
- Rational Unified Process: A Best Practices Approach, IBM Corporation, 2003, p. 82.
- Using Service-Oriented Architecture and Component-Based Development to Build Web Service Applications, A Rational software whitepaper from IBM, No. 04/03, p. 15.
- Introducing Web Services into the Software Development Lifecycle, A Rational software whitepaper from IBM, No. 10/03, p. 9.
- Rational Unified Process for Systems Engineering RUP SE1.1, A Rational Software White Paper, No. 5/02, p. 28.
- Philippe Kruchten, From Waterfall to Iterative Lifecycle. A tough transition for project managers, Rational Software White Paper, No. 5/00, p. 10.
- Leslee Probasco, The Ten Essentials of RUP The Essence of an Effective Development Process, Rational Software White paper, p.12.
- Grady Booch, Unifying Enterprise Development Teams with the UML, A technical discussion of UML, p. 7.
- Catherine Connor and Leonard Callejo, Requirements Management Practices for Developers, Rational Software White paper, No. 03/02, p. 15.
- John Smith, A Comparison of the IBM Rational Unified Process and eXtreme Programming, A technical discussion of RUP, p. 24.