Методология rational unified process реферат

Обновлено: 02.07.2024

Тема: Рациональный унифицированный процесс. Характеристики процесса. Фазы, итерации и циклы разработки. Рабочие процессы.

Выполнил: Шеремет С. М

Студент _5___ курса

_______4____ семестр

Нягань, 2011

В настоящее время широкое применение получают так называемые промышленные технологии создания программного продукта. Эти технологии были разработаны фирмами, накопившими большой опыт создания ПО. Технологии представлены описаниями принципов, методов, применяемых процессов и операций. Такие технологии, как правило, поддерживаются набором CASE – средств (Computer Aided System Engineering), охватывают все этапы жизненного цикла продукта и успешно применяются для решения практических задач. Но развитие технологии разработки программного обеспечения, методов моделирования, появление CASE-технологий не решило проблему определения и формализации требований к информационным системам, но способствовало возникновению нескольких основных подходов.

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

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

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

Процесс – частный случай более общего понятия методологии разработки ПО. Примерами методологий являются структурное программирование или объектно-ориентированный анализ и дизайн.

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

Таким образом, целью данной курсовой работы является рассмотрение RUP(Rational Unified Process).

Предназначение RUP

Rational Unified Process – это модель создания программного обеспечения, оформленная в виде размещаемой на Web базы знаний, которая снабжена поисковой системой.

Продукт Rational Unified Process (RUP) разработан и поддерживается Rational Software. Он регулярно обновляется с целью учета передового опыта и улучшается за счет проверенных на практике результатов.

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

RUP способствует повышению производительности коллективной разработки и предоставляет лучшее из накопленного опыта по созданию ПО, посредством руководств, шаблонов и наставлений по пользованию инструментальными средствами для всех критически важных работ, в течение жизненного цикла создания и сопровождения ПО. Обеспечивая каждому члену группы доступ к той же самой базе знаний, вне зависимости от того, разрабатывает ли он требования, проектирует, выполняет тестирование или управляет проектом - RUP гарантирует, что все члены группы используют общий язык моделирования, процесс, имеют согласованное видение того, как создавать ПО. В качестве языка моделирования в общей базе знаний используется Unified Modeling Language (UML), являющийся международным стандартом.

Особенностью RUP является то, что в результате работы над проектом создаются и совершенствуются модели. Вместо создания громадного количества бумажных документов, RUP опирается на разработку и развитие семантически обогащенных моделей, всесторонне представляющих разрабатываемую систему. RUP – это руководство по тому, как эффективно использовать UML. Стандартный язык моделирования, используемый всеми членами группы, делает понятным и для всех описания требований, проектирование и архитектуру системы.

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

RUP – это конфигурируемый процесс, поскольку, вполне понятно, что невозможно создать единого руководства на все случаи разработки ПО. RUP пригоден как для маленьких групп разработчиков, так и для больших организаций, занимающихся созданием ПО. В основе RUP лежит простая и понятная архитектура процесса, которая обеспечивает общность для целого семейства процессов. Более того, RUP может конфигурироваться для учета различных ситуаций. В его состав входит Development Kit, который обеспечивает поддержку процесса конфигурирования под нужды конкретных организаций.

RUP описывает, как эффективно применять коммерчески обоснованные и практически опробованные подходы к разработке ПО для коллективов разработчиков, где каждый из членов получает преимущества от использования передового опыта в:

• итерационной разработке ПО,

• использовании компонентной архитектуры,

• тестировании качества ПО,

• контроле за изменениями в ПО.

RUP организует работу над проектом в терминах последовательности действий (workflows), продуктов деятельности, исполнителей и других статических аспектов процесса с одной стороны, и в терминах циклов, фаз, итераций и временных отметок завершения определенных этапов в создании ПО (milestones), т.е. в терминах динамических аспектов процесса, с другой [5].

Жизненный цикл RUP

Модель жизненного цикла RUP является довольно сложной, детально проработанной итеративно – инкрементной моделью с элементами каскадной модели. В модели RUP выделяются 4 основные фазы, 9 видов деятельности (процессов). Кроме того, в модели описывается ряд практик, которые следует применять или руководствоваться для успешного выполнения проекта. RUP ориентирован на поэтапное моделирование создаваемого продукта с помощью языка UML (Рис.5).

