Responding to Significant Software Events

Quality Software #2.2

by Gerald M. Weinberg

To consistently produce high-quality software in today's competitive marketplace, managers must have reliable information, obtained through careful observation and measurement. But measurement alone is insufficient to produce quality software. With measurements in hand, a manager must first interpret the significance of those measurements. Yet again, understanding significance is useless unless the manager responds appropriately.Responding to Significant Software Events is a comprehensive guide to those two basic measurement activities every organization must perform to manage the software development process.Many management failures occur even when observations are well done. Responding to Significant Software Events tells how to determine the significance of those observations, and then to respond with appropriate actions.Numerous examples and diagrams illustrate the author's points, and exercises challenge readers to test their understanding of the concepts. Topics include• measuring emotional significance• translating observation into action• dealing with swarms of failures* planning projects composed of measurable tasks• communicating about plans and progress• reviews as basic measurement tools• measuring failures before they happen• listening with precision• using requirements as the basis of measurement.This stand-alone text is the fourth in a series of volumes in which acclaimed author Gerald Weinberg explores the most difficult aspects of building high-quality software.

165 pages, Kindle Edition

First published January 3, 2011

About the author

Gerald Marvin Weinberg (October 27, 1933 – August 7, 2018) was an American computer scientist, author and teacher of the psychology and anthropology of computer software development.

Reviews

[Johnny · Rating 2 out of 5]

I’m very interested in metrics and like to base my decisions on data. I therefore looked forward to this part of the Software Quality series. Unfortunately the book doesn’t add much new insights or ideas. Too much is already present in Tom DeMarcos Controlling Software Projects: Management, Measurement, and Estimates that was written in 1986. I hoped that in the 25 years between those two books one would have gained new ideas and proven (or disproven) certain aspects. Judging by this book this was not the case.