The Unified Software Development Process (Hardcover)
暫譯: 統一軟體開發過程 (精裝版)

Ivar Jacobson, Grady Booch, James Rumbaugh

  • 出版商: Addison Wesley
  • 出版日期: 1999-02-14
  • 定價: $1,250
  • 售價: 9.8$1,225
  • 語言: 英文
  • 頁數: 512
  • 裝訂: Hardcover
  • ISBN: 0201571692
  • ISBN-13: 9780201571691
  • 立即出貨 (庫存=1)

買這商品的人也買了...

相關主題

商品描述


Description

This landmark book provides a thorough overview of the Unified Process for software development, with a practical focus on modeling using the Unified Modeling Language. The Unified Process goes beyond mere object-oriented analysis and design to spell out a proven family of techniques that supports the complete software development life cycle. The result is a component-based process that is use-case driven, architecture-centric, iterative, and incremental. The Unified Process takes full advantage of the industry-standard Unified Modeling Language. This book demonstrates how the notation and process complement one another, using UML models to illustrate the new process in action. The authors clearly describe the semantics and notation of the different higher-level constructs used in the models. Constructs such as use cases, actors, subsystems, classes, interfaces, active classes, processes, threads, nodes, and most relations are described in the context of a model. Object technology practitioners and software engineers familiar with the authors' past work will appreciate The Unified Software Development Process as a useful means of learning the current best practices in software development.

Back to Top


Appropriate Courses

Unified Modeling Language (UML).

Back to Top


Table Of Contents

Preface.

I. THE UNIFIED SOFTWARE DEVELOPMENT PROCESS.

1. The Unified Process: Use-Case Driven, Architecture-Centric, Iterative, and Incremental.
The Unified Process in a Nutshell.
The Unified Process Is Use-Case Driven.
The Unified Process Is Architecture-Centric.
The Unified Process Is Iterative and Incremental.
The Life of the Unified Process.
The Product.
Phases within a Cycle.

An Integrated Process.

2. The Four Ps: People, Project, Product, and Process in Software Development.
People Are Crucial.
Development Processes Affect People.
Roles Will Change.
Turning “Resources” into “Workers.”

Projects Make the Product.
Product Is More Than Code.
What Is a Software System?
Artifacts.
A System Has a Collection of Models.
What Is a Model?
Each Model Is a Self-Contained View of the System.
Inside a Model.
Relationships between Models.

Process Directs Projects.
Process: A Template.
Related Activities Make Up Workflows.
Specializing Process.
Merits of Process.

Tools Are Integral to Process.
Tools Impact Process.
Process Drives Tools.
Balance Process and Tools.
Visual Modeling Supports UML.
Tools Support the Whole Life Cycle.

References.

3. A Use-Case-Driven Process.
Use-Case-Driven Development in Brief.
Why Use Cases?
To Capture the Value Adding Requirements.
To Drive the Process.
To Devise the Architecture and More...

Capturing the Use Cases.
The Use-Case Model Represents the Functional Requirements.
Actors Are the Environment of the System.
Use Cases Specify the System.

Analysis, Design, and Implementation to Realize the Use Cases.
Creating the Analysis Model from the Use Cases.
Each Class Must Fulfill All Its Collaboration Roles.
Creating the Design Model from the Analysis Model.
Subsystems Group Classes.
Creating the Implementation Model from the Design Model.

Testing the Use Cases.
Summing Up.
References.

4. An Architecture-Centric Process
Architecture in Brief.
Why We Need Architecture.
Understanding the System.
Organizing Development.
Fostering Reuse.
Evolving the System.

Use Cases and Architecture.
The Steps to an Architecture.
The Architecture Baseline Is a “Small, Skinny” System.
Using Architecture Patterns.
Describing Architecture.
The Architect Creates the Architecture.

Finally, an Architecture Description!
The Architectural View of the Use-Case Model.
The Architectural View of the Design Model.
The Architectural View of the Deployment Model.
The Architectural View of the Implementation Model.
Three Interesting Concepts.
What Is Architecture?
How Is It Obtained?
How Is It Described?

References.

