How To Observe Software Systems
How To Observe Software Systems
$9.99
Minimum
$9.99
Suggested
How To Observe Software Systems

Last updated on 2014-08-31

About the Book

To consistently produce high-quality software in today's competitive marketplace, managers must have reliable information, obtained through careful observation and measurement. How to Observe Software Systems is a comprehensive guide to the basic measurement activities every organization must perform to manage the software development process.

Many management failures are caused by poor observation. First-Order Measurement tells how to observe properly with the aid of a four-step model to break the complex observation process into a series of smaller, simpler, steps. The book also defines the different levels of measurement, and describes the minimum set of activities in order to start a measurement program.

Numerous examples and diagrams illustrate the author's points, and exercises challenge readers to test their understanding of the concepts. Topics include

• why observation is important

• selecting what to observe

• visualizing the product

• visualizing the process

• pitfalls when making meaning from observations

• the direct observation of quality

• comparison of cost and value

• meta-measurement

This stand-alone text is the third in a series of volumes in which acclaimed author Gerald Weinberg explores the most difficult aspects of building high-quality software.

Table of Contents

  • How To Observe Software Systems
    • Preface
    • Acknowledgements
    • Introduction: A Model of Observation
    • Chapter 1. Why Observation is Important
      • 1.1 Management Failure: Crisis or Illusion?
      • 1.2. Seeing the Culture
        • 1.2.1. What is culture?
        • 1.2.2 Six Software sub-cultural patterns
        • 1.2.3 Surveying to discover your cultural pattern
      • 1.3 Cultural Observation Patterns in Action
        • 1.3.1 The Oblivious Culture
        • 1.3.2 The Variable Culture
        • 1.3.3 The Routine Organization
        • 1.3.4 The Steering Organization
        • 1.3.5. The Anticipating Organization (Pattern 4)
        • 1.3.6 The Congruent Organization(Pattern 5)
      • 1.4. Comparing the Effects of Observation Patterns
      • 1.5 Helpful Hints and Variations
      • 1.6 Summary
      • 1.7 Practice
    • Chapter 2: Selecting What to Observe
    • 2.1 The Intake Step
      • 2.1.1 Sensory intake
        • 2.1.2 Intake, not input
        • 2.1.3 All data are potential information
      • 2.2 The Parable of the Ones
      • 2.3 Requirements for an Effective Model of Observation
        • 2.3.1 What the observation model must do
        • 2.3.2 To what do you pay attention?
        • 2.3.3 The Rat Hair Rule
        • 2.3.4 A model tells how precisely to measure
      • 2.4 The Eye-Brain Law and the Brain-Eye Law
      • 2.5 Helpful Hints and Variations
      • 2.6 Summary
      • 2.7 Practice
    • Chapter 3: Visualizing the Product
      • 3.1 Sensory Modalities
      • 3.2 Making Software Visible
        • 3.2.1 Showing logic
        • 3.2.2 Showing quality
        • 3.2.3 Using sub-modalities to facilitate communication
        • 3.2.4 Combining sub-modalities to broaden communication
        • 3.2.5 Distortion or emphasis?
        • 3.2.6 How bad is distortion?
      • 3.3 Making Software Available for Observation
        • 3.3.1 Disguising the smell
        • 3.3.2 Visibility and control
        • 3.3.3 Visibility and participation
      • 3.4 Openness of the Product is the Key to Pattern 3
        • 3.4.1. Available to view:
        • 3.4. 2. Visualizable
        • 3.4. 3. Undistorted
      • 3.5 Helpful Hints and Variations
      • 3.6 Summary
      • 3.7 Practice
    • Chapter 4: Visualizing the Process
      • 4.1. Openness of the Process Is the Key to Pattern 4
        • 4.1.1 Availability to view
        • 4.1.2 Visualizable
        • 4.1.3 Undistorted
      • 4.2 Identifying the Pattern 4 Organization
        • 4.2.1. Available to view:
        • 4.2.2. Visualizable:
        • 4.2.3. Undistorted:
      • 4.3 A Process Picture Vocabulary
      • 4.3.1 Flow
        • 4.3.2 Cause and effect
        • 4.3.3 Distributions
        • 4.3.4 Trends
      • 4.4 The Project Control Panel
      • 4.5 Helpful Hints and Variations
      • 4.7 Practice
    • Part II. Meaning
    • Chapter 5: A Case Study of Interpretation
      • 5.1 The Slip Chart: Comparing Promise and Delivery
        • 5.1.1 Definitions
        • 5.1.2 Cultural revelations
        • 5.1.3 Slip-lead chart
      • 5.2 Interpretation of Company A’s Charts
      • 5.3 Interpretation of Company B’s Charts
        • 5.3.1 The project that’s afraid to finish
        • 5.3.2 The project that’s afraid of its own managers
        • 5.3.3 Company B’s culture
        • 5.3.4 Reactions are data
        • 5.3.5 Digging deeper
      • 5.4 Company C’s Culture
      • 5.5 Helpful Hints and Variations
      • 5.6 Summary
      • 5.7 Practice
    • Chapter 6: Pitfalls When Making Meaning from Observations
      • 6.1 The Rule of Three Interpretations
      • 6.2 The Data Question
        • 6.2.1 A typical interaction
        • 6.2.2 Applying the Data Question
      • 6.3 Interpreting Observations
      • 6.4 Spending Too Much Too Soon on Measurements
        • 6.4.1 Round 1: smaller projects
        • 6.4.2 Round 2: larger projects
        • 6.4.3 Meta-meaning
      • 6.5 Pitfalls
        • 6.5.1 No verification
        • 6.5.2 Unconsciously selected data
        • 6.5.3 Consciously selected data
        • 6.5.4 Misunderstanding
        • 6.5.5 Falsification
      • 6.6 Helpful Hints and Variations
      • 6.7 Summary
      • 6.8 Practice
    • Chapter 7: Direct Observation of Quality
      • 7.1 Quality Versus Apple Pie
        • 7.1.1 A survey of attitudes about quality
        • 7.1.2 What do people mean by quality?
        • 7.1.3 What does quality mean?
        • 7.1.4 Quality is relative
      • 7.2 An Example of the Relativity of Quality
      • 7.3 An Industry Out of Control of Quality
      • 7.4 Whose Ideas and Feelings Count?
        • 7.4.1 The IBM view of who counts
        • 7.4.2 The software developer’s view
        • 7.4.3 A balanced measure of quality
        • 7.4.4 The first measure of quality
      • 7.5 Helpful Hints and Variations
      • 7.6 Summary
      • 7.7 Practice
    • Chapter 8: Measuring Cost and Value
      • 8.1 Confusing Cost with Value
      • 8.2 What Is Value?
        • 8.2.1 Perceived value
        • 8.2.2 Collapse of value
        • 8.2.3 The Second Law of Thermodynamics
        • 8.2.4 The First Law of Human Nature
      • 8.3 The Role of Requirements in Observing Quality
        • 8.3.1 Direct measurement of quality
        • 8.3.2 Indirect measurement of quality
      • 8.4 The Detailed Impact Case Method
        • 8.4.1 Basic approach
        • 8.4.2 Key ideas
        • 8.4.3 Possible difficulties
        • 8.4.4 Sample report #1
      • 8.4.5 Notes on the detailed impact case study 1**
        • 8.4.6 Sample report #2
      • 8.5 Single Greatest Benefit Method
      • 8.5.1 Key ideas
        • 8.5.2 Possible difficulties
        • 8.5.3 Example Report #3
        • 8.5.4 Example Report #4
      • 8.6 Helpful Hints and Variations
      • 8.6 Summary
      • 8.7. Practice
    • Chapter 9: Meta-Measurement
      • 9.1 Inability to Know What’s Happening
        • 9.1.1 Imprecise accounting
        • 9.1.2 Project management breakdown
        • 9.1.3 Losing things
        • 9.1.4 Imprecise language and thought
        • 9.1.5 Intentional ignorance
      • 9.2 Lack of External Reference
      • 9.2.1 What standards?
      • 9.2.2 Goodbye to specifications
      • 9.3 Thinking You Know
        • 9.3.1 Not checking it out
        • 9.3.2 Quantity hiding lack of quality
        • 9.3.3 Pseudo-reviews hiding lack of reviewing
      • 9.4 Cutting Communication Lines
      • 9.4.1 Poor quality communication
        • 9.4.2 Failure to follow through
        • 9.4.3 Silence, gossip, rumors, and indirect action
        • 9.4.4 Isolation
        • 9.4.5 Denial of bad news
      • 9.5 Helpful Hints and Variations
      • 9.6 Summary
      • 9.7 Practice
    • Appendix A: The Diagram of Effects
    • Appendix B: The Software Engineering Cultural Patterns
        • Pattern 0. Oblivious Process
        • Pattern 1: Variable Process
        • Pattern 2: Routine Process
      • Pattern 3: Steering Process
      • Pattern 4: Anticipating Process
      • Pattern 5: Congruent Process
    • Appendix C. The Satir Interaction Model
      • Intake.
      • Meaning.
      • Significance.
      • Response.
    • Appendix D. Control Models
      • D.1. The Aggregate Control Model
      • D.2. Cybernetic Control Models
        • D.2.1 The system to be controlled (the focus of Patterns 0 and 1)
        • D.2.2 The controller (the focus of Pattern 2)
        • D.2.3 Feedback control (the focus of Pattern 3)
  • What Next?

