Cultivating Successful Software Development [Hardcover]

Scott Donaldson (Author), Stanley Siegel (Author)

Book Description

Publication Date: January 15, 1997

This book contains tips for developing high-quality software systems consistently. Its wealth of valuable advice on developing computer code, software-related products such as specification documents, databases, user's manuals, and test documents train readers to develop software systems that do what they are supposed to do and are delivered on time and within budget.

Editorial Reviews

From the Publisher

This book contains tips for developing high-quality software systems consistently. Its wealth of valuable advice on developing computer code, software-related products such as specification documents, databases, user's manuals, and test documents train readers to develop software systems that do what they are supposed to do and are delivered on time and within budget.

From the Inside Flap

We must not promise what we ought not, lest we be called on to perform what we cannot. -Attributed to Abraham Lincoln, speech delivered before the first Republican convention of Illinois, May 29, 1856, The Writings of Abraham Lincoln, ed. Arthur B. Lapsley, vol. 2, p. 249 (1905).


Software process is this book's focus. Processes examined include (1) project planning (2) software systems development, and (3) change control. We show you how to achieve effective communication between software customers and software developers. We show you how to measure software processes and the products they yield. We show you how to use measurements to improve processes and products. We show you how to implement processes by examining organizational cultural change factors. We show you how to plan pr ocess improvement so that you can bring about organizational cultural change. This book features the following:


Approximately 240 figures to help you quickly assimilate ideas and their relationships
A list of key ideas (called "nuggets") at the outset of each chapter (except the first) to help you work your way through the chapter and organize what you want to take from the chapter
Process diagrams that you can easily adapt to your environment
Annotated outlines to help you overcome the blank-page syndrome in committing your processes to writing.


We wrote this book because the software industry is struggling to find ways to achieve consistent success. In particular, we wrote this book to help software systems developers achieve consistency in turning out systems that do what they are supposed to do-on time and within budget. And we wrote this book to help software systems buyers and users get systems that do what they are supposed to do-on time and within budget.


This book is for software practitioners. People are still the most important part of the equation for successful software development projects. As competition continues to increase and budgets continue to shrink, practitioners need to continue improving their skill sets. This book contains practical guidance for building good software systems consistently. Simply stated, our definition of a "good" software system is one that does what it is supposed to do and is delivered on time and within budget. Successf ul software systems development in this book means "consistently building good software systems." You are a software practitioner if you perform one or more of the following activities:


Develop computer code, software-related products such as specification documents, databases, user's manuals, and test documents. Directly manage people who do the preceding. Manage the preceding managers. Buy/use products from the preceding.


A practitioner can be new to the software game or can be a veteran. The newcomer will want to study and apply what is said; the veteran will want to adapt what is said. There is no one way to build software systems. If there were, software systems development would have been reduced to an assembly-line process long ago. However, we believe there are fundamental engineering and process principles whose application can increase the likelihood that software systems development projects will be successful. This book highlights and illustrates these principles so that you can apply them to your way of contracting for and/or building software systems.


This book stresses achieving consistent software development results. It helps the practitioner build a mature software systems development process so that consistently good systems are a natural outcome. As we explain, achieving maturity is more than a matter of defining engineering practices. Raising the maturity of your software systems development process is also an exercise in bringing about organizational cultural change. For example, if you are using the Software Engineering Institute's various capab ility maturity models to foster software development consistency in your organization, this book will help you institutionalize your processes. Similarly, if you are trying to gain, or maintain, ISO 9001 certification, this book can help you. Whatever your approach, this book can help you consistently achieve effective software systems development.


Figure P-1 captures the book's essence-cultivating successful software systems development. This book helps you acquire a green thumb for this cultivation exercise. If your organization has been in the software business for some time, we offer you guidance for nurturing what you have to achieve consistent success. If your organization is just getting started in the software business, we provide you with the tools and materials to grow your organization into one that consistently achieves software success. I f you are a software customer, we provide you with the means to nourish the client/developer environment so that it breeds software success. Just as growing crops is subject to many perils (such as bad weather, insects, and uncertain seed quality), so too is software systems development (e.g., unanticipated change, requirements creep, and miscommunication). Our objective is to help you anticipate these perils so that you consistently produce the software equivalent of good crops.


The book has the following eight chapters.

1.

Motivation, whose purpose is to convince you that the rest of the book is worth reading.

2.

Project Planning Process, whose purpose is to provide you with practical guidance for effectively planning software systems development work.

3.

Software Systems Development Process, whose purpose is to (1) define principles for putting together a software systems development process that breeds success and (2) illustrate these principles by defining a top-level process that you can use to formulate a process for your environment.

4.

Change Control Process, whose purpose is to define change control board (CCB) mechanics and provide you with practical guidance for setting up a CCB for your software systems development process.

5.

Product and Process Reviews, whose purpose is to describe basic processes associated with the various reviews called out in Chapter 3 as a means for reducing software systems development risk.

6.

Measurement, whose purpose is to provide you with practical guidance for measuring the "goodness" of products and the "goodness" of the software systems development process that produced the products; the focus is on how to use measurement to achieve consistent product and process "goodness."

7.

Cultural Change, whose purpose is to address human issues bearing on bringing about organizational cultural change during implementation of your systems engineering environment (SEE).

8.

Process Improvement Planning, whose purpose is to provide practical guidance on how to write an SEE implementation plan to establish the framework for doing the things discussed in the preceding chapters.