Рис.5. Жизненный цикл RUP

Основными фазами RUP являются:

Фаза начала проекта (Inception). Определяются основные цели проекта, бюджет проекта, основные средства его выполнения – технологии, инструменты, ключевой персонал, составляются предварительные планы проекта. Основная цель этой фазы – достичь компромисса между всеми заинтересованными лицами относительно задач проекта.
Фаза проработки (Elaboration). Основная цель этой фазы – на базе основных, наиболее существенных требований разработать стабильную базовую архитектуру продукта, которая позволяет решать поставленные перед системой задачи и в дальнейшем используются как основа разработки системы.
Фаза построения (Construction). Основная цель этой фазы – детальное прояснение требований и разработка системы, удовлетворяющей им, на основе спроектированной ранее архитектуры.
Фаза передачи (Transition). Цель фазы – сделать систему полностью доступной конечным пользователям. Здесь происходит окончательное развертывание системы в ее рабочей среде, подгонка мелких деталей под нужды пользователей.

В рамках каждой фазы возможно проведение нескольких итераций, количество которых определяется сложностью выполняемого проекта.

Деятельности (основные процессы) RUP делятся на 5 рабочих и 4 поддерживающие. К рабочим деятельностям относятся:

Моделирование предметной области (бизнес – моделирование, Business Modeling). Цели этой деятельности – понять бизнес – контекст, в котором должна будет работать система (и убедиться, что все заинтересованные лица понимают их одинаково), понять возможные проблемы, оценить возможные их решения и их последствия для бизнеса организации, в которой будет работать система.
Определение требований (Requirements). Цели – понять, что должна делать система, определить границы системы и основу для планирования проекта и оценок ресурсозатрат в нем.
Анализ и проектирование (Analysis and Design). Выработка архитектуры системы на основе ключевых требований, создание проектной модели, представленной в виде диаграмм UML, описывающих продукт с различных точек зрения.
Реализация (Implementation). Разработка исходного кода, компонент системы, тестирование и интегрирование компонент.
Тестирование (Test). Общая оценка дефектов продукта, его качество в целом; оценка степени соответствия исходным требованиям.

Поддерживающими деятельностями являются:

Развертывание (Deployment). Цели – развернуть систему в ее рабочем окружении и оценить ее работоспособность.
Управление конфигурациями (Configuration and Change Management). Определение элементов, подлежащих хранению и правил построения из них согласованных конфигураций, поддержание целостности текущего состояния системы, проверка согласованности вносимых изменений.
Управление проектом (Project Management). Включает планирование, управление персоналом, обеспечения связей с другими заинтересованными лицами, управление рисками, отслеживание текущего состояния проекта.
Управление средой проекта (Environment). Настройка процесса под конкретный проект, выбор и смена технологий и инструментов, используемых в проекте.

Безусловно, RUP - итеративная методология. Хотя выполнение всех фаз или какого-то минимального числа итераций нигде в RUP не оговаривается, весь подход ориентирован на то, что их достаточно много. Только при этом можно настроить процесс для последующих итераций, основываясь на результатах начальных. Ограниченное количество итераций не позволяет использовать в полной мере все преимущества RUP. Вместе с тем, RUP можно использовать и в "практически каскадных" проектах, включающих реально всего пару итераций: одну в фазе Построение и одну в фазе Передача. Именно такое количество итераций, как правило, реально используется в каскадных проектах. Ведь проведение испытаний и опытной эксплуатации системы предполагает внесение исправлений, которые могут предполагать определенные действия, связанные с анализом, проектированием и разработкой, то есть фактически являются еще одним проходом через все фазы разработки.

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

Методология разработки – подход к созданию и сопровождению информационных систем в виде жизненного цикла ИС, представляющий его в виде последовательности стадий, каждая из которых разбита на этапы, и выполняемых на них процессов.

Методология RUP

Разрабатывайте программное обеспечение итеративно;
Управляйте требованиями;
Используйте компонентную архитектуру;
Визуализируйте модель программы;
Проверяйте качество программы;
Контролируйте изменения программы.