5. An Iterative and Incremental Process.
Iterative and Incremental in Brief.
Develop in Small Steps.
What Iteration Is Not.

Why Iterative and Incremental Development?
Mitigating Risks.
Getting a Robust Architecture.
Handling Changing Requirements.
Allowing for Tactical Changes.
Achieving Continuous Integration.
Attaining Early Learning.

The Iterative Approach is Risk-Driven.
Iterations Alleviate Technical Risks.
Management Is Responsible for Nontechnical Risks.
Dealing with Risks.

The Generic Iteration.
What an Iteration Is.
Planning the Iterations.
Sequencing the Iterations.

The Result of an Iteration Is an Increment.
Iterations over the Life Cycle.
Models Evolve from Iterations.
Iterations Challenge the Organization.
References.

II. THE CORE WORKFLOWS.


6. Requirements Capture: From Vision to Requirements.
Why Requirements Capture Is Difficult.
The Purpose of the Requirements Workflow.
Overview of Requirements Capture.
The Role of Requirements in the Software Life Cycle.
Understanding the System Context Using a Domain Model.
What Is a Domain Model?
Developing a Domain Model.
Use of the Domain Model.

Understanding the System Context Using a Business Model.
What Is a Business Model?
How to Develop a Business Model.
Find Use Cases from a Business Model.

Supplementary Requirements.
Summary.
References.

7. Capturing the Requirements as Use Cases.
Introduction.
Artifacts.
Artifact: Use-Case Model.
Artifact: Actor.
Use Case.
Artifact: Architecture Description (View of the Use-Case Model).
Artifact: Glossary.
Artifact: User-Interface Prototype.

Workers.
Worker: System Analyst.
Worker: Use-Case Specifier.
User-Interface Designer.
Worker: Architect.

Workflow.
Activity: Find Actors and Use Cases.
Activity: Prioritize Use Cases.
Activity: Detail a Use Case.
Activity: Prototype User Interface.
Activity: Structure the Use-Case Model.

Summary of the Requirements Workflow.
References.

8. Analysis.
Introduction.
Analysis in Brief.
Why Analysis Is not Design or Implementation.
The Purpose of Analysis: Summary.
Concrete Examples of When to Employ Analysis.

The Role of Analysis in the Software Life Cycle.
Artifacts.
Artifact: Analysis Model.
Artifact: Analysis Class.
Artifact: Use-Case Realization—Analysis.
Artifact: Analysis Package.
Artifact: Architecture Description (View of the Analysis Model).

Workers.
Worker: Architect.
Worker: Use-Case Engineer.
Worker: Component Engineer.

Workflow.
Activity: Architectural Analysis.
Activity: Analyze a Use Case.
Activity: Analyze a Class.
Activity: Analyze a Package.

Summary of Analysis.
References.

9. Design.
Introduction.
The Role of Design in the Software Life Cycle.
Artifacts.
Artifact: Design Model.
Artifact: Design Class.
Artifact: Use-Case Realization—Design.
Artifact: Design Subsystem.
Artifact: Interface.
Artifact: Architecture Description (View of the Design Model).
Artifact: Deployment Model.
Artifact: Architecture Description (View of the Deployment Model).

Workers.
Worker: Architect.
Worker: Use-Case Engineer.
Worker: Component Engineer.

Workflow.
Activity: Architectural Design.
Activity: Design a Use Case.
Activity: Design a Class.
Activity: Design a Subsystem.

Summary of Design.
References.

10. Implementation.
Introduction.
The Role of Implementation in the Software Life Cycle.
Artifacts.
Artifact: Implementation Model.
Artifact: Component.
Artifact: Implementation Subsystem.
Artifact: Interface.
Artifact: Architecture Description (View of the Implementation Model).
Artifact: Integration Build Plan.

Workers.
Worker: Architect.
Worker: Component Engineer.
Worker: System Integrator.

Workflow.
Activity: Architectural Implementation.
Activity: Integrate System.
Activity: Implement a Subsystem.
Activity: Implement a Class.
Activity: Perform Unit Test.

Summary of Implementation.
References.

