Рациональный унифицированный процесс разработки программных продуктов Rational Unified Process

Методология Rational Unified Process (RUP) опирается на проверенные практикой методы анализа, проектирования и разработки программных продуктов, предполагает итерационный характер разработки программного продукта (рис. 19.4).

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

• ? формирование общего видения и целей ИТ-проекта, оценку бизнес-перспектив и влияния проекта на бизнес-цели предприятия;
• ? управление запросами на изменение требований;
• ? управление работами, ресурсами и бюджетом ИТ-проекта;
• ? управление рисками ИТ-проекта;

Рис. 19.4. Схема применения методологии проектирования RUP

• ? построение гибкой и надежной архитектуры системы;
• ? акцент на продукте как конечной цели проекта, его качестве;
• ? документирование проектных решений.

Процесс управления требованиями к программному продукту включает в себя следующие фазы: выявление требований, анализ и организация реализации требований, документирование реализованных требований. Для успешной и своевременной реализации требований необходима система учета требований, определение их значимости, взаимного влияния и возможных изменений. Методология RUP обеспечивает единое понимание ожидаемых функциональных возможностей, уровня качества программного продукта как разработчиками, так и заказчиком, осуществляет управление затратами и графиками выполнения работ. Мониторинг хода работ проекта основан на контроле изменений требований, своевременной реакции на возникающие проблемы. Также RUP поддерживает компонентно-ориентированный подход. Компоненты^[1] — это нетривиальные модули или подсистемы, которые выполняют конкретную функцию и могут быть использованы многократно. В составе программного продукта можно выделить относительно самостоятельные части, такие, как интерфейс пользователя (экранные формы, панели инструментов, языки запросов и др.); программные модули (библиотеки процедур, функций, объектов ActiveX, библиотеки классов объектов и др.); дополнительно загружаемые компоненты (надстройки, макросы, плагины, скрипты и т. п.), драйверы устройств, памяти, форматов файлов и др. Особенность RUP — визуальное проектирование программных продуктов на основе унифицированного языка моделирования.

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

Жизненный цикл проекта RUP. Структура жизненного цикла проекта RUP — сочетание времени жизни проекта и вида деятельности (рис. 19.5).

	Процесс.	Фаза проекта.
		Разработка технического задания.	Техническое проектирование.	Создание.	Внедрение.
Основные процессы.	Моделирование бизнес-процессов.
	Управление требованиями.
	Анализ и проектирование.
	Реализация.
	Тестирование.
	Развертывание.
Вспомогательные процессы.	Конфигурационное управление и управление изменениями.
	Управление проектом.
	Управление средой.
Итерации.		1 2.	3 4.		п

¹ История создания UML начинается в 1994 г., авторы языка — Гради Буч, Джеймс Рамбо, Айвар Якобсон. Версия UML 1.4.2 принята в качестве международного стандарта ISO/IEC 19 501:2005. Версия UML 2.0 (2006 г.) дополнена поддержкой методологии Model Driven Development.

Рис. 19.5. Жизненный цикл проекта по методологии RUP

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

Компания «IBM Rational» разработала инструментальное средство для многоуровневого моделирования IBM Rational Software Modeler с возможностью автоматизированного преобразования моделей, применения готовых шаблонов (Patterns) и лучших проектных решений. Инструментарий поддерживает архитектуру, управляемую моделями, — Model Driven Architecture (MDA), которая расширяет возможности графического моделирования, дизайна и проектирования. Инструментальное средство IBM Rational Software Architect (RSA) включает в себя всю функциональность IBM Rational Software Modeler и имеет возможность автоматизированного преобразования моделей в программный код (C++, Java). Решения построены на базе Eclipse, платформы с открытым исходным кодом, поэтому можно постепенно наращивать функциональность программного продукта, обеспечить поддержку использования модулей расширения независимых разработчиков (Plug-In), работать в двух операционных средах (Windows, Linux). К инструментальным средствам моделирования относится и пакет IBM WebSphere® Business Integration Modeler (WBI Modeler), обеспечивающий моделирование бизнес-процессов.

Эффективное управление требованиями — ключевой фактор процесса разработки программного продукта. К основным целям процесса управления требованиями относят:

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

Основным инструментом для организации работы с требованиями в проекте является IBM Rational RequisitePro, который позволяет организовать контролируемый доступ к требованиям, быть в курсе текущих требований, их контекста и связей, быстро и качественно создавать программные продукты.

