Rational Unified Process, как продукт, состоит из:

• Размещаемой на Web базы знаний, которая состоит из руководств, шаблонов, наставлений по использованию инструментальных средств, и которая может быть разбита на:

• Обширные руководства для всех членов коллектива разработчиков, для каждого временного интервала жизненного цикла ПО. Руководства представлены в двух видах: для осмысления процесса на верхнем уровне, и в виде подробных наставлений по повседневной деятельности. Руководства опубликованы в HTML формате.

• Наставления по пользованию инструментальными средствами, которые автоматизируют большие разделы процесса создания ПО. Наставления опубликованы в HTML формате.

• Примеры и шаблоны для Rational Rose, которые служат руководствами по тому, как структурировать информацию в Rational Rose при следовании указаниям RUP.

• Шаблоны для SoDa – более десятка шаблонов для SoDa, которые помогают автоматизировать документирование ПО.

• Microsoft Word шаблоны – более 30 шаблонов, которые предназначены для поддержки документации по всем последовательностям действий и интервалам жизненного цикла ПО.

• Планы в формате Microsoft Project – для тех, кому трудно сразу перейти к созданию планов - отражают итерационную разработку. Данные документы помогают произвести такой переход.

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

• Доступ к Resource Center, который содержит последние публикации, обновления, подсказки, методики, а также ссылки на add-on и сервисы.

• Книги Ph. Kruchten - Rational Unified Process-An Introduction. Книга содержит 277 страниц и является хорошим вступлением и обзором к процессу и базе знаний.

Ниже представлен список продуктов, которые поддерживают Rational Unified Process:

• Rational Requisite Pro - поддерживает обновления и отслеживает изменения в требованиях для всего коллектива разработчиков, представляя их в удобном виде для чтения, обсуждения и изменений.

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

• Rational Rose 98 - мировой лидер среди средств визуального моделирования для бизнес процессов, анализа требований, и проектирования на основе архитектуры компонентов.

• Rational SoDA - автоматизирует создание документации для всего процесса разработки ПО, значительно сокращая стоимость документации и время на ее создание.

• Rational Purify - средство поиска ошибок на run-time для разработчиков приложений и компонентов, программирующих на C/C++; помогает находить ошибки утечки памяти.

• Rational Visual Quantify - средство измерения характеристик для разработчиков приложений и компонентов, программирующих на C/C++, Visual Basic и Java; помогает определять и устранять узкие места в производительности ПО.

• Rational Visual PureCoverage - автоматически определяет области кода, которые не подвергаются тестированию; разработчики могут учесть это и более тщательно выполнять проверку.

• SQA TeamTest - создает, обслуживает и выполняет автоматизированные функциональные тесты, позволяя тщательно протестировать код и проверить, соответствует ли ПО предъявляемым к нему требованиям.

• Rational PerformanceStudio - простое в использовании, точное и масштабируемое средство, которое измеряет и предсказывает характеристики клиент/серверных и Web систем.

• Rational ClearCase - лидирующее на рынке средство конфигурационного управления, позволяющее менеджерам проекта отслеживать эволюцию каждого разрабатываемого проекта.

Циклы разработки ПО

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

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

• Фаза проработки проекта: планирование необходимых работ и требуемых ресурсов; определение возможностей, проектирование и создание базовой версии архитектуры.

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

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

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

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

Эти фазы являются обязательными и через них нельзя перешагнуть; хотя в некоторых случаях проводимые в них работы можно сократить до минимума, но практически никогда невозможно сократить до нуля. Не заблуждайтесь относительно "узловой диаграммы" методологии RUP (рис. 1); эта диаграмма не учитывает факта, что вы уже затратили определенное количество времени и денег на то, чтобы выполнить часть работ. Вот один из ключевых принципов RUP: “Не делайте ничего, не имея перед собой цели.”

Рис. 1."Узловая диаграмма" методологии RUP

Давайте, например, предположим, что вы только что вышли из фазы обследования, и поняли, что имеются все предпосылки для выхода из фазы проработки проекта:

• Требования понимаются однозначным образом.

• В дальнейшем архитектура не будет изменяться.

• Имеется план первой итерации фазы построения системы.

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

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

 

Рис. 2. Версия 1.0: цикл начальной разработки

Циклы развития

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

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

3.Oracle Designer

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

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

Графические модели определений проекта, интегрированные с многопользовательским репозиторием существенно облегчают работу с Oracle Designer. Инструментальные средства построены на базе общепринятых методик, охватывающих весь жизненный цикл разработки и позволяющих пользователям привычным для их организации способом. Это обеспечивает гибкость и открытость подхода к разработке программного обеспечения за счет использования только тех частей продукта, которые требуются в данной задаче. В рамках процесса разработки обеспечивается поддержка методов RAD, JAD, информационного проектирования, водопадного метода (waterfall), итеративного метода, а также индивидуального подхода, выбранного компанией.

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

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