11. Test.
Introduction.
The Role of Testing in the Software Life Cycle.
Artifacts.
Artifact: Test Model.
Artifact: Test Case.
Artifact: Test Procedure.
Artifact: Test Component.
Artifact: Plan Test.
Artifact: Defect.
Artifact: Evaluate Test.

Workers.
Worker: Test Designer.
Worker: Component Engineer.
Worker: Integration Tester.
Worker: System Tester.

Workflow.
Activity: Plan Test.
Activity: Design Test.
Activity: Implement Test.
Activity: Perform Integration Test.
Activity: Perform System Test.
Activity: Evaluate Test.

Summary of Testing.
References.

III. ITERATIVE AND INCREMENTAL DEVELOPMENT.


12. The Generic Iteration Workflow.
The Need for Balance.
The Phases Are the First Division of Work.
Inception Phase Establishes Feasibility.
Elaboration Phase Focuses on “Do-Ability.”
Construction Phase Builds the System.
Transition Phase Moves into the User Environment.

The Generic Iteration Revisited.
Core Workflows Repeat in Each Iteration.
Workers Participate in the Workflows.

Planning Precedes Doing.
Plan the Four Phases.
Plan the Iterations.
Think Long Term.
Plan the Evaluation Criteria.

Risks Affect Project Planning.
Manage a Risk List.
Risks Affect the Iteration Plan.
Schedule Risk Action.

Use-Case Prioritization.
Risks Specific to a Particular Product.
Risk of Not Getting the Architecture Right.
Risk of Not Getting Requirements Right.

Resources Needed.
Projects Differ Widely.
A Typical Project Looks Like This.
Complex Projects Have Greater Needs.
New Product Line Calls for Experience.
Paying the Cost of the Resources Used.

Assess the Iterations and Phases.
Criteria Not Achieved.
The Criteria Themselves.
The Next Iteration.
Evolution of the Model Set.


13. Inception Launches the Project.
The Inception Phase in Brief.
Early in the Inception Phase.
Before the Inception Phase Begins.
Planning the Inception Phase.
Expanding the System Vision.
Setting the Evaluation Criteria.

The Archetypal Inception Iteration Workflow.
Introduction to the Five Core Workflows.
Fitting the Project into the Development Environment.
Finding Critical Risks.

Execute the Core Workflows, Requirements to Test.
Capture the Requirements.
Analysis.
Design.
Test.

Make the Initial Business Case.
Outline Business Bid.
Estimate Return on Investment.

Assess the Iteration(s) in the Inception Phase.
Planning the Elaboration Phase.
The Deliverables for the Inception Phase.

14. The Elaboration Phase Makes the Architectural Baseline.
The Elaboration Phase in Brief.
Early in the Elaboration Phase.
Planning the Elaboration Phase.
Building the Team.
Modifying the Development Environment.
Setting Evaluation Criteria.

The Archetypal Elaboration Iteration Workflow.
Capture and Refine Most of the Requirements.
Develop the Architectural Baseline.
Iterate While the Team Is Small.

Execute the Core Workflows—Requirements to Test.
Capture the Requirements.
Analysis.
Design.
Implementation.
Test.

Make the Business Case.
Prepare the Business Bid.
Update Return on Investment.

Assess the Iterations in the Elaboration Phase.
Planning the Construction Phase.
The Key Deliverables.

15. Construction Leads to Initial Operational Capability.
The Construction Phase in Brief.
Early in the Construction Phase.
Staffing the Phase.
Setting the Evaluation Criteria.

The Archetypal Construction Iteration Workflow.
Execute the Core Workflows—Requirements to Testing.
Requirements.
Analysis.
Design.
Implementation.
Test.

Controlling the Business Case.
Assess the Iterations and the Construction Phase.
Planning the Transition Phase.
The Key Deliverables.

16. Transition Completes Product Release.
The Transition Phase in Brief.
Early in the Transition Phase.
Planning the Transition Phase.
Staffing the Transition Phase.
Setting the Evaluation Criteria.

The Core Workflows Play a Small Role in this Phase.
What We Do in the Transition Phase.
Getting the Beta Release Out.
Installing the Beta Release.
Responding to the Test Results.
Adapting the Product to Varied User Environments.
Completing the Artifacts.
When Does the Project End?

