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. 0201571692T04062001About the Author
Ivar Jacobson, Ph.D., is “the father” of many
technologies, including components and component architecture, use
cases, modern business engineering, and the Rational Unified
Process. He was one of the three amigos who originally developed
the Unified Modeling Language. He is the principal author of five
best-selling books on these methods and technologies, in addition
to being the coauthor of the two leading books on the Unified
Modeling Language. Ivar is a founder of Jaczone AB, where he and
his daughter and cofounder, Agneta Jacobson, are developing a
ground-breaking new product that includes intelligent agents to
support software development. Ivar also founded Ivar Jacobson
Consulting (IJC) with the goal of promoting good software
development practices throughout teams worldwide.
Grady Booch, is the Chief Scientist at Rational Software
Corporation and developer of the Booch Method of object-oriented
analysis and design. He is also co-developer of the Unified
Modeling Language (UML). Widely recognized for these and many
contributions in the field, he is a popular speaker at technology
conferences around the world. Booch has twice received Software
Development magazine's coveted Jolt-Cola Product Excellence Award
for his seminal text,Object-Oriented Analysis and Design with
Applications. Dr. James Rumbaugh is one of the leading
object-oriented methodologists. He is the chief developer of the
Object Modeling Technique (OMT) and the lead author of the
best-selling book Object-Oriented Modeling and Design. Before
joining Rational Software Corporation in October 1994, he worked
for more than 25 years at General Electric Research and Development
Center in Schenectady, New York.
He has been working on object-oriented methodology and tools for
many years. He developed the DSM object-oriented programming
language, the state tree model of control, the OMT object modeling
notation, and the Object Modeling Tool graphic editor. The
foundations for the OMT notation were developed more than 10 years
ago with Mary Loomis and Ashwin Shah of Calma Corporation. The OMT
methodology was developed at GE R&D Center with coauthors Mike
Blaha, Bill Premerlani, Fred Eddy, and Bill Lorensen.
Dr. Rumbaugh received his Ph.D. in computer science from MIT.
During his Ph.D. research under Professor Jack Dennis, Dr. Rumbaugh
was one of the inventors of data flow computer architecture. His
career has dealt with semantics of computation, tools for
programming productivity, and applications using complex algorithms
and data structures. Dr. Rumbaugh has published journal articles on
his work and has spoken at leading object-oriented conferences. He
writes a regular column for the Journal of Object-Oriented
Programming.
Dr. Rumbaugh is the lead author of the recent best-selling book
Object-Oriented Modeling and Design, published by Prentice Hall.
His latest book, OMT Insights: Perspectives on Modeling from the
Journal of Object-Oriented Programming, was released in October
1996. He and his colleagues developed the OMT methodology described
in the book based on real-world applications at GE, and they have
worked to extend the original methodology. He has taught courses
based on the methodology to different audiences around the world,
ranging from one-hour seminars to intensive several-day training
courses.
He has a B.S. in physics from MIT, an M.S. in astronomy from
Caltech, and a Ph.D. in computer science from MIT.
During his career at GE, he worked on a variety of problems,
including the design of one of the first time-sharing operating
systems, early work in interactive graphics, algorithms for
computed tomography, use of parallel machines for fast image
generation, VLSI chip design, and finally, object-oriented
technology.
Jim developed OMTool, an interactive graphical editor for
manipulation of object model diagrams. The editor is commercially
available. In addition, he led a five-year programming effort
producing production-quality software.
In addition, Jim was the manager of the Software Engineering
Program at GE, where he led a team of eight to ten Ph.D. and M.S.
scientists performing research in software engineering in the areas
of algorithm development, programming languages, program proving,
and VLSI computer-aided design. In addition, he performed personal
research.
Jim developed Chipwright, an interactive graphical CAD system
for VLSI layout with incremental design rule checking. He also led
a team of four programmers in implementation.
Jim developed and implemented the object-oriented language DSM,
combining object-oriented concepts with database concepts and
distributed it within GE for use on production applications. The
language was heavily used at Calma Corporation and was extensively
extended based on user feedback with a preliminary version.
Jim also developed Vista, a hierarchical interactive standard
graphics system (similar to the PHIGS system) written in the
object-oriented DSM language. He implemented user-interface
applications based on this system, including a
configuration-management tool and a user-interface generation
tool.
Jim developed the concept of state trees, a structured extension
of finite state machines incorporating a new model of
object-oriented control. He applied it to the design of user
interfaces, and the technique was used as a main aspect of the
CHIDE user-interface system developed by colleagues at GE-CRD.
Later, it was used in the OMTool object editor.
Jim also developed the Flow Graph System, a generic interactive
graphic system for controlling a network of design engineering
jobs, including management of multiple versions of data and
coordination of information flow among applications. He received a
patent on the underlying concepts.
In addition, Jim developed algorithms for the reconstruction of
images for computerized tomography using fewer input points and
with reduced noise in the reconstructed images. He also developed
algorithms for display of three-dimensional images in real time
using array processors, and he developed Parallax, a language for
programming pipelined array processors.
Jim has served on various committees, including the OOPSLA
Program Committee and the TOOLS Program Committee.