Инструментальное средство Rational RequisitePro предоставляет возможность работы в режимах стандартного интерфейса Windows, Web-интерфейса (собственный Rational RequisiteWeb), поддерживает доступ, добавление и коррекцию требований через обычный Web-браузер. Документы для отражения требований, содержащие контекстную и дополнительную информацию, готовятся в редакторе Microsoft Word, хранятся в отдельной базе требований. Авторы требований могут составлять, просматривать, редактировать и работать с этими документами без необходимости доступа к базе требований, а сами документы автоматически синхронизируются с проектом при их возвращении в проект. Можно ограничить типы требований, задать стандартные и дополнительные атрибуты (приоритет, сложность, состояние, ответственность за реализацию и др.) для эффективного управления требованиями. С помощь средств визуального контроля изменений в требованиях отслеживается влияние любых изменений на артефакты ИТ-проекта, ведется история изменений требований. Анализ требований выполняется для выявления тенденций их изменения, получения отчетов о степени готовности и оценок состояния ИТ-проекта.

Интеграция Rational RequisitePro с Rational Software Modeler связывает требования с визуальными моделями. Участники проекта могут легко формировать требования верхнего уровня на основании существующих прецедентов и детализировать эти требования с помощью анализа сценариев указанных прецедентов. Интеграция Rational RequisitePro с Rational Rose связывает требования с визуальными моделями. Участники проекта могут легко формировать требования верхнего уровня на основании существующих прецедентов и детализировать эти требования с помощью анализа сценариев указанных прецедентов. Интеграция Rational RequisitePro и Rational ClearQuest облегчает внесение изменений в проект, связывая запросы на изменения с требованиями, определенными на базе первых. При этом легко получить набор требований, связанных с конкретным запросом на изменение, и наоборот, набор запросов на изменения, связанных с конкретным требованием. Интеграция Rational RequisitePro с Rational ClearCase позволяет организовать эффективный версионный контроль проектных требований. Интеграция Rational RequisitePro с Rational TestManager гарантирует, что на основе существующих требований тестировщиками или специалистами по контролю качества будут созданы необходимые сценарии тестирования. Интеграция Rational RequisitePro с Rational SoDA позволяет автоматизировать создание проектных отчетов по требованиям, используя шаблоны оформления документов, принятые в организации. Интеграция Rational RequisitePro с Microsoft Project помогает наладить планирование в проекте в кратчайшие сроки. Требования — это то, что должно быть реализовано, а значит, на их основе можно определить задачи для участников проекта и спланировать их выполнение.

При разработке программного продукта создается исходный код в виде программных модулей (исходных, двоичных, исполняемых файлов и др.), который подвергается тестированию. В конце разработки выполняется интеграция результатов работы отдельных программистов (или групп) в рабочую систему. Продукт IBM Rational предлагает набор специализированных инструментальных средств разработки исходных кодов: IBM Rational Application Developer, IBM Rational Web Developer, IBM Rational XDE Developer.

Тестирование программных продуктов является трудоемким процессом и часто проводится без определенной методики, в условиях отсутствия соответствующих инструментальных средств. Стоимость тестирования программного обеспечения составляет 30—50% общей стоимости разработки. В RUP принята следующая базовая классификация видов тестирования:

1. Функциональное тестирование, в том числе: непосредственно функциональное тестирование (Function testing), тестирование целостности данных (Data Integrity Testing), тестирование на разных платформах (Configuration Testing), тестирование отказоустойчивости (Failover & Recovery Testing), тестирование доступа (Security Testing), инсталляционное тестирование (Installation Testing), тестирование пользовательского интерфейса (User Interface Testing).^[2]

Functional Tester—средство функционального тестирования, IBM Rational Manual Tester — средство для организации и проведения ручного тестирования и др.).

Интеграция инструментальных средств RequisitePro и TestManager позволяет сформировать план и сценарии тестирования, дополнить их тестовыми скриптами, которые формируются с помощью IBM Rational Robot в целях автоматизации процесса тестирования. Для проведения расширенного функционального и регрессионного тестирования Javaи Web-приложений существует инструмент IBM Rational XDE Tester. Для автоматизации процесса создания необходимых отчетов используется Seagate Crystal Report или IBM Rational SoDA. Анализ работы систем, построенных с помощью языков C/C+ +, Microsoft Visual Basic, Java, C#.NET, VB. NET и Java.NET, можно осуществлять с помощью средств IBM Rational Purify, Quantify и PureCoverage. Средство автоматизированного тестирования IBM Rational TestFactory предназначено для анализа графического интерфейса пользователя (GUI) и генерации полного набора тестов, позволяющего провести максимально полное функциональное тестирование.