Рис 1. Рабочие процессы RUP

Ядро RUP составляют следующие рабочие процессы, пересечение которых показано на рисунке 1., среди которых 6 процессов инжиниринга и 3 вспомогательных процесса:

бизнес моделирование;
управление требованиями;
проектирование;
реализация;
тестирование;

развертывание.

конфигурационное управление и управление изменениями;
управление проектом;
поддержка среды разработки.

+ Сравнительная легкость описания и наглядность моделей

+ Возможность адаптирования методологии UML собственным элементам и видам диаграмм

+ Возможность автоматической генерации кода на основе построенных моделей при проектировании с использованием case средств, поддерживающих методологию

– Невозможность проведения детального анализа процессов

– Неполнота и незавершенность некоторых видов диаграмм, возможность их неверной интерпретации

Методология MSF

Microsoft Solutions Framework является наиболее сбалансированной технологией, ориентированной на проектные группы малых и средних размеров. MSF не накладывает никаких ограничений на используемый инструментарий и содержит рекомендации весьма общего характера. Однако, эти рекомендации могут быть использованы для построения конкретного процесса, соответствующего потребностям коллектива разработчиков.
MSF включает четыре фазы: анализ, проектирование, разработку, стабилизацию. Она является итерационной, предполагает использование объектно - ориентированного моделирования. MSF по сравнению с RUP в большей степени ориентирована на разработку бизнес - приложений.

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

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

+ снижение воздействия серьёзных рисков на ранних стадиях проекта, что ведет к минимизации затрат на их устранение;

+ непрерывное итеративное тестирование, позволяющее оценить успешность всего проекта в целом;

+ раннее обнаружение конфликтов между требованиями, моделями и реализацией проекта;

- целостное понимание возможностей и ограничений проекта очень долгое время отсутствует.

- при итерациях приходится отбрасывать часть сделанной ранее работы.

Сравнительный анализ методологии RUP и MSF

Сравним две крупные методологии, предназначенные специально для создания корпоративных систем - Rational Unified Process (RUP) и Microsoft Solutions Framework (MSF).

Технология	Оптимальная команда	Соответствие стандартам	Допустимые технологии и инструменты	Удобство модификации и сопровождения
RUP	10-40 чел	Стандарты Rational	UML и продукты Rational	Удобно
MSF	3-20 чел	Адаптируемая	Любые	Удобно

RUP. В основе методологии RUP лежат процессы, причем следует отметить такие особенности методологии, такие особенности подхода, как архитектурную центричность, а также основу на Use Cases – сценариях использования, и итеративность.

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

При этом на первом этапе дела есть высокоуровневые требования и общая концепция программного продукта, но еще нет детальных спецификаций. На втором этапе происходит архитектурное проектирование. На третьей стадии – конструирование или разработка, где и происходит кодирование, тестирование и сборка, разработка всей необходимой документации, для того чтобы релиз в начальном варианте мог быть передан заказчику. На четвертой стадии происходит последовательное уточнение, доработка, переработка, сведение и фиксация всей необходимой документации и кода, для того чтобы продукт был полнофункциональным и был готов к передаче заказчику. Так происходит базовый процесс разработки.

Поскольку RUP – методология строгая, существуют вполне определенные критерии выхода, как из каждой фазы, так и из каждой итерации. Существуют вполне определенные артефакты и вполне определенные метрики, которые описывают степень их готовности. На первой стадии — это основные высокоуровневые требования к системе. На втором этапе – архитектурный проект и, соответственно, диаграммы, которые описывают программный продукт, если на первом этапе это были Use-Сase. На третьем этапе – программное решение в виде кода и документации. И на четвертом этапе – полный релиз, готовый к передаче заказчику.

MSF. Методология MSF основана на гибкой процессной модели и включает в себя командную разработку. Масштабирование, команды команд – это достаточно важные составляющие MSF. Нужно сказать, что MSF поддерживает полный жизненный цикл разработки, т.е. он включает в себя как MSF (Microsoft Solutions Framework), так и MOF (Microsoft Operations Framework), которые объединяют процессы концептуализации, создания, внедрения, сопровождения, расширения, развития программных продуктов.

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

