Home > Store

Dare to be Excellent: Case Studies of Software Engineering Practices That Work

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

Dare to be Excellent: Case Studies of Software Engineering Practices That Work


  • Your Price: $26.39
  • List Price: $32.99
  • We're temporarily out of stock, but order now and we'll send it to you later.


  • Copyright 1999
  • Dimensions: 6" x 9"
  • Pages: 384
  • Edition: 1st
  • Book
  • ISBN-10: 0-13-081156-4
  • ISBN-13: 978-0-13-081156-1


Best practices from the world's highest-quality software development organizations.

Contrary to popular wisdom, you can build extraordinarily high-quality software-and this book shows you exactly how the world's best development organizations do it. From Cisco to Intel, Texas Instruments to Tandem, Dare To Be Excellent gives you an exclusive tour of today's software quality best practices. Each chapter describes a real-world problem, and exactly how it was identified, addressed and fixed-in detail. Dare To Be Excellent covers virtually the entire software lifecycle, including:

  • Project planning, management and support
  • Software requirements
  • Software reliability and automated testing
  • Release planning and metrics
  • Software inspections
  • Managing key client/vendor relationships
  • Software Development Process Handbook

By now, software engineering practices don't need to be defined; they need to be applied. Dare To Be Excellent shows how real organizations have gotten past obstacles that trip up so many companies. Even better, it shows how to fit best practices to your situation, instead of the other way around. Whether you're a developer, manager, tester or executive, you'll find proven ideas you can actually use to build higher-quality software starting right now.

Sample Content

Downloadable Sample Chapter

Click here for a sample chapter for this book: 0130811564.pdf

Table of Contents

1. REQUIREMENTS (Texas Instruments)

Company Profile. Basic Concepts of Requirements. Reasons To Implement. Elicitation And Analysis Of Di Business Requirements. Lessons Learned. Conclusions.

2. PROJECT PLANNING (Intel Corporation)

Company Profile. Intel Corporation's Landesk Products. Anti-Virus Products. Anti-Viral (AV)Technologies. Virus Protection Software. The Revival Plan. Cultural Issues. The Result—a New Generation of Award-Winning, Sustainable LDVP Products. Lessons Learned. Conclusions.


(PKS Information Services) Company Profile. Reasons to Implement. Company Philosophy. Technology Project Management Process. Culture Change. Implementation. Final Results. Lessons Learned. Conclusions. TPMP Sample.

4. PROJECT SUPPORT OFFICE (Royal Bank Financial Group)

Company Profile. Reasons To Implement. Culture Change. Project Office. Challenges. Customer Satisfaction. Conclusions.


(Primark Investment Management Services Limited) Company Profile. Reasons to Implement. Measures of Software Quality. What Do We Mean By Process? How Did We Get Started? Lessons Learned. Culture Change. Strategic Plans. Challenges. Conclusions.


(Digital Technology International) Company Profile. Basic Concepts and Goals of Software Reliability Engineering. Reasons To Implement. Solutions To the Problem. Culture Change. Project Plan/Time-Line. Implemention. Results. Lessons Learned. Conclusions.

7. RELEASE PLANNING (Cisco Systems)

Company Profile. Reasons To Implement. Release Process. Culture Change. Lessons Learned. Conclusions.

8. RELEASE METRICS (TANDEM Telecom Network Solutions)

Company Profile. Introduction. Reasons for Implementation. Obtaining Buy-In. Assessing Measurements. Description of the Rating. Calculating the Confidence Rating. Implementation. Release Management in Action. Results. Lessons Learned. Conclusions.


(Phoenix Technologies Limited) Company Profile. Why Phoenix Created a Process Handbook. Cultural Issues. Drafting the Software Development Handbook. Lessons Learned. Continuous Improvement. Conclusions.


(International Business Systems) Company Profile. Reason To Implement. Description of Process. The Handoff. Approach. Cultural Change. Project Plan/Time-Line. Results. Lessons Learned. Conclusions. Acryonyms/Abbreviations. References.




Software development has matured to the point where known engineering practices donÕt need to be defined, they need to be applied. We know what needs to happen, but the inevitable details of how to make it work are often a stumbling block. Too many times, discipline is sacrificed to competing needs and schedule constraints: Taking the time to do things may be viewed as an impractical ideal.

Nothing could be further from the truth, of course. Doing things right reaps continuous rewards that are no less valuable for being difficult to measure: reduced rework and support costs, improved time to market, and increased customer satisfaction. Because it is hard to measure the costs you avoid, but easy to track the costs you incur, the investment in process improvement may be more obvious than the rewards.

The trick is to follow the spirit of a process, not necessarily the form: depending on the size of the project and organizational environment, it may be wise to condense or circumscribe certain aspects. Fit the practice to the situation instead of the other way around.

There are quite a lot of software engineering practices in the world that are viewed to bring ÒsuccessÓ to your software development, and there are several books on theories of development practices. Often, you are at a loss to identify companies who may have implemented these theories. So, the question comes up: How do I know the theories described in a book really work? The best way to understand a process and how to implement it is through actual examples, which is what this book is all about.

The authors have extensive experience in several software engineering quality improvement techniques to know that what one large company does may not be appropriate for another small company, or that what works for a software development organization in one industrial segment may not work the same way in another. Over the years we have encountered software developers, quality assurance managers, ISO implementors, students, executives, managers, supervisors, consultants, and testers who asked us to give them examples of companies that introduced a process change and the logistics as well as the results of this change. This question inspired us to embark upon a journey to capture real scenarios.

We know most of you are faced with immediate problems of managing software development and do not have time to benchmark or improve current processes based on what has worked for others. Unfortunately, software development does not excel by implementing one or two simple techniques. It is an accumulation of many complex processes which requires integration of project controls and technical knowledge. Quality is built into software products through careful project management and processes that have been known to reduce defects and increase productivity.

Until now (this is the first!), there has been no book that describes case studies of software engineering principles under one cover. We have chosen a variety of companies, big and small, from different aspects of the overall industry such as financial, telecommunications, service, consulting, etc. Each of these companies chose a software improvement path and made a commitment to follow the path to see the ultimate results. Each company stumbled upon different road-blocks that they had to overcome.

This book presents what each company did, what their reason was for implementing the new process, what were the cultural issues, and what were the final results. So many times, we see an organization trying to implement a process change and then abnormally ending the project in search of a Òquick fix.Ó The cases of the companies represented in this book show a lot of perseverance, dedication, and good Òfollow-through.Ó The companies may not resemble your own, it is the way they applied a practice to make it succeed for them that is the most instructive: Not just what did or didnÕt work, but how and why. You can learn universal principles from the mistakes and successes of others.

This book seeks to convey an understanding of what worked in the software development process and how managing that process to obtain quality software while improving the overall productivity helped each company achieve a particular goal. Each chapter provides a comprehensive description of the process adhered by a specific company.

  • Chapter 1: Focuses on requirements.
  • Chapters 2, 3 and 4: Describe different aspects of project planning, project management, and project support office.
  • Chapter 5: Provides details of using inspections as an agent of change.
  • Chapter 6: Highlights software reliability.
  • Chapter 7: Talks about release planning.
  • Chapter 8: Gives you guidance on release metrics.
  • Chapter 9: Talks about creation of a Software Development Process Handbook.
  • Chapter 10: Discusses managing client/vendor relationships.

While we know the importance of software measurements, we have decided to direct our readers to Grady (1987).

This book captures case studies of companies who mastered an area of software development and who, by example, can guide your own efforts.


Submit Errata

More Information

Unlimited one-month access with your purchase
Free Safari Membership