Управление проектами и портфелями IBM Rational. Разработка программного продукта представляет собой проект, управление которым основано на методологии Project Management. Для ИТ-проекта осуществляется планирование состава и сроков проектных работ, подбор персонала, разработка бюджета проекта, управление рисками ИТ-проекта с использованием методов Risk Management.

Портфель проектов — объединение нескольких ИТ-проектов, использующих общие ресурсы («ресурсный пул»), взаимосвязанных между собой. Инструментальное средство IBM Rational Portfolio Manager представляет собой мощное серверное приложение управления портфелем проектов, поддерживает Web-доступ, использует специальный репозиторий портфеля проектов, реализует все методы управления проектами. В реальном времени оно позволяет получать информацию о ходе выполнения отдельных проектов и портфеля проектов в целом. Средство IBM Rational Portfolio Manager может интегрироваться с другими решениями IBM (WebSphere, Tivoli и Lotus) и поддерживать известные модели и стандарты управления (Sarbanes/Oxley, Six Sigma, Application Portfolio Management, Product Lifecycle Management и т. п.).

В зависимости от масштаба ИТ-проекта используются различные функциональные возможности IBM Rational Portfolio Manager.

Так, для небольшого проекта выполняются функции: Document (документирование), Issues (расчет результатов) и Risk Management (управление рисками), Process Work Flows (поддержка потоков работ процесса). Для управления крупными проектами могут потребоваться все функции Rational Portfolio Manager:

• ? управление портфелем (Portfolio Management);
• ? управление стандартными проектами (Standard Project Management);
• ? интеграция с Microsoft Project;
• ? интеграция с IBM Rational RequisitePro;
• ? методы многократного использования (Reusable Methods) в виде шаблонов проектов и шаблонов документов;
• ? методы управления рисками (Risk Management), включая сбор и отображение информации о рисках, связанных с проектом, анализ возможности сокращения рисков;
• ? методы управления ресурсами (Resource Management);
• ? методы управления данными о персонале (сбор и отслеживание времени выполнения работ);
• ? методы учета затрат;
• ? составление графика загрузки сотрудников; и др.

Средство IBM Rational Portfolio Manager позволяет документировать процесс управления проектами, ведет бухгалтерский учет по проекту, поддерживает совместную работу над проектом.

Основными пользователями Rational Portfolio Manager являются менеджеры проектов, члены команд проектов (получение заданий, отчетность о выполнении заданий), руководители проектов, менеджеры ресурсов.

• [1] Как правило, компоненты соответствуют одной из промышленных спецификаций, таким как CORBA, COM/DCOM, ActiveX, Enterprise Java Beans и др. Наиболее популярная технология COM (Component Object Model), объектная моделькомпонентов, технологический стандарт компании «Microsoft» (1993) обеспечивает связывание и внедрение программных объектов, которые одновременно могут использоваться в других приложениях согласно принципам объектно-ориентированного программирования. Технология СОМ послужила основой для реализации стандартов OLE Automation, ActiveX, DCOM, COM4- и др. Технология DCOM (Distributed СОМ) является альтернативой технологии CORBA (Common Object Request Broker Architecture), применяется в условиях распределенной обработки данных. Она позволяет COM-компонентам взаимодействовать друг с другом по сети. Для создания приложений и компонентов под Windows может применяться платформа .NET в которую вошли средства, позволяющие обращаться к компонентамСОМ из приложений .NET, и наоборот. Операционная система Windows Vista построена с использованием технологий .NET и COM4-.
• [2] Нагрузочное тестирование, включая: непосредственно нагрузочное тестирование (Load Testing), профилирование производительности (Performance Profiling), тестирование циклаработы (Business Cycle Testing), тестирование при большойпользовательской нагрузке (Stress Testing), тестированиена больших объемах данных (Volume Testing). Для автоматизации процессов тестирования IBM Rational предлагает различные инструментальные средства (IBM Rational Performance Tester — средство нагрузочного тестирования; IBM Rational