Заключение

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

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

Приведен обзор предсказуемых методологий на примере Rational Unified Process (RUP) и Microsoft Solutions Framework (MSF). Были обсуждены характерные черты этих методологий. Наряду с общими деталями были выявлены также и некоторые сложные моменты процесса разработки, связанные с управлением командой, планированием, стратегией менеджмента, взаимодействием с заказчиком, жизненным циклом программного продукта, внедрением и реализацией выбранной методологии.

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

Список источников

1. Fazar W., Program Evaluation and Review Technique // The American Statistician, Vol. 13 (№ 2), 1959, С. 10.

2. A.A. Ермолаев, В. М. Дёмкин. Управление проектами по разработке программных продуктов.

4. Уокер Ройс. Управление проектами по созданию программного обеспечения. Издательство "Лори", 2002 г. 424 с.

Унифицированный процесс Rational — это универсальная методология распределения задач и сфер ответственности при разработке программного обеспечения. Её цель – создание высококачественного программного обеспечения, отвечающего потребностям и запросам пользователей. Методология RUP была разработана в компании Rational Software Corporation , которую в 2003 году купила IBM .

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

Методология RUP предназначена для крупных проектов разработки, поэтому многие менеджеры уверены, что она не подойдёт для небольших задач, не требующих большого объёма ресурсов. Но есть множество примеров, когда небольшие проекты значительно выигрывали от внедрения RUP .

К примеру, RUP используется в системе управления онлайн-обучением TAP University . Компания поставила перед собой цель расширить область традиционного офлайн-обучения и улучшить свои сервисы для корпоративных, частных пользователей и студентов.

Хотя это был небольшой проект, внедрение методологии RUP показало отличные результаты. Она помогла выстроить набор принципов, необходимых для организации сценариев использования сервисов TAP University , помогла увидеть направления для перехода к третьей, самой важной фазе RUP — построению.

Что такое унифицированный процесс Rational (RUP)?

Работа над процессом – команда разработчиков RUP тесно работает с покупателями, партнёрами и группами компаний, постоянно обновляя методологию.

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

RUP – это инструкция использования Unified Modelling Language (UML) – UML позволяет команде легко донести свои требования к проекту, его архитектуру и план реализации.

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

Шесть основополагающих принципов RUP

В основе RUP лежит шесть главных принципов :

Итеративная модель разработки – устранение рисков на каждой стадии проекта позволяет лучше понять проблему и вносить необходимые изменения, пока не будет найдено приемлемое решение;
Управление требованиями – RUP описывает процесс организации и отслеживания функциональных требований, документации и выбора оптимальных решений ( как в процессе разработки, так и при ведении бизнеса );
Компонентная архитектура – архитектура системы разбивается на компоненты, которые можно использовать как в текущем, так и в будущих проектах;
Визуальное моделирование ПО – RUP методология разработки показывает , как создать визуальную модель программного обеспечения, чтобы понять структуру и поведение архитектуры и его компонентов;
Проверка качества ПО – в процессе разработки программного обеспечения контролируется качество всех действий команды;
Контроль внесённых изменений – отслеживание изменений позволяет выстроить непрерывный процесс разработки. Создаётся благоприятная обстановка, в рамках которой команда будет защищена от изменений в рабочем процессе.

Структура RUP

Данный подход описывает, кто делает что делает, как и когда. RUP можно представить в виде четырёх основных элементов:

Действие — это единица работы, которую может выполнить работник. У каждого действия есть чётко обозначенная цель. Каждое действие назначено определённому работнику. Действия могут включать в себя создание или обновление артефактов, таких как модель, класс или план.

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

Рабочий процесс представляет собой последовательность действий, приводящих к видимому результату. В терминах UML можно представить рабочий процесс как диаграмму последовательности, диаграмму кооперации или диаграмму активности:

Жизненный цикл RUP

Жизненный цикл RUP разбит на четыре основных фазы, в каждой из которых ведётся работа над новым поколением продукта: фазу начала проекта, уточнение, построение и внедрение.

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

