Columns by the SEI's Watts Humphrey

The Watts New? Collection: Columns by the SEI’s Watts Humphrey Watts S. Humphrey November 2009 SPECIAL REPORT CMU/SEI-2009-SR-024 Software Engineering Process Management (SEPM) Program Unlimited distribution subject to the copyright. http://www.sei.cmu.edu This report was prepared for the SEI Administrative Agent ESC/XPK 5 Eglin Street Hanscom AFB, MA 01731-2100 The ideas and findings in this report should not be construed as an official DoD position. It is published in the interest of scientific and technical information exchange. This work is sponsored by the U.S. Department of Defense. The Software Engineering Institute is a federally funded research and development center sponsored by the U.S. Department of Defense. Copyright 2009 Carnegie Mellon University. NO WARRANTY THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN "AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. Use of any trademarks in this report is not intended in any way to infringe on the rights of the trademark holder. Internal use. Permission to reproduce this document and to prepare derivative works from this document for internal use is granted, provided the copyright and "No Warranty" statements are included with all reproductions and derivative works. External use. This document may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting formal permission. Permission is required for any other external and/or commercial use. Requests for permission should be directed to the Software Engineering Institute at [email protected]. This work was created in the performance of Federal Government Contract Number FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The Government of the United States has a royalty-free government-purpose license to use, duplicate, or disclose the work, in whole or in part and in any manner, and to have or permit others to do so, for government purposes pursuant to the copyright license under the clause at 252.227-7013. Table of Contents Introduction 1 1 Why Does Software Work Take So Long? 3 Working Harder 3 Interruptions 4 Non-Project Work 4 Lean And Mean Organizations 5 Ad-Hoc Working And Planning 5 You Also Need An Occasional Break 6 So, Keep Track of Your Time 6 Manage Interruptions 6 Learn to Use Administrative Support 9 Plan Every Job 9 Vary Your Work 9 Define and Use a Personal Process 9 Get and Use Historical Data 9 Acknowledgements 10 2 Your Date or Mine? 11 Getting Into Trouble 11 Pressure 11 The Problems With Pressure 12 I Told You So 12 Negotiating Schedules 12 Handling Pressure 13 Be Flexible But Firm 13 Answering Management 14 How Does This Work 14 The Next Steps 14 Final Comments 15 Acknowledgements 15 3 Making Team Plans 17 How Do They Make A Plan When They Don't Know the Requirements? 17 Plan Accuracy 17 How Detailed Should They Make the Plan, And How Much of the Project Should They Cover? 17 Start With the Process, Then List the Products And Make An Estimate 18 Make the Schedule 18 Next Came the Detailed Plan 19 What Happened 19 Teamwork 19 Closing Comments 20 The Commercial 21 Acknowledgements 21 i | CMU/SEI-2009-SR-024 4 Bugs or Defects? 23 Do Defects Really Matter? 23 Do They Matter To You? 23 Why Not Just Worry About The Serious Defects? 24 How Many Defects Are Serious? 24 Won’t the Compiler Find Them? 24 How About Exhaustive Testing? 25 Just How Many Defects Are There? 25 Consider Some Data 25 But Why Not Call Them “Bugs”? 26 We Think In Language 27 Acknowledgements 27 References 27 5 Doing Disciplined Work 29 What Is Disciplined Work? 29 Why Is Disciplined Work Important? 29 What Are the Elements of Disciplined Engineering Work? 30 Getting the Needed Skills 30 Why Not Just Do It? 30 Personal Discipline 31 Coaching and Support 31 What Kind of Support Do We Need? 31 Acknowledgements 31 6 Getting Management Support for Process Improvement 33 Obtaining Broad Management Support 33 Why Do You Want To Make Changes? 33 Which Managers Do You Need Support From? 34 Why Should This Manager Support You? 35 Getting Help From a Senior Manager 35 Getting Help At the First Management Level 36 Acknowledgements 36 7 Making the Strategic Case for Process Improvement 37 The General Improvement Case 37 Defining the Proposal 37 Understand Today’s Business Environment 38 Identify the Hot Buttons 38 Make an Improvement Sanity Check 38 Prototype Introduction 38 Introduction Costs 39 The Continuing Costs 39 The Process-Improvement Benefits 40 Improvement Experience 40 Calculating the Savings 40 Measuring the Benefits 41 Other Benefits 41 Stay Tuned 41 Letter to Business Week 41 Acknowledgements 42 ii | CMU/SEI-2009-SR-024 8 Justifying a Process Improvement Proposal 43 The Financial Justification Process 43 Phase 1: Decide What to Do 43 Phase 2: Estimate the Likely Costs 44 Estimating the Labor Costs 44 Support Costs 44 External Costs 45 Lost Opportunity Costs 45 Phase 3: Estimate the Likely Improvement Benefits 46 Identify Available Improvement Data 46 Organizational Performance Data 46 Estimate the Likely Cost Savings 46 Cycle-Time Benefits 47 Phase 4: Produce the Improvement Proposal 48 Phase 5: Close the Deal 48 Closing Comments 49 Stay Tuned In 49 Acknowledgements 49 References 50 9 Making the Tactical Case for Process Improvement 51 The Tactical Situation 51 Possible Approaches 51 Making a Strategic Improvement Program Tactically Attractive 52 Build a Small Effort into a Strategic Program 52 Suggested Tactical Improvement Priorities 53 Code Inspections 53 Design Courses 53 The PSP and TSP 54 The Commitment System 54 Acknowledgements 55 A Note to My Readers 55 References 55 10 Moving the Goal Posts 57 Brownian Motion 57 When the Problems Change, the Solutions Must Also Change 57 Finding the Goal Posts 58 Human Failings 58 What this Means for Process Improvement 58 The Implications for the Future 59 Acknowledgements 60 iii | CMU/SEI-2009-SR-024 11 The Future of Software Engineering: Part I 61 Current Trends 61 Application Program Quality 62 Growing Program Complexity 62 The Defect Content of Programs 62 An Application Quality Example 63 The Quality Problem 64 The Impact of Poor Quality 65 Acknowledgements 65 References 65 12 The Future of Software Engineering: Part II 67 Some Facts 67 Future Needs 67 The Automobile Industry Analogy 68 The Computer Field Today 68 Growing System Size and Complexity 69 Reuse 69 Packaged Applications 70 Application Categories 71 Custom Application Programming 71 Acknowledgements 72 References 72 13 The Future of Software Engineering: Part III 73 The Objectives of Systems Programs 73 Early Trends in Systems Programs 73 The Operating Systems Business 74 Acknowledgements 76 References 76 14 The Future of Software Engineering: Part IV 77 Systems Programming 77 The Internet 78 Application Service Providers 78 The Time Scale 79 Kinds of OS Businesses 79 The Hardware-Coupled OS Business 80 The Standalone OS Business 80 The Open-Source OS Business 81 Middleware 81 Summary 81 Acknowledgements 82 References 82 iv | CMU/SEI-2009-SR-024 15 The Future of Software Engineering: Part V 83 The Kinds of Software Businesses 83 The Forces on Software Businesses 84 Software Size and Complexity 84 The Central Role of Software 85 Interconnectedness 85 Real-World Threats 86 What These Trends Will Mean to All of Us 86 The Accelerating Pace of Change 87 Some Final Comments 87 Acknowledgements 87 References 88 16 Surviving Failure 89 Keep Plugging Away 89 Look for Another Job 89 Fix the Problems 89 Think Like a Manager 90 Management Already Senses the Problem 90 Management Wants Solutions, Not Problems 90 Managers Do Not Want Competition 90 A Strategy for Survival 91 Understanding the Problem 91 Deciding How to Fix the Problem 91 Fix What You Can Yourself 92 Talking With Your Manager 92 Agree on the Next Steps 93 Conclusions 93 Acknowledgements 93 References 93 17 Learning from Hardware: Planning 95 Engineering and Craftsmanship 95 The Software Problem 95 The Pressure for Improvement 96 Software Background 96 Plan and Track the Work 96 The Key Questions 97 The Answers 97 Acknowledgements 98 References 98 v | CMU/SEI-2009-SR-024 18 Learning from Hardware: Design and Quality 99 Hardware Costs 99 The Design Release 99 The Need for Precise and Detailed Designs 100 The Need for Documented Software Designs 100 Separate Implementation 101 New and Innovative Products 101 Software Service Costs 102 Measure and Manage Quality 102 Quality and Fix Time 102 Engineered Software 103 Acknowledgements 103 Reference 103 19 Some Programming Principles: Requirements 105 The Programming Job 105 Understanding the Problem 106 Researching Problems 106 Getting Informed Input 107 Building Superior Products 107 Changing Problems and Products 108 Acknowledgements 108 20 Some Programming Principles: Products 109 The Nature of Computer Programs 109 The First Challenge: Software Work Is Intellectual 109 The Second Challenge: Software Is Not Manufactured 110 The Third Challenge: The Major Software Activities Are Creative 110 The Fourth Challenge: Software Lives Forever 111 The Fifth Challenge: Software Provides Product Uniqueness 112 The Sixth Challenge: Software Quality is Critical 112 Conclusions 113 Acknowledgements 113 21 Some Programming Principles: Projects 115 Project Schedule Performance 115 Project Cost Performance 116 Project Quality Performance 116 Project Success Criteria 117 Acknowledgements 117 vi | CMU/SEI-2009-SR-024 22 Some Programming Principles: People 119 The Performance of Software Professionals 119 People Principle Number 1 119 If the programmers do not understand the job they are to do, they will not do it very well.

Load more