Table P-1 highlights what you will learn from each chapter. To help you extract each chapter's messages and subsequently apply its concepts, we condense each chapter's key points (except Chapter 1) into what we label "nuggets." In general, the material is organized to help you extract what you need. The book's approximately 240 figures aim at highlighting essential points. In these figures, we communicate ideas through icons to facilitate information retrieval and assimilation.


We also include worked-out examples containing sufficient detail so that you can adapt the concepts illustrated to your organization. For instance, in Chapter 6, we address measurement. We focus on two metrics that we call "product integrity index" and "process integrity index." We give general formulas for these indexes. We show you how to set up value scales for these indexes in terms that make sense to your organization. Through detailed, worked-out examples, we show you how to calculate these indexes. F inally, we explain what these numbers mean.


At the end of the book, we include an annotated bibliography. Most of the bibliographic entries have been selected because of their practitioner bent. This bibliography is intended to (1) point you to alternative treatments of topics that we discuss, (2) help you gain greater insight into topics that we address, and (3) help you pursue topics that we only touch upon that may be of greater interest to you.


The book's central concept for housing an organization's development processes is the systems engineering environment (SEE). The SEE consists of the following two complementary components:


An application development process environment (ADPE) and An application development technology environment (ADTE).


The ADPE is that set of policies, guidelines, procedures, and standards defining an organization's way of doing business. These entities we call "ADPE elements." The ADTE is that set of technologies (e.g., personal computers, networks, CASE tools) used to develop th

See all Editorial Reviews

Product Details

• Hardcover: 540 pages
• Publisher: Prentice Hall PTR; 1st edition (January 15, 1997)
• Language: English
• ISBN-10: 013341678X
• ISBN-13: 978-0133416787
• Product Dimensions: 10.1 x 8.1 x 1.2 inches
• Shipping Weight: 2.8 pounds
• Average Customer Review: 3.2 out of 5 stars  See all reviews (4 customer reviews)
• Amazon Best Sellers Rank: #3,180,314 in Books (See Top 100 in Books)

More About the Author

Discover books, learn about writers, read author blogs, and more.

Customer Reviews

Most Helpful Customer Reviews

6 of 7 people found the following review helpful:

2.0 out of 5 stars State of the Art in Software Engineering..., June 12, 2001

By 

"nigel_ht" (Columbia, MD United States) - See all my reviews

This review is from: Cultivating Successful Software Development (Hardcover)

.

...for 1994.

The book is a typical example of the literature available when SEI CMM was the next silver bullet to save our industry from the dreaded "software lottery" that everyone loses (a favorite phrase of the authors).

The authors come from a DoD background and it shows with their selection of methodologies and recommendations. There is a lot of good information in here, but they don't cover many alternative concepts to how DoD builds software. Can you develop good software following this book?

Sure.

On the other hand, the same sort of methodology was used on the FAA AAS project...one of the industry's classic software disaster stories.

Take for example, the authors assertion that the basis for customer input and understanding customer needs (and the resulting project artifacts) is the Statement of Work. Which is technically true for government contracts from a contractural point of view. From an engineering point of view, a better basis of understanding customer desires is a careful analysis of current and desired workflow...on site, watching real users perform the activities that makes their businesses run.

We have a moderately large body of more recent literature that suggests that this is a (much) better method to capture user requirements and expectations than traditional DoD methodology.

There are more examples of this kind of bias but what is most damning about this book are the examples they use. Their discussion on product assurance (pg 39) has an example where product assurance testers find problems with software on the Friday before a delivery and the management "can focus its attention and resources on those areas that must be redone for Monday's release".

Excuse me?

This example is so bad on so many levels that one wonders if this is actually how SAIC does business. Certainly, I would expect that for practitioners in a "mature organization" this sort of example wouldn't even come to mind.

Likewise, the example solution on page 94 on how a CCB might respond to the problem of staff turnover is cross training. Of course this doesn't solve any of the root causes for staff turnover or even the fact that you now have N-1 programmers to do the work of N programmers.

Obviously for authors that blithely accepts that testing occurs the last minute and that programmers should work on weekends this is more than acceptable "solution".

The reason why these kinds of examples are damning is because examples are often better insight into what is actually practiced and internalized by the authors rather than the ideals presented in the book.

2 of 2 people found the following review helpful:

4.0 out of 5 stars Too Much in Too Samll a Package., May 22, 2000

By 

Graduate Software Engineering Student - See all my reviews

This review is from: Cultivating Successful Software Development (Hardcover)

I think this resource is better for reference purposes than it is for comprehension. The charts, forms, tables, graphics and flowcharts are great, but the reading itself and its presentation, e.g. the font size, need correction or refinement. This book helped me to understand important process, project management, and software engineering concepts, and when combined with other SW Eng resources, such as Pfleeger's SW Engineering (PH, 1998) makes a great resource.

1 of 1 people found the following review helpful:

5.0 out of 5 stars My Favorite Reference, August 23, 2001

By A Customer

This review is from: Cultivating Successful Software Development (Hardcover)

I've just ordered my second copy of this book (to replace one that vanished from my desk - I simply did not want to be without it). As a software development manager with fifteen years experience I find this book very valuable - it is logically laid out and has excellent visuals. I refer to it on a regular basis to help me put my thoughts in order and to jog my memory when I'm planning, documenting, and training.