Completing the Business Case.
Controlling Progress.
Review of the Business Plan.

Assess the Transition Phase.
Assess the Iterations and the Phase.
Postmortem of the Project.

Planning the Next Release or Generation.
The Key Deliverables.

17. Making the Unified Process Work.
The Unified Process Helps You Deal with Complexity.
The Life Cycle Objectives.
The Life Cycle Architecture.
Initial Operational Capability.
Product Release.

The Major Themes.
Management Leads Conversion to Unified Process.
The Case for Action.
The Reengineering Directive Persuades.
Implementing the Transition.

Specializing the Unified Process.
Tailoring the Process.
Filling in the Process Framework.

Relate to the Broader Community.
Get the Benefits of the Unified Process.
References.

Appendix A: Overview of the UML.
Introduction.
Vocabulary.
Extensibility Mechanisms.

Graphical Notation.
Structural Things.
Behavioral Things.
Grouping Things.
Annotational Things.
Dependency Relationships.
Association Relationships.
Generalization Relationships.
Extensibility Mechanisms.

Glossary of Terms.
References.

Appendix B: The Unified Process-Specific Extensions of the UML.
Introduction.
Stereotypes.
Tagged Values.
Graphical Notation.
References.

Appendix C: General Glossary.
Introduction.
Terms.

Index. 0201571692T04062001


Back to Top

商品描述(中文翻譯)

這本具有里程碑意義的書籍提供了統一過程(Unified Process)在軟體開發中的全面概述,並著重於使用統一建模語言(Unified Modeling Language)進行建模的實用性。統一過程不僅僅是物件導向分析和設計,而是詳細說明了一套經過驗證的技術家族,支持完整的軟體開發生命週期。其結果是一個基於元件的過程,驅動於用例(use-case)、以架構為中心、迭代和增量式的。統一過程充分利用了行業標準的統一建模語言。本書展示了符號和過程如何相輔相成,使用UML模型來說明新過程的實際運作。作者清楚地描述了模型中使用的不同高階構造的語義和符號。用例、角色、子系統、類別、介面、主動類別、過程、執行緒、節點及大多數關係等構造在模型的背景下進行描述。熟悉作者過去工作的物件技術從業者和軟體工程師將會欣賞《統一軟體開發過程》作為學習當前最佳實踐的有用工具。

適合的課程
統一建模語言(UML)。

目錄
前言。
I. 統一軟體開發過程。
1. 統一過程:以用例驅動、以架構為中心、迭代和增量。
統一過程簡介。
統一過程是以用例驅動的。
統一過程是以架構為中心的。
統一過程是迭代和增量的。
統一過程的生命週期。
產品。
週期內的階段。
一個整合的過程。

2. 四個P:人員、專案、產品和過程在軟體開發中的角色。
人員至關重要。
開發過程影響人員。
角色將會改變。
將「資源」轉變為「工作者」。
專案造就產品。
產品不僅僅是程式碼。
什麼是軟體系統?
工件。
系統擁有一組模型。
什麼是模型?
每個模型都是系統的自包含視圖。
模型內部。
模型之間的關係。
過程指導專案。
過程:一個模板。
相關活動構成工作流程。
專業化過程。
過程的優點。
工具是過程的不可或缺部分。
工具影響過程。
過程驅動工具。
平衡過程和工具。
視覺建模支持UML。
工具支持整個生命週期。
參考文獻。

3. 一個以用例驅動的過程。
以用例驅動的開發簡介。
為什麼使用用例?
捕捉增值需求。
驅動過程。
設計架構及更多...
捕捉用例。
用例模型代表功能需求。
角色是系統的環境。
用例指定系統。
分析、設計和實現以實現用例。
從用例創建分析模型。
每個類別必須滿足其所有協作角色。
從分析模型創建設計模型。
子系統分組類別。
從設計模型創建實現模型。
測試用例。
總結。
參考文獻。