Цель этой фазы — анализ требований к системе и её архитектуры, разработка плана проекта и устранение элементов наивысшего риска. Это самая важная фаза из всех, поскольку она знаменует переход от низкого уровня риска к высокому. В рамках этой фазы команда решает, переходить ли к фазе построения ( разработке и написанию кода ) или нет.

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

В конце каждой фазы существует отметка завершения этапа ( Project Milestone ) — момент, когда ваша команда оценивает, достигнуты ли поставленные цели. При этом команда принимает важные решения, влияющие на ход следующей фазы:

Преимущества RUP

Методология RUP позволяет справляться с изменениями в требованиях, независимо от того, исходят они от клиента или возникают в ходе работы над проектом;
RUP подчёркивает необходимость точной документации.
Интеграция требований происходит на протяжении всего процесса разработки, и в частности в фазе построения.

Недостатки RUP

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

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

Дайте знать, что вы думаете по данной теме материала в комментариях. За комментарии, дизлайки, лайки, отклики, подписки огромное вам спасибо!

Дайте знать, что вы думаете по этой теме материала в комментариях. За комментарии, лайки, отклики, подписки, дизлайки огромное вам спасибо!

Пожалуйста, опубликуйте ваши мнения по текущей теме материала. Мы крайне благодарны вам за ваши комментарии, лайки, подписки, отклики, дизлайки!

Аннотация
В данной статье рассматривается история развития методологии Rational Unified Process, разработанной компанией IBM. Приведены теоретические аспекты данной методологии, а также проведен сравнительный анализ с классическим подходом разработки программного обеспечения - "водопадной" моделью. Рассмотрены основные инструменты компании IBM для автоматизации процесса создания сложных систем.

Abstract
The article considers the brief history of the IBM Rational Unfiied Process methodology. The author focuses on the theoretical aspects of the RUP methodology. Besides, the comparative analysis of RUP and the waterfall model has been carried out. The IBM tools for automating the software development are described briefly.

Компания Rational Software сформулировала три основные определения Rational Unified Process (RUP):

Совокупность основополагающих принципов для успешной разработки программного обеспечения. На этих принципах основана методология разработки программного обеспечения.
Среда многоразового содержимого метода и строительных блоков процесса. Определенное и усовершенствованное Rational Software на постоянной основе, семейство RUP модулей метода определяет среду метода, в которой создаются собственные конфигурации метода и специализированные процессы. Это определение подчёркивает, что методология относится к разряду Agile методологий, то есть гибких методологий.
Лежащий в основе язык определения методов и процессов. В основе всего лежит унифицированная метамодель архитектуры метода. Эта модель предоставляет язык описания процессов и содержимого методов. Этот новый язык представляет собой объединение различных языков разработки методов и процессов, включая язык моделирования UML.

Компания Rational Software разработала базу знаний под названием RUP Database, которая включает в себя опыт и рекомендации ведущих компаний-разработчиков для успешного создания крупных систем. Данная база постоянно пополняется и совершенствуется с учетом передового опыта. Компания выпустила целую линейку продуктов, которые являются основными инструментами для применения методологии RUP.

Первоначально Rational Software разработала продукты Rational Approach и Objectory Process 3.8. Впоследствии, в 1995 г. их объединили в единый продукт Rational Unified Objectory.

На рисунке 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)

Лучшие практики включают в себя следующее:

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

Ключевым принципом является итеративный подход при разработке ПО, который напоминает спиралевидную модель. Он позволяет выявлять риски на ранней стадии, устранять крупные риски до вложения крупных инвестиций в проект, обеспечивать постоянную обратную связь с пользователями, развертывать частичные реализации с выпуском промежуточного релиза. На рисунке 4 представлена сравнительная характеристика водопадной модели c методологией RUP.

Для того, чтобы разработать систему, необходимо большую часть времени уделять составлению требований и спецификаций к системе. Исследовательская компания 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.

Связь с автором (комментарии/рецензии к статье)

Оставить комментарий

Вы должны авторизоваться, чтобы оставить комментарий.

Читайте также: