| Figures. |
| Tables. |
| Foreword. |
| Preface. |
| 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. |
| Summary. |
| Ensure That You Deliver Value to Your Customer. |
| Summary. |
| Stay Focused on Executable Software. |
| Summary. |
| Accommodate Change Early in the Project. |
| Summary. |
| Baseline an Executable Architecture Early On. |
| Summary. |
| Build Your System with Components. |
| Summary. |
| Work Together as One Team. |
| Summary. |
| Make Quality a Way of Life, Not an Afterthought. |
| Summary. |
| 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 Vision. |
| The Plan. |
| The Risk List. |
| The Business Case. |
| The Architecture. |
| 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). |
| Conclusion. |
| II. THE LIFECYCLE OF A RATIONAL UNIFIED PROCESS PROJECT. |
| 5. Going Through the Four Phases. |
| A Major Misconception. |
| Major Milestones. |
| 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. |
| Integrate Components. |
| 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. |
| Configuration Management. |
| 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. |
| Transition Testing. |
| 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. |
| Marketing Rollout. |
| 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. |
| Conclusion. |
| 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. |
| Assess. |
| Plan. |
| Configure and Customize. |
| Execute. |
| Evaluate. |
| Adopting the RUP in Small Projects. |
| Adopting the RUP in a Large Organization. |
| Process and Tool Enhancement Projects (PTEP). |
| Pilot Projects. |
| 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. |
| Motivation. |
| Key Concepts. |
| Cycle. |
| Phases. |
| Iteration. |
| Build. |
| Time-Boxing. |
| 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. |
| Iteration Length. |
| Staffing the Project. |
| Iteration Planning. |
| Inception and Elaboration. |
| Construction and Transition. |
| Identifying Activities. |
| Estimating. |
| An Iterative Estimation Technique: Wideband Modified Delphi. |
| Optimizing the Project Plan. |
| Overlapping Iterations. |
| Parallel Iterations. |
| 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. |
| Having Analysis-Paralysis. |
| 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. |
| Conclusion. |
| 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). |
| Iterative Development. |
| Risks. |
| Metrics. |
| 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. |
| Conclusion. |
| Resources for the Project Manager. |
| Further Reading. |
| 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. |
| Problem Statement. |
| Feature List. |
| 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. |
| Further Reading. |
| Training Resources. |
| 16. An Architect's Guide to the RUP. |
| The Mission of an Architect. |
| A Jack-of-All-Trades. |
| A Person or a Team? |
| A Vertex of Communication. |
| Architecture. |
| Architecture Defined. |
| Models and Views. |
| Software Architecture Document. |
| Executable Architectural Prototype. |
| Architectural Mechanisms. |
| Additional Architecture? |
| An Evolving Role. |
| What Do Architects Do? |
| Vision. |
| Rhythm. |
| Anticipation. |
| Partnering. |
| Simplification. |
| 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. |
| Further Reading. |
| 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. |
| Developer Testing. |
| Design, Implement, and Test Any Necessary Databases. |
| Frequently Integrate Your Application with the Work of Other Developers. |
| Configuration Management Workspaces. |
| Integration Planning. |
| Produce a Build. |
| Developer Best Practices. |
| Test First. |
| Refactor Your Code and Design. |
| Use Patterns, Architectural Mechanisms, and Other Reusable Assets. |
| Keep Your Design Simple. |
| Pair Programming. |
| The Developer Role in the Rational Unified Process. |
| Available Resources for Developers. |
| Recommended Reading. |
| 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. |
| Mission. |
| Test Cycles. |
| 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. |
| Conclusion. |
| Resources for Testers. |
| Further Reading. |
| Training Resources. |
| Glossary. |
| Bibliography. |