The Unified Software Development Process
Published on 26. February 1999
Book
Hardback
512 pages
978-0-201-57169-1 (ISBN)
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.
More details
Language
English
Place of publication
Boston
United States
Publishing group
Pearson Education (US)
Target group
Professional and scholarly
Dimensions
Height: 193 mm
Width: 241 mm
Thickness: 31 mm
Weight
930 gr
ISBN-13
978-0-201-57169-1 (9780201571691)
Copyright in bibliographic data and cover images is held by Nielsen Book Services Limited or by the publishers or by their respective licensors: all rights reserved.
Schweitzer Classification
Persons
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.
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.
Content
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
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