Home > Store

Succeeding with Use Cases: Working Smart to Deliver Quality

Register your product to gain access to bonus material or receive a coupon.

Succeeding with Use Cases: Working Smart to Deliver Quality

Premium Website

  • Sorry, this book is no longer in print.
Not for Sale

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
  • Premium Website
  • 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.

Extras

Author's Site

Visit the Author's Web Site related to this title.

Sample Content

Online Sample Chapter

An Introduction to Use Cases and Quality Function Deployment: Driving Vision Vertically Through the Project

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

Untitled Document If the Unified Software Development Process (USDP) were a coloring book, I'm afraid I'd be characterized as one of those kids who just can't color within the lines. I've been using use-case-like "things" for quite some time, although they may have been called something else: workflows, scenarios when Object Modeling Technique (OMT) came out, and then eventually use cases. But the funny thing is, more often than not I wasn't using them like the USDP described them being used. Rather, I was combining them first with this technique, and then that one. It's not that I was trying to be a rebel; use cases just seemed to fit in nicely with other techniques to solve a problem. Eventually, as the USDP matured, I began to notice that others were starting to mention QFD in conjunction with use cases and discuss operational profiles of use cases. Scott Ambler added project portfolio management to his Enterprise Unified Process, an extension to USDP; and preconditions and postconditions actually became an official part of use cases. It finally occurred to me: other people were coloring outside the lines too! The motivation for this: problems that were best solved with techniques that were not a part of USDP proper; problems for which other disciplines already had solutions.

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

Untitled Document

Errata for Succeeding with Use Cases can be found on the author's web site

Submit Errata

More Information

Unlimited one-month access with your purchase
Free Safari Membership