Explains the underlying software development principles behind the RUP, and guides reader in the application of it in their organization.
- Step-by-step instruction shows you how simple it can be to succeed with the RUP
- Shows how to incrementally adopt the RUP with minimal risk, and how to identify traps and pitfalls along the way.
- Authored by the foremost RUP experts in the field, backed up by examples of companies that have made the process work for them
Explains the underlying software development principles behind the RUP, and guides reader in the application of it in their organization. RUP experts borrow from their significant experience and insider knowledge to show what works, and what doesn't, as well as specific advice on how and when to apply the RUP.
The authors explain the underlying software development principles behind theRUP, and guide readers in its application in their organization.
I. INTRODUCING THE RATIONAL UNIFIED PROCESS. 1. Introducing the Rational Unified Process.
What Is the Rational Unified Process?
The RUP—The Approach.
Underlying Principles of the RUP Approach.
The RUP and Iterative Development.
The RUP--A Well-Defined Software Engineering Process.
The Dynamic Structure of the Rational Unified Process.
The Static Structure of the Rational Unified Process.
The RUP-A Customizable Process Product.
Configuration and Process Authoring Tools.
Process Delivery Tools.
Who Uses the RUP Product?
Conclusion. 2. The Spirit of the RUP: Guidelines for Success.
Attack Major Risks Early and Continuously, or They Will Attack You.
Ensure That You Deliver Value to Your Customer.
Stay Focused on Executable Software.
Accommodate Change Early in the Project.
Baseline an Executable Architecture Early On.
Build Your System with Components.
Work Together as One Team.
Make Quality a Way of Life, Not an Afterthought.
Conclusion. 3. Comparing Processes: The RUP, Agile Methods, and Heavyweight Government Standards.
How Can We Compare Processes?
Agile Development: Low-Ceremony, Iterative Approaches.
SEI CMM, SEI CMMI, ISO/IEC, DOD-STD, MIL-STD: High Ceremony Striving for Higher Predictability.
SEI CMM: Process Assessment Framework.
SEI CMMI: Process Assessment Framework.
ISO/IEC 15504: Process Assessment Framework.
DOD-STD and MIL-STD: High-Ceremony Processes.
The RUP: An Iterative Approach with an Adaptable Level of Ceremony.
How Iterative Do You Want to Be?
How Much Ceremony Do You Want?
What Kind of RUP Configuration Meets Your Process Needs?
Project Deimos: Team of One.
Project Ganymede: Small Project with Tight Timeline.
Project Mars: Average-Size Project without Iterative Development Experience.
Project Jupiter: Large Distributed Project.
Conclusion. 4. The RUP for a Team of One: Project Deimos.
A Solo Software Project: Project Deimos.
The Seminal Idea (Saturday Night).
The Proposal (Monday Morning).
The Risk List.
The Business Case.
The Commitment (Monday Lunch).
The Vision, Take Two.
The Plan, Take Two.
The Risk List, Take Two.
The Business Case, Take Two.
Digging In (Later Monday).
Pressing On (Tuesday).
More Progress, More Changes (Wednesday).
Nearing Completion (Thursday).
Beta and Ship (Friday).
II. THE LIFECYCLE OF A RATIONAL UNIFIED PROCESS PROJECT. 5. Going Through the Four Phases.
A Major Misconception.
No Fixed Workflows.
No Frozen Artifacts.
Three Types of Projects. 6. The Inception Phase.
Objectives of the Inception Phase.
Inception and Iterations.
Objective 1: Understand What to Build.
Produce a Vision Document.
Generate a “Mile-Wide, Inch-Deep” Description.
Hold a Workshop or Brainstorming Session.
Detail Key Actors and Use Cases.
Objective 2: Identify Key System Functionality.
Objective 3: Determine at Least One Possible Solution.
Objective 4: Understand the Costs, Schedule, and Risks Associated with the Project.
Objective 5: Decide What Process to Follow and What Tools to Use.
Project Review: Lifecycle Objective Milestone.
Conclusion. 7. The Elaboration Phase.
Objectives of the Elaboration Phase.
Elaboration and Iterations.
First Iteration in Elaboration.
Second Iteration in Elaboration.
Objective 1: Get a More Detailed Understanding of the Requirements.
Objective 2: Design, Implement, Validate, and Baseline the Architecture.
Architecture: Defining Subsystems, Key Components, and Their Interfaces.
Use Architecturally Significant Use Cases to Drive the Architecture.
Design Critical Use Cases.
Consolidate and Package Identified Classes.
Ensure Architectural Coverage.
Design the Database.
Outline Concurrency, Processes, Threads, and Physical Distribution.
Identify Architectural Mechanisms.
Implement Critical Scenarios.
Test Critical Scenarios.
What Is Left to Do?
Objective 3: Mitigate Essential Risks, and Produce Accurate Schedule and Cost Estimates.
Plan the Project and Estimate Costs.
Objective 4: Refine the Development Case and Put the Development Environment in Place.
Project Review: Lifecycle Architecture Milestone.
Conclusion. 8. The Construction Phase.
Objectives of the Construction Phase.
Construction and Its Iterations.
Objective 1: Minimize Development Costs and Achieve Some Degree of Parallelism.
Organize Around Architecture.
Enforce the Architecture.
Ensure Continual Progress.
Objective 2: Iteratively Develop a Complete Product That is Ready to Transition to Its User Community.
Describe the Remaining Use Cases and Other Requirements.
Fill in the Design.
Design the Database.
Implement and Unit-Test Code.
Do Integration and System Testing.
Early Deployments and Feedback Loops.
Prepare for Beta Deployment.
Prepare for Final Deployment.
Project Review: Initial Operational Capability Milestone.
Conclusion. 9. The Transition Phase.
Objectives of the Transition Phase.
Transition Iterations and Development Cycles.
Transition and Iterations.
Transition and Development Cycles.
Objective 1: Beta Test to Validate That User Expectations are Met.
Capturing, Analyzing, and Implementing Change Requests.
Patch Releases and Additional Beta Releases.
Metrics for Understanding When Transition Will be Complete.
Objective 2: Train Users and Maintainers to Achieve User Self-Reliability.
Objective 3: Prepare Deployment Site and Convert Operational Databases.
Objective 4: Prepare for Launch: Packaging, Production, and Marketing Rollout.
Packaging, Bill of Materials, and Production.
Objective 5: Achieve Stakeholder Concurrence That Deployment is Complete.
Product Acceptance Test.
Objective 6: Improve Future Project Performance Through Lessons Learned.
Project Review: Product Release Milestone.
III. ADOPTING THE RATIONAL UNIFIED PROCESS. 10. Configuring, Instantiating, and Customizing the Rational Unified Process.
Configuring the RUP.
Producing a RUP Process Configuration.
Producing Process Views.
Customizing RUP Templates.
Instantiating the RUP in a Project.
A RUP Development Case.
Project Web Site.
Alternatives to Producing a Development Case.
Customizing the RUP.
Rational Process Workbench and Process Engineering Process.
Creating Thin RUP Plug-Ins Using RUP Organizer.
Creating Structural RUP Plug-Ins Using RUP Organizer.
Conclusion. 11. Adopting the Rational Unified Process.
Adopting the RUP in a Project.
Configure and Customize.
Adopting the RUP in Small Projects.
Adopting the RUP in a Large Organization.
Process and Tool Enhancement Projects (PTEP).
Software Development Projects.
A Typical Program for Moderate Change.
A Typical Program for Major Change.
An Aggressive Program for Major Change.
Conclusion. 12. Planning an Iterative Project.
Coarse-Grain and Fine-Grain Plans: Project Plans and Iteration Plans.
The Project Plan.
The Iteration Plan.
Building a Project Plan.
Determining the Number of Iterations.
Staffing the Project.
Inception and Elaboration.
Construction and Transition.
An Iterative Estimation Technique: Wideband Modified Delphi.
Optimizing the Project Plan.
Conclusion. 13. Common Mistakes When Adopting and Using the RUP--and How to Avoid Them.
Mistakes When Adopting the RUP.
Adopting Too Much of What Is in the RUP.
Adopting Everything at Once, Rather than Incrementally.
Not Planning the Implementation of the RUP.
Not Coupling Process Improvement with Business Results.
Customizing Too Much of the RUP Too Early.
Paying Lip Service to the RUP.
Mistakes When Managing Iterative Development.
Having a Functional, Specialized Organization.
Not Setting the Right Stakeholder Expectations or Using an Old-Fashioned Acquisition Model.
Too Many Developers at Project Start.
Solving the Easy Stuff First.
Having an Extended Initial Iteration.
Having Overlapping Iterations.
Allowing Too Many Changes Late in the Project.
Mistakes in Analysis, Architecture, Design, Implementation, and Testing.
Creating Too Many Use Cases.
Including Design Decisions in Your Requirements.
Not Having Stakeholder Buy-In on Requirements.
“Not Invented Here” Mentality.
Ending Elaboration Before the Architecture Is Sufficiently Stable.
Focusing on Inspections Instead of Assessing Executable Software.
IV. A ROLE-BASED GUIDE TO THE RATIONAL UNIFIED PROCESS. 14. A Project Manager's Guide to the RUP.
The Mission of a Project Manager.
A Complex Role.
A Person or a Team?
Scope of the Project Management Discipline in the RUP.
Software Development Plan (SDP).
Activities of a Project Manager.
Launching a New Project.
Developing the Software Development Plan.
Starting and Closing Phases and Iteration.
Monitoring the Project.
Finding Your Way in the RUP.
Resources for the Project Manager.
On the Web.
Training Resources. 15. An Analyst's Guide to the RUP.
Your Mission as an Analyst.
Where Do You Start?
Understand How Your Business Should Operate.
Understand Stakeholder Needs.
Develop a Vision.
Develop a Use-Case Model and Glossary.
Describe Requirements “Mile-Wide, Inch-Deep”.
Detail Actors and Use Cases.
Example Use-Case Specification for Register for Courses.
Fine-Tune Your Model.
Develop User-Interface Prototypes.
Develop Use-Case Storyboard or Prototype.
Capture Nonfunctional Requirements.
Update and Refine Requirements.
Ensure That the Requirements Are Delivered and Tested.
The Analyst's Role in the Rational Unified Process.
Resources for Analysts.
Training Resources. 16. An Architect's Guide to the RUP.
The Mission of an Architect.
A Person or a Team?
A Vertex of Communication.
Models and Views.
Software Architecture Document.
Executable Architectural Prototype.
An Evolving Role.
What Do Architects Do?
The Architect's Activities in the RUP.
Working with the Requirements and Project Management.
Refining the Architecture.
Maintaining Architectural Integrity.
The Architect's Roles in the RUP.
Finding Your Way in the RUP Product.
Resources for the Architect.
Useful Web Sites. 17. A Developer's Guide to the RUP.
Your Mission as a Developer.
Overview of the Developer's Tasks.
Understand the Requirements and Design Constraints.
Design, Implement, and Test Use Cases and Components.
Design Use-Case Realizations and Components.
Implement Use Cases and Components.
Design, Implement, and Test Any Necessary Databases.
Frequently Integrate Your Application with the Work of Other Developers.
Configuration Management Workspaces.
Produce a Build.
Developer Best Practices.
Refactor Your Code and Design.
Use Patterns, Architectural Mechanisms, and Other Reusable Assets.
Keep Your Design Simple.
The Developer Role in the Rational Unified Process.
Available Resources for Developers.
Recommended Training. 18. A Tester's Guide to the RUP.
The Mission of the Tester.
The Concept of Product Quality in the RUP.
Paradigms of “Good Enough”.
The Cost of Quality.
Wouldn't Quantification Help?.
Conformance to Standards.
What Is Testing?
The RUP Testing Philosophy.
The Test Discipline in the RUP Product.
Various Roles Related to Test in the RUP.
Key Test Artifacts.
Activities of the Tester.
Define Test Mission.
Verify Test Approach.
Validate Build Stability (Smoke Test).
Test and Evaluate.
Achieve an Acceptable Mission.
Improve Test Assets.
Other Related Activities.
Resources for Testers.
Training Resources. Glossary.