IBM Rational Unified Process：解决方案设计师参考认证指南

需积分: 10 198 浏览量更新于2024-07-31 收藏 3.46MB PDF 举报

"IBM Rational Unified Process Reference and Certification Guide — Solution Designer" 本书《IBM Rational Unified Process Reference and Certification Guide》由Ahmad K. Shuja和Jochen Krebs撰写，是关于IBM Rational Unified Process（RUP）的参考和认证指南，专门针对解决方案设计师。RUP是一种广泛认可的软件开发过程框架，由IBM开发，旨在提供一套结构化的方法论，帮助软件开发团队高效、有序地进行项目管理、需求分析、设计、实现和维护。 RUP的核心理念是通过迭代和增量的开发方式，确保软件产品的质量与适应性。它强调了软件生命周期中的关键实践，如配置和变更管理、软件工程管理、风险管理以及测试等。RUP包含了一系列工作产品、活动和角色，这些元素共同构成了一个完整的软件开发过程模型。在本书中，作者可能会详细阐述以下几个方面： 1. **基础概念**：介绍RUP的基本原理，包括其核心价值、理念和框架结构，以及如何将敏捷开发的原则融入到RUP中。 2. **角色和职责**：详细说明在RUP中不同角色（如业务分析师、系统架构师、开发人员、测试人员等）的职责和协作方式。 3. **生命周期阶段**：描述RUP的四个主要生命周期阶段——初始化、Inception、Elaboration、Construction和Transition，以及每个阶段的目标、交付物和关键任务。 4. **工作流程**：探讨RUP中的关键工作流程，如需求管理、软件架构、实现与构造、测试和质量保证。 5. **最佳实践**：分享在RUP实施过程中的一些最佳实践，以帮助团队提高效率，减少风险，并确保项目成功。 6. **工具支持**：IBM Rational系列工具在RUP中的应用，如Rational Team Concert、Rational Rose等，它们如何支持RUP的工作流程和项目管理。 7. **认证准备**：对于那些寻求IBM Certified Solution Designer - IBM Rational Unified Process v9认证的读者，本书可能提供考试复习指导和案例研究，帮助他们掌握必要的知识和技能。 8. **实例分析**：通过实际项目案例，展示RUP如何在现实世界中应用，以及如何解决在软件开发过程中遇到的问题。这本书不仅适合希望深入了解RUP的软件专业人士，也是准备RUP相关认证考试的绝佳参考资料。IBM Press作为出版方，确保了内容的专业性和权威性。同时，书中的注意事项提醒读者，虽然内容详尽，但不承担任何使用信息可能产生的直接或间接损失的责任。

 Adapt the process.

 Balance stakeholder priorities.

 Collaborate across teams.

 Demonstrate value iteratively.

 Elevate the level of abstraction.

 Focus continuously on quality.

The key principals are not sequential; in fact, you will see in Chapter 2, “Key Principles for

Business-Driven Development,” that the principles actually reinforce each other. For example,

the principle of demonstrating value iteratively supports the principle of focusing continuously on

quality. Similarly, other key principles support and drive one another. Chapter 2 explains all six

key principles in detail and discusses their inter-relationships.

A Framework of Reusable Method Content and Process Building

Blocks

A process framework can be defined as an incomplete support structure in which another

process can be organized and developed. Therefore, you need to finish a process framework

before you can apply it to specific projects within an organization. Similarly, you need to finish

the RUP skeleton and its libraries to fit the organization.

The RUP framework is defined by a family of method plug-ins from which, based on the unique

business needs as well as the context (technical and management complexity), organizations

are able to create their own method configurations and tailored processes. RUP provides an

architectural foundation and wealth of material from which a process definition can be

constructed, therefore enabling the adopting organization to configure and extend that

foundation as desired.

A few factors influence the configuring and tailoring of RUP:

 Project complexity

In most cases, the more complex and technical the project, the greater the formality and

control required to ensure its successful completion and timely delivery. This formality

normally involves greater plan-driven development and more discipline. The term

commonly used in RUP to determine the level of formality and control that is required within

the process is ceremony. Figure 1-2 shows the relationship between complexity and

ceremony. Accordingly, the level of ceremony affects the number of artifacts and details of

the workflow descriptions.

Figure 1-2: Complexity and ceremony

source: IBM Rational Unified Process v7.0

 Organizational maturity

Less mature organizations might require more discipline than more mature ones.

 Organization culture

Culture plays an important role in the successful adaptation and adoption of the process.

 Regulatory compliance and policy requirements

Some industries, especially financial and healthcare, might require more controls, which in

turn require a high ceremony process and more artifacts.

 Development type

The type of software development, such as green field versus COTS based, affects the

process.

 Organization size

The size of the organization determines how to customize the RUP to enable successful

development and timely delivery of the software solutions.

These factors lead to one or more RUP flavors meeting the specific needs of an organization. IT

organizations commonly develop multiple RUP instances to meet the needs of different types of

projects. That approach satisfies the need for different levels of ceremony for small or large IT

projects. In Part IV, we discuss Rational Method Composer, which can be used for effectively

and efficiently customizing and publishing various flavors of RUP. We include some further

discussion within Chapter 13, “Environment.” Even though hundreds, if not thousands, of RUP

customizations have been performed, they are based on the original RUP process framework,

which is the subject of this book and the certification.

Architectural Views

RUP represents the software architecture in multiple architectural views. Each architectural view

addresses concerns specific to stakeholders in the development process. These stakeholders

might include users, designers, managers, and maintainers. The architectural views capture the

major design decisions by presenting the software architecture in terms of how components

connect to produce useful forms (Perry & Wolf, 1992).

The typical set of views in the RUP, called the 4+1 view model, is composed of the following.

 Use-Case view

This view provides a basis for planning the technical content of iterations. It is used in the

Requirements discipline.

 Logical view

This view provides a basis for understanding the structure and organization of the design of

the system. Logical view is used in the Analysis and Design discipline.

 Implementation view

This view captures the enumeration of all subsystems in the Implementation Model, the

component diagrams illustrating how subsystems are organized in layers, and hierarchies

and illustrations showing important dependencies between subsystems.

 Process view

This view illustrates the process decomposition of the system, including the mapping of

classes and subsystems on to processes and threads. The Process view is used in the

Analysis and Design discipline.

 Deployment view

This view illustrates the distribution of processing across a set of nodes in the system,

including physical distribution of processes and threads. This view is used in the Analysis

and Design discipline.

Figure 1-5: The phases and milestones of a RUP project

Overview

As discussed earlier, phases are made up of iterations, and both phases and iterations are

important concepts to grasp for building a concrete understanding of the RUP. Disciplines play

an important role in designing the iterations carried out within each phase. Although we do

discuss disciplines later, let’s briefly see how the RUP defines the term discipline. According to

the RUP, “a discipline is a collection of related activities that are related to a major area of

concern.” Based on which phase you are in, each iteration contains activities from across

different disciplines. For instance, earlier in the RUP lifecycle, although there is a focus on the

development of an executable build as early in the lifecycle as possible, there is a greater need

to build an understanding of the business problem or opportunity. Therefore, this need, as

shown in the hump chart, requires more activities from the Business Modeling and

Requirements disciplines to be performed earlier in the RUP project lifecycle.

Iterations are designed and executed with certain goals in mind. Depending upon which phase

the iteration belongs to, the iteration goals are aligned to accomplish the respective milestone.

For example, iterations for the Elaboration phase are designed such that its objectives are

achieved and the Lifecycle Architecture milestone is accomplished. Therefore, achievement of

each iteration goal moves the project closer to achieving the respective objectives of that phase.

This concept is presented in Figure 1-6. Each iteration has its own respective goals and is

designed such that collectively, the iterations are executed within a given phase. These

iterations achieve respective objectives of a milestone.

Figure 1-6: Iterations achieve objectives of phase milestone

Phases need to end with accomplishment milestones, as shown in Figure 1-5. Each milestone

provides a critical decision point, or a go or no-go. Chapter 14, “Phases, Activities, and

Milestones,” discusses in detail all four phases and their respective objectives and evaluation

criteria. Here, we will briefly review these phases. Please note that phases are executed in a

sequence, as shown in Figure 1-5.

剩余283页未读，继续阅读

westlwt

粉丝: 0
资源: 3

IBM Rational Unified Process：解决方案设计师参考认证指南

IBM Rational 培训资料

Rational unified process

Rational Unified Process 2000

Rational Unified Process模板

UML: Rational Unified Process

Rational Unified Process.ppt

Rational Unified Process十大要素

Rational Unified Process for Systems Engineering

Rational unified process（软件工程概论）

RUP(Rational Unified Process)英文模板

最新资源