4. 一個以架構為中心的過程。
架構簡介。
為什麼我們需要架構。
理解系統。
組織開發。
促進重用。
演進系統。
用例和架構。
架構的步驟。
架構基線是一個「小而瘦」的系統。
使用架構模式。
描述架構。
架構師創建架構。
最後,架構描述!
用例模型的架構視圖。
設計模型的架構視圖。
部署模型的架構視圖。
實現模型的架構視圖。
三個有趣的概念。
什麼是架構?
如何獲得架構?
如何描述架構?
參考文獻。

5. 一個迭代和增量的過程。
迭代和增量簡介。
小步驟開發。
什麼不是迭代。
為什麼選擇迭代和增量開發?
減輕風險。
獲得穩健的架構。
處理變更需求。
允許戰術變更。
實現持續整合。
獲得早期學習。
迭代方法是風險驅動的。
迭代減輕技術風險。
管理層負責非技術風險。
處理風險。
通用迭代。
什麼是迭代。
計劃迭代。
排列迭代的順序。
迭代的結果是增量。
生命週期中的迭代。
模型從迭代中演變。
迭代挑戰組織。
參考文獻。

II. 核心工作流程。
6. 需求捕捉:從願景到需求。
為什麼需求捕捉困難。
需求工作流程的目的。
需求捕捉概述。
需求在軟體生命週期中的角色。
使用領域模型理解系統上下文。
什麼是領域模型?
開發領域模型。
領域模型的使用。
使用商業模型理解系統上下文。
什麼是商業模型?
如何開發商業模型。
從商業模型中找到用例。
補充需求。
總結。
參考文獻。

7. 將需求捕捉為用例。
介紹。
工件。
工件:用例模型。
工件:角色。
用例。
工件:架構描述(用例模型的視圖)。
工件:術語表。
工件:用戶介面原型。
工作者。
工作者:系統分析師。
工作者:用例規範者。
用戶介面設計師。
工作者:架構師。
工作流程。
活動:尋找角色和用例。
活動:優先排序用例。
活動:詳細描述用例。
活動:原型用戶介面。
活動:結構化用例模型。
需求工作流程的總結。
參考文獻。

8. 分析。
介紹。
分析簡介。
為什麼分析不是設計或實現。
分析的目的:總結。
何時使用分析的具體例子。
分析在軟體生命週期中的角色。
工件。
工件:分析模型。
工件:分析類別。
工件:用例實現—分析。
工件:分析包。
工件:架構描述(分析模型的視圖)。
工作者。
工作者:架構師。
工作者:用例工程師。
工作者:元件工程師。
工作流程。
活動:架構分析。
活動:分析用例。
活動:分析類別。
活動:分析包。
分析的總結。
參考文獻。

9. 設計。
介紹。
設計在軟體生命週期中的角色。
工件。
工件:設計模型。
工件:設計類別。
工件:用例實現—設計。
工件:設計子系統。
工件:介面。
工件:架構描述(設計模型的視圖)。
工件:部署模型。
工件:架構描述(部署模型的視圖)。
工作者。
工作者:架構師。
工作者:用例工程師。
工作者:元件工程師。
工作流程。
活動:架構設計。
活動:設計用例。
活動:設計類別。
活動:設計子系統。
設計的總結。
參考文獻。

10. 實現。
介紹。
實現在軟體生命週期中的角色。
工件。
工件:實現模型。
工件:元件。
工件:實現子系統。
工件:介面。
工件:架構描述(實現模型的視圖)。
工件:整合建置計畫。
工作者。
工作者:架構師。
工作者:元件工程師。
工作者:系統整合者。
工作流程。
活動:架構實現。
活動:整合系統。
活動:實現子系統。
活動:實現類別。
活動:執行單元測試。
實現的總結。
參考文獻。

11. 測試。
介紹。
測試在軟體生命週期中的角色。
工件。
工件:測試模型。
工件:測試案例。
工件:測試程序。
工件:測試元件。
工件:計畫測試。
工件:缺陷。
工件:評估測試。
工作者。
工作者:測試設計師。
工作者:元件工程師。
工作者:整合測試員。
工作者:系統測試員。
工作流程。
活動:計畫測試。