Register your product to gain access to bonus material or receive a coupon.
Succeeding with Use Cases: Working Smart to Deliver Quality
- By Richard Denney
- Published Apr 26, 2005 by Addison-Wesley Professional. Part of the Addison-Wesley Object Technology Series series.
Book
- Sorry, this book is no longer in print.
About
Features
Increase software quality, while minimizing development costs, by leveraging industry best practices for quality management in use cases.
° Launch your development efforts to another level with an entirely new set of perspectives on use case driven development
° Deliver true "bang for the buck" with proven techniques for improving software quality and increasing ROI
° Learn to extend the power of use cases as well as proven methodologies such as RUP and Extreme Programming
Description
- Copyright 2005
- Edition: 1st
- Book
- ISBN-10: 0-321-31643-6
- ISBN-13: 978-0-321-31643-1
Build on Use Cases to Deliver Higher-Quality, Higher-Value Software
You can dramatically improve software quality and value by integrating use cases with best-practice software quality engineering disciplines.
Richard Denney presents practical, cost-effective techniques that help your entire development organization deliver superior software.
Using realistic examples, Denney demonstrates how to complement use cases with Quality Function Deployment (QFD), Software Reliability Engineering (SRE), Model-Based Specification (preconditions, postconditions, and invariants), Requirements Configuration Management, and Project Portfolio Management. Denney's techniques address challenges faced by project and product managers, team leads, developers, designers, software engineers, and testers alike. These techniques offer immense value no matter what methodology you use—from the Unified Process to Extreme Programming.
Use QFD to make sure you release products that are true to your business drivers
Drive your project's vision vertically, from senior management and marketing to the development team
Align/synchronize distributed development horizontally across component teams, product teams, and business groups
Use SRE to maximize reliability and customer satisfaction—while minimizing engineering costs
Build use case operational profiles that help you spend development dollars more intelligently
Get solid metrics that tell you when it's time to stop testing
Use Model-Based Specification to sharpen your analysis of potential failures
Understand precondition and postcondition realities they never mentioned in "Use Case 101"
Design effective test cases using preconditions, postconditions, and invariants
Use Configuration Management of Use Cases to help your company work smarter
Leverage use cases in Project Portfolio Management—quite possibly the most valuable process improvement you can make
Calculate ROI on your company's investments in a requirements management tool and process
© Copyright Pearson Education. All rights reserved.
Sample Content
Online Sample Chapter
Downloadable Sample Chapter
Download the Sample
Chapter related to this title.
Table of Contents
Preface.
Acknowledgments.
I. QUALITY FUNCTION DEPLOYMENT.
1. An Introduction to QFD: Driving Vision Vertically.
Through the Project
The Language Gap
QFD in Use Case-Driven Projects
Business Drivers in QFD
The "Chaos" of Projects and the Importance of Prioritization
Running a QFD Workshop: Mega Motors Example
Workshop Overview
Identify Use Cases
Analyze Relationship of Use Cases to Business Drivers
Analyze Correlations Between Use Cases
First Matrix Complete; QFD Workshop Status Check
"Flipping the Matrix": Deployment to Quality Requirements
Flipping the Matrix: Deployment to Vehicle Components
Workshop Conclusion and Summary
Chapter Review
2. Aligning Decision Making and Synchronizing Distributed Development Horizontally in the Organization.
Using QFD to Align Decision Making Horizontally Across a Company
A Brief Overview of Oil and Gas Exploration
The Problem: Selecting A Shared Earth Modeling Development Kit
O&G's QFD Road Map
Matrix 1: Prioritize Use Cases
Matrix 2: Prioritize Non-Functional Requirements
Matrix 3: Prioritize Earth Modeling Techniques
Matrix 4: Prioritize Shared Earth Modeling Dev Kits
Example Conclusion and Summary
Using QFD to Synchronize Distributed Development Horizontally Across Component Teams
Entropy Happens in Distributed Software Development
Planning the Length of Iterations and Number of Use Cases per Iteration in Distributed Software Development
Chapter Review
II. SOFTWARE RELIABILITY ENGINEERING.
3. Operational Profiles: Quantifying Frequency of Use of Use Cases.
Operational Profile of Use Case Scenarios
Decision Graphs
Pareto Principle and Guesstimates
Working Smarter: Scenarios of a Use Case
Time-Boxing an Inspection
Bottom-Up Estimation of Tests Needed per Scenario
Operational Profile of a Use Case Package
Sanity Check Before Proceeding
Use Case Relationships
Sales Order Example
Probability that Include/Extend Use Cases Are Actually Used
Concluding Thoughts About Use Case Relationships
Working Smarter: Use Case Packages
Time-Boxing for a Package of Use Cases
Transitioning from High-Level to Low-Level Planning
Air Bags and Hawaiian Shirts
Extending Operational Profiles to Address Critical Use Cases
What Does "Critical" Mean?
It's a Calculated Risk
Hardware Widget Example
Profiling Risk in Use Cases
What Have You Got to Lose?
Chapter Review
4. Reliability and Knowing When to Stop Testing.
What Is "Reliability"?
Software Reliability is User-Centric and Dynamic
Software Reliability Is Quantifiable
Reliability: Software Versus Hardware
Failure Intensity
Visualizing Failure Intensity with a Reliability Growth Curve
Selecting a Unit of Measure for Failure Intensity
Setting a Failure Intensity Objective
But What's the Right Failure Intensity Objective?
The Swamp Report
Dashboard Layout
Establish Planned Test Coverage as per Operational Profile
Initialize Dashboard Before Each Test Iteration
Update the Dashboard at the End of Each Test Iteration
Tracking the Swamp Through Time
Determining the Effectiveness of Your SRE-Based Test Process
Final Notes on DDE
Chapter Review
III. MODEL-BASED SPECIFICATION (PRECONDITIONS, POSTCONDITIONS, AND INVARIANTS).
5. Use Case Preconditions, Postconditions, and Invariants: What They Didn't Tell You, But You Need to Know!
Sanity Check Before Proceeding
A Brief History of Preconditions and Postconditions
Calculating Preconditions from Postconditions
Use Case Overview
Step 1. Find a "Risky" Postcondition: Model as an Equation
Step 2. Identify a Potential Failure: State an Invariant
Step 3. Compute the Precondition
Why Does This Work?!
Modeling State Change
Model-Based Specification
Reasoning About State Through Time
Use Case Overview
Step 1. Find "Risky" Postconditions: Model as Equations
Step 2. Identify a Potential Failure: State an Invariant
Step 3. Calculate Preconditions
Exploring Boundary Condition Failures
Step 1. Identify Postconditions Associated with Boundaries of Operation
Step 2. State an Invariant the Postconditions Should Not Violate
Step 3. Calculate Preconditions
Further Thoughts: Preconditions, Postconditions, and Invariants in Use Cases
Preconditions and Postconditions of Individual Operations Versus the Use Case as a Whole
Scope of Preconditions and Postconditions: Scenario Versus Whole Use Case
Postconditions Can Have More than One Precondition
Weak and Strong Preconditions
Types of Invariants in Use Cases
Working Smart in How You Apply What You've Learned
Prioritize Where You Apply Model-Based Specification
Stick to Numeric Problems
The Absolute Least You Need to Know: One Fundamental Lesson and Three Simple Rules
Chapter Review
6. Triple Threat Test Design for Use Cases.
"Triple Threat" Test Cases?
Threat #1-The Precondition
Threat #2-The Postcondition
Threat # 3-The Invariant
Applying the Extended Use Case Test Design Pattern
Step 1. Identify Operational Variables
Step 2. Define Domains of the Operational Variables
Step 3. Develop the Operational Relation
Step 4. Build Test Cases
Closing Thoughts
Chapter Review
IV. USE CASE CONFIGURATION MANAGEMENT.
7. Calculating Your Company's ROI in Use Case Configuration Management.
Overview of ROI
Requirements Management Tools
Calculating the ROI
Conventions and Starting Assumptions
Assumptions About Cost of a Fully Burdened Employee
Initial Actual Data about Use Cases
The Cost
Cost of Tools, Training, Consulting, and Rollout Team
Cost of Tool Use Overhead
Cost of Added Review and Rigor
The Benefits
Savings from Staff Working more Efficiently
Savings from Avoiding the Cost of Lost Use Cases from Staff Churn
Savings from Avoiding Cost of Unnecessary Development
Savings from Reducing the Cost of Requirements-Related Defects
Bottom Line: Benefit to Cost Ratio
Dealing with Uncertainty in the Model
Chapter Review
8. Leveraging Your Investment in Use Case CM in Project Portfolio Management.
What this Chapter Is (and Isn't) About
The Good Thing About Use Cases...
Use Case Metadata (Requirements Attributes)
How Are You Currently Invested?
Inventory of Projects
Metadata Needed for Use Cases
Assign Use Case to Project and Estimate Effort
Checking the Mix
Managing the Pipeline
Full Time Equivalent (FTE) Models of the Project Portfolio
Run Chart of FTEs Through Time
Tracking the Status of the Portfolio via Use Cases
Status of Use Cases
Tracking the Progress of Projects with the Status of Use Cases
Chapter Review
V. APPENDICES.
Appendix A: Sample Use Case.
Appendix B: Bare-Bones Project Portfolio Database and Use Case Metadata.
Bare-Bones Portfolio Database
Use Case Metadata
Checking the Mix of Project Types
Appendix C: Run Chart of FTEs Required by Project Portfolio.
Query to Sum Use Case Effort by Project Code
Query to Prepare Data for Import to Microsoft Project
Appendix D: Reports for Tracking Progress of Projects in Portfolio.
Metadata for Use Case Status
Report for Tracking Status of Projects in the Portfolio by Use Case Status
References.
Index.
Preface
It was this realization that led to this book: that my experiences with disciplines, such as QFD, Software Reliability Engineering, Model-based Specification (preconditions, postconditions, and invariants), Requirements Configuration Management, and Project Portfolio Management combined with use cases might benefit others in the use case development community.
This book presents what I hope you will agree is a whole new set of perspectives on use case-driven development. Innovation, solutions to problems, and ways of working smarter often arise when ideas from multiple areas are combined. As use cases continue to mature, future improvements in use case-driven development are likely to arise from just such cross-pollination of use cases with other disciplines of software engineering. This book looks at four areas that focus on quality engineering.
•Quality Function Deployment (QFD)
•Software Reliability Engineering
•Model-Based Specification (Preconditions, Postconditions, and Invariants)
•Requirements Configuration Management/Project Portfolio Management
From each discipline, the book pulls practical, 20/80, "high bang for the buck" ideas that help you and your organization work smart to deliver quality products in use case-driven development.1
--------------------------------------------------------------------------------
1 "Quality" as used in this book is the project stakeholders' (especially customers') relative valuation of scope (functions and features), schedule (speed of delivery to the customer), cost and degree of defect-free operation (i.e. reliability). This is the same definition used by Jim Highsmith (2000) and others in the software quality arena.
--------------------------------------------------------------------------------
Overview of Parts and Chapters
The book is organized into four parts—one per quality engineering discipline—with
two chapters each. Here's an overview of what you'll find in each part of the
book.
Part 1—Quality Function Deployment
Like it or not, software development is increasingly becoming a team sport!
And it's a game being played on a "two dimensional field." Chapter
1, "An Introduction to QFD: Driving Vision Vertically Through the Project,"
introduces QFD, a team-oriented product-planning tool that is used to translate
business drivers into the technical requirements and design aspects of a product.
You will learn how to use QFD in use case-driven development as a mechanism
for moving vision vertically—the first dimension of the playing field—through
projects starting at the senior management/marketing level, where vision is
hatched and business priorities are being set, downward to the development team
level, so that the product that is released is true to the original vision and
business priorities.
The second dimension in which the "team sport" of use case-driven development is played out in a company is horizontally. Chapter 2, "Aligning Decision Making and Synchronizing Distributed Development Horizontally in the Organization," looks at the factors that make use case-driven distributed development difficult and the combined use of QFD and use cases to align decisions and synchronize use case-driven development horizontally across multiple component or product teams, or business groups in a company. You'll learn how to use QFD and simple optimization problem-solving tools to find the optimum duration for a development iteration and the optimum set of high-priority use cases that can be implemented in that time across distributed teams.
Part 2—Software Reliability Engineering
Software Reliability Engineering (SRE) is about increasing customer satisfaction
by delivering a reliable product, while minimizing engineering costs. Use case-driven
development and SRE are a natural match, both being usage-driven styles of product
development. What SRE brings to the party is a discipline for focusing time,
effort, and resources on use cases in proportion to their estimated frequency
of use or criticality, called an operational profile. In Chapter 3, "Operational
Profiles: Quantifying Frequency of Use of Use Cases," you'll learn how
to build an operational profile for the scenarios that make up a single use
case and for a package of use cases. Examples are provided to illustrate the
use of operational profiles to enable you to work intelligently in how you plan
the activities that affect your product reliability. The chapter concludes by
showing how to extend operational profiles to address risk profiling of use
case packages.
Your product has been in final system test for days—or has it been weeks? Surely it must be time to stop testing and release it! Chapter 4, "Reliability and Knowing When to Stop Testing," looks at another important concept that Software Reliability Engineering brings to use case development: A concrete way to talk about "reliability." This includes how to define it, measure it, set goals in terms of it, and track it in testing. In this chapter, you will learn how to set quantitative reliability goals in the form of a failure intensity objective. The development and testing group then tracks product reliability in system tests against this objective providing a sound method to determine when the reliability goal has been reached, testing can terminate, and the product can be released.
Part 3—Model-Based Specification (Preconditions, Postconditions, and Invariants)
In Chapter 5, "Preconditions, Postconditions, and Invariants: What They
Didn't Tell You, But You Need to Know!" you are introduced to a time-tested
technique for specifying the expected behavior of abstract data types and objects—model-based
specification—and learn how to apply it in a fresh way to pose sharp questions
in use case failure analysis: the analysis of potential ways a system, specified
by a use case, might fail. In doing so, you'll learn some things about preconditions
and postconditions they forgot to mention in "Use Case 101." The chapter
concludes with ideas on how to work smartly in applying model-based specification,
including the section "The Absolute Least You Need to Know: One Fundamental
Lesson and Three Simple Rules," which, if you get nothing else from the
chapter, will give you a take away you can apply to any and all use cases right
away. The goal of this chapter is nothing less than providing you a whole new
perspective on use case preconditions and postconditions.
Not only does the model-based specification with its preconditions, postconditions, and invariants provide an integrated basis for use case failure analysis, taken as a unit they are a veritable triple threat test case. In Chapter 6, "Triple Threat Test Design for Use Cases," you'll learn how to take the preconditions, postconditions, and invariants generated from failure analysis in the previous chapter and design test cases from them using Robert Binder's Extended Use Case Test Design Pattern.
Part 4—Use Case Configuration Management
There is no question that a commercial requirements management tool is useful
for use case management; but can it pay for itself at your company? Chapter
7, "Calculating Your Company's ROI in Use Case Configuration Management,"
looks at a model to help you calculate the Return On Investment (ROI) on requirements
management tools for use case management. Not only will it help you decide if
such tools make sense for your company, it also helps illustrate some of the
types of problems configuration management of use cases is meant to address.
In Chapter 8, "Leveraging Your Investment in Use Case CM in Project Portfolio Management," you'll learn how to leverage your company's investment in use case CM to provide metrics and reports for what could well be the most far-reaching, single process improvement possible in your company: Project Portfolio Management. Project Portfolio Management is the measured allocation of development resources according to some strategic plan. You'll learn how to leverage use case-based metrics and reports to evaluate the mix of strategic project types in the project portfolio and evaluate if projects are executable in the times specified by the portfolio, an approach called pipeline management.
Part 5—Appendices
Appendices A through D provide further supporting materials. They provide more
detailed, how-to information that should prove useful as you read the chapters.
Who Should Read What
This book is for anyone doing use case-driven development who wants to think
outside the box a little to try some new ideas. Here's some guidance on who
should read what parts and chapters of the book, and what background you are
assumed to have.
Knowledge About Use Cases
The only assumption made about your background as a reader is that you are already
familiar with use cases. The scope of the book does not include an introduction
to use cases, UML, Unified Software Development Process, and so on. Many excellent
books already cover these topics.
Knowledge About the Other Software Engineering Disciplines
Previous knowledge of the other software engineering disciplines discussed in
this book is not necessary. Do keep in mind that whole quality engineering disciplines
have been condensed down to two chapters each. These are disciplines that merit
whole books, and have large conferences and research and development communities,
so what you will see is only a small part of what are large disciplines, but
they are parts that yield a good bang for the buck for the use case community.
Ample references have been provided to allow you to explore topics in more depth
if you desire. A goal of this book is to increase the visibility of these other
disciplines to the use case community, and I think references are key to this
goal.
For Those Who Hate Math
Two parts of the book—Part 2, "Software Reliability Engineering,"
and Part 3, "Model-Based Specification"—have a little math in
them.
Part 2 involves a little probability and an equation or two, all of which you will be walked through carefully, so no prior background in probability is needed.
Part 3—especially the first chapter—may be the book's most challenging technically, more due to the concepts than the math. The only assumption made is that you are familiar with arithmetic and simple algebra.
Unified Software Development Process
All the ideas in this book can be applied whether or not you are following the
Unified Software Development Process (USDP). If you are, however, following
USDP you might find Table P.2 useful: It provides guidance on phases of the
USDP in which you will find the application of the techniques of each chapter
most beneficial. A checkmark indicates the phase in which the techniques as
exemplified in the chapter would likely occur. A plus sign indicates other phases
in which the techniques could be applied, but which are not specifically illustrated
in the chapter.
To review Table P.2, moving top to bottom, QFD is a technique that by design is capable of being applied in all phases of a project. The example provided in Chapter 1 illustrates its use during inception in helping a team decide the focus of a release. The application of QFD in Chapter 2 is focused on planning and coordinating use case distributed development and would be used in elaboration and/or construction.
Chapter 3 is concerned with operational profiles that would be created during elaboration, then their results used in all subsequent phases for prioritization of effort and resource. The setting of reliability goals discussed in Chapter 4 would occur as part of planning done in elaboration. The use of those reliability goals would then be used in tracking reliability growth of the product during testing in construction and transition.
Having used QFD or operational profiles to identify use cases that were frequently used, critical and/or important to business drivers, the model-based specification techniques of Chapter 5 would be used in elaboration for failure analysis of the system as described by those key use cases. In construction, those same techniques could also be used in specifying class or component interfaces using design by contract. In Chapter 6, test planning based on the work of Chapter 5 would be done as part of late elaboration or early construction. The test cases would be used in all subsequent phases as a basis for testing.
Finally, the calculation of ROI on a requirements configuration management tool, covered in Chapter 7, and project portfolio management, covered in Chapter 8, would occur as separate programs apart from any single software product release and so are not applicable to specific phases per se. The results of project portfolio management would of course be used as part of the input to the inception phase of all projects.
How Parts of This Book Relate
Each of the four parts of this book—like the disciplines they pull from—are
standalone and can be read and used independently of one another. A few of the
techniques can, however, be leveraged off of one another.
Project portfolio management (Part 4, Chapter 8) is over-arching in relationship to all other topics in this book in that stresses in a company due to "too much work, too little time" affect virtually every other aspect of software development and the quality of products produced. A company that has not sorted its vital few projects from the trivial many is likely to have staff with neither the interest nor time for new innovative ideas.
The biggest bang for the buck in applying the ideas of Part 3, "Model-Based Specification," will come from application to use cases that are frequently used and/or are critical in nature. The techniques on describing operational profiles in Part 2, "Software Reliability Engineering," are ideal for identifying such use cases, as are the prioritization techniques of Part 1, "Quality Function Deployment."
It is also possible to use frequency of use information or criticality information obtained from an operational profile (Part 2, "Software Reliability Engineering") as one of many business drivers used to prioritize use cases with QFD. An example of this is provided in Chapter 2, "Aligning Decision Making and Synchronizing Distributed Development Horizontally in the Organization."
Conversely, you may find that a QFD matrix (Part 1, "Quality Function Deployment") is an ideal tool for building informal operational profiles for a product (Part 2, "Software Reliability Engineering").
What This Book Is Not
As with the scope of software projects, it's probably as important to be clear
about what this book is not as it is what it is. I've touched on a couple things
already, but they are worth reiterating.
The book does not provide an introduction on use cases: what they are, their benefit, or how to write them.
Nor will this book provide an overview of UML or the Unified Software Development Process. In general, this book is largely software development life-cycle neutral. Some of the ideas presented in the book actually work just as well with Extreme Programming's (XP) Stories as they do with use cases, and these will be pointed out.
While you will be getting a good impression of what the other disciplines are about—QFD, Software Reliability Engineering, Model-Based Specification, CM/Project Portfolio Management—the intent is not to present a definitive tutorial on any of these topics. Having said that, what you do get in this book from a use case-driven development standpoint may be all you ever need.
Richard Denney
Austin, Texas
http://www.software-quality-consulting.com
Index
Download the Index
file related to this title.
Updates
Errata
Errata for Succeeding with Use Cases can be found on the author's web site