Bundles that include this book

Agile Impressions
Freshman Murders
How Software Is Built
Why Software Gets In Trouble
How To Observe Software Systems
11 Books
$106.89
Regular Price
$49.99
Bundle Price

About the Author

Gerald M. Weinberg
Gerald M. Weinberg

I've always been interested in helping smart people be happy and productive. To that end, I've published books on human behavior, including Weinberg on Writing: The Fieldstone Method, The Psychology of Computer Programming, Perfect Software and Other Fallacies, and an Introduction to General Systems Thinking. I've also written books on leadership including Becoming a Technical Leader, The Secrets of Consulting (Foreword by Virginia Satir), More Secrets of Consulting, and the nine-volume Quality Software series.

I try to incorporate my knowledge of science, engineering, and human behavior into all of my writing and consulting work (with writers, hi-tech researchers, software engineers, and people whose life-situation could require the use of a service dog). I write novels about such people, including The Aremac Project, Aremac Power, Jigglers, First Stringers, Second Stringers, The Hands of God, Freshman Murders, Where There's a Will There's a Murder, Earth's Endless Effort, and Mistress of Molecules—all about how my brilliant protagonists produce quality work and learn to be happy. My books that are not yet on Leanpub may be found as eBooks at <http://www.smashwords.com/profile/view/JerryWeinberg>; on Amazon at http://www.amazon.com/-/e/B000AP8TZ8; and at Barnes and Noble bookstore: http://tinyurl.com/4eudqk5.

Early in my career, I was the architect for the Project Mercury's space tracking network and designer of the world's first multiprogrammed operating system. I won the Warnier Prize, the Stevens Award, and the first Software Testing Professionals' Luminary Award, all for my writing on software quality. I was also elected a charter member of the Computing Hall of Fame in San Diego and chosen for the University of Nebraska Hall of Fame.

But the "award" I'm most proud of is the book, The Gift of Time (Fiona Charles, ed.) written by my student and readers for my 75th birthday. Their stories make me feel that I've been at least partially successful at helping smart people be happy.

The Leanpub 45-day 100% Happiness Guarantee

Within 45 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.

See full terms...

Write and Publish on Leanpub

Authors and publishers use Leanpub to publish amazing in-progress and completed ebooks, just like this one. You can use Leanpub to write, publish and sell your book as well! Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks. Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. It really is that easy.

Learn more about writing on Leanpub