Trustworthy Systems Through Quantitative Software Engineering

LAWRENCE BERNSTEIN is the Series Editor for the Quantitative Software Engineering Series, published by Wiley. Professor Bernstein is currently Industry Research Professor at the Stevens Institute of Technology. He previously pursued a distinguished executive career at Bell Laboratories. He is a Fellow of IEEE and ACM. C. M. YUHAS is a freelance writer who has published articles on network management in the IEEE Journal on Selected Areas in Communication and IEEE Network. She has a BA in English from Douglass College and an MA in communications from New York University.

• Preface xviiAcknowledgment xxvPart 1 Getting Started 11. Think Like an Engineer—Especially for Software 31.1 Making a Judgment 41.2 The Software Engineer’s Responsibilities 61.3 Ethics 61.4 Software Development Processes 111.5 Choosing a Process 121.5.1 No-Method “Code and Fix” Approach 151.5.2 Waterfall Model 161.5.3 Planned Incremental Development Process 181.5.4 Spiral Model: Planned Risk Assessment-Driven Process 181.5.5 Development Plan Approach 231.5.6 Agile Process: an Apparent Oxymoron 251.6 Reemergence of Model-Based Software Development 261.7 Process Evolution 271.8 Organization Structure 291.9 Principles of Sound Organizations 311.10 Short Projects—4 to 6 Weeks 331.10.1 Project 1: Automating Library Overdue Book Notices 331.10.2 Project 2: Ajax Transporters, Inc. Maintenance Project 341.11 Problems 352. People, Product, Process, Project—The Big Four 392.1 People: Cultivate the Guru and Support the Majority 402.1.1 How to Recognize a Guru 412.1.2 How to Attract a Guru to Your Project 422.1.3 How to Keep Your Gurus Working 432.1.4 How to Support the Majority 432.2 Product: “Buy Me!” 452.2.1 Reliable Software Products 462.2.2 Useful Software Products 472.2.3 Good User Experience 482.3 Process: “OK, How Will We Build This?” 492.3.1 Agile Processes 492.3.2 Object-Oriented Opportunities 532.3.3 Meaningful Metrics 602.4 Project: Making It Work 612.5 Problems 652.6 Additional Problems Based on Case Studies 67Part 2 Ethics and Professionalism 733. Software Requirements 753.1 What Can Go Wrong With Requirements 753.2 The Formal Processes 763.3 Robust Requirements 813.4 Requirements Synthesis 843.5 Requirements Specification 863.6 Quantitative Software Engineering Gates 873.7 sQFD 883.8 ICED-T Metrics 913.8.1 ICED-T Insights 923.8.2 Using the ICED-T Model 943.9 Development Sizing and Scheduling With Function Points 953.9.1 Function Point Analysis Experience 953.9.2 NCSLOC vs Function Points 963.9.3 Computing Simplified Function Points (sFP) 973.10 Case Study: The Case of the Emergency No-Show Service 983.11 Problems 1034. Prototyping 1074.1 Make It Work; Then Make It Work Right 1074.1.1 How to Get at the Governing Requirements 1084.1.2 Rapid Application Prototype 1084.1.3 What’s Soft Is Hard 1104.2 So What Happens Monday Morning? 1114.2.1 What Needs to Be Prototyped? 1114.2.2 How Do You Build a Prototype? 1124.2.3 How Is the Prototype Used? 1124.2.4 What Happens to the Prototype? 1144.3 It Works, But Will It Continue to Work? 1164.4 Case Study: The Case of the Driven Development 1164.4.1 Significant Results 1194.4.2 Lessons Learned 1224.4.3 Additional Business Histories 1234.5 Why Is Prototyping So Important? 1284.6 Prototyping Deficiencies 1304.7 Iterative Prototyping 1304.8 Case Study: The Case of the Famished Fish 1314.9 Problems 1335. Architecture 1375.1 Architecture Is a System’s DNA 1375.2 Pity the Poor System Administrator 1395.3 Software Architecture Experience 1415.4 Process and Model 1425.5 Components 1445.5.1 Components as COTS 1445.5.2 Encapsulation and Abstraction 1455.5.3 Ready or Not, Objects Are Here 1465.6 UNIX 1485.7 Tl1 1495.7.1 Mission 1505.7.2 Comparative Analysis 1515.7.3 Message Formatting 1525.7.4 TL1 Message Formulation 1525.7.5 Industry Support of TL1 1525.8 Documenting the Architecture 1535.8.1 Debriefing Report 1545.8.2 Lessons Learned 1545.8.3 Users of Architecture Documentation 1545.9 Architecture Reviews 1555.10 Middleware 1565.11 How Many Times Before We Learn? 1585.11.1 Comair Cancels 1100 Flights on Christmas 2004 1585.11.2 Air Traffic Shutdown in September 2004 1595.11.3 NASA Crashes into Mars, 2004 1595.11.4 Case Study: The Case of the Preempted Priorities 1605.12 Financial Systems Architecture 1635.12.1 Typical Business Processes 1635.12.2 Product-Related Layer in the Architecture 1645.12.3 Finding Simple Components 1655.13 Design and Architectural Process 1665.14 Problems 1706. Estimation, Planning, and Investment 1736.1 Software Size Estimation 1746.1.1 Pitfalls and Pratfalls 1746.1.2 Software Size Metrics 1756.2 Function Points 1766.2.1 Fundamentals of FPA 1766.2.2 Brief History 1766.2.3 Objectives of FPA 1776.2.4 Characteristics of Quality FPA 1776.3 Five Major Elements of Function Point Counting 1776.3.1 EI 1776.3.2 EO 1786.3.3 EQ 1786.3.4 ILF 1786.3.5 EIF 1796.4 Each Element Can Be Simple, Average, or Complex 1796.5 Sizing an Automation Project With FPA 1826.5.1 Advantages of Function Point Measurement 1836.5.2 Disadvantages of Function Point Measurement 1846.5.3 Results Common to FPA 1846.5.4 FPA Accuracy 1856.6 NCSLOC Metric 1866.6.1 Company Statistics 1876.6.2 Reuse 1876.6.3 Wideband Delphi 1896.6.4 Disadvantages of SLOC 1906.7 Production Planning 1926.7.1 Productivity 1926.7.2 Mediating Culture 1926.7.3 Customer Relations 1936.7.4 Centralized Support Functions 1936.8 Investment 1956.8.1 Cost Estimation Models 1956.8.2 COCOMO 1976.8.3 Scheduling Tools—PERT, Gantt 2056.8.4 Project Manager’s Job 2076.9 Example: Apply the Process to a Problem 2086.9.1 Prospectus 2086.9.2 Measurable Operational Value (MOV) 2096.9.3 Requirements Specification 2096.9.4 Schedule, Resources, Features—What to Change? 2146.10 Additional Problems 2167. Design for Trustworthiness 2237.1 Why Trustworthiness Matters 2247.2 Software Reliability Overview 2257.3 Design Reviews 2287.3.1 Topics for Design Reviews 2297.3.2 Modules, Interfaces, and Components 2307.3.3 Interfaces 2347.3.4 Software Structure Influences Reliability 2367.3.5 Components 2387.3.6 Open&Closed Principle 2387.3.7 The Liskov Substitution Principle 2397.3.8 Comparing Object-Oriented Programming With Componentry 2407.3.9 Politics of Reuse 2407.4 Design Principles 2437.4.1 Strong Cohesion 2437.4.2 Weak Coupling 2437.4.3 Information Hiding 2447.4.4 Inheritance 2447.4.5 Generalization/Abstraction 2447.4.6 Separation of Concerns 2457.4.7 Removal of Context 2457.5 Documentation 2467.6 Design Constraints That Make Software Trustworthy 2487.6.1 Simplify the Design 2487.6.2 Software Fault Tolerance 2497.6.3 Software Rejuvenation 2517.6.4 Hire Good People and Keep Them 2547.6.5 Limit the Language Features Used 2547.6.6 Limit Module Size and Initialize Memory 2557.6.7 Check the Design Stability 2557.6.8 Bound the Execution Domain 2597.6.9 Engineer to Performance Budgets 2607.6.10 Reduce Algorithm Complexity 2637.6.11 Factor and Refactor 2667.7 Problems 268Part 3 Taking the Measure of the System 2758. Identifying and Managing Risk 2778.1 Risk Potential 2788.2 Risk Management Paradigm 2798.3 Functions of Risk Management 2798.4 Risk Analysis 2808.5 Calculating Risk 2828.6 Using Risk Assessment in Project Development: The Spiral Model 2868.7 Containing Risks 2898.7.1 Incomplete and Fuzzy Requirements 2898.7.2 Schedule Too Short 2908.7.3 Not Enough Staff 2918.7.4 Morale of Key Staff Is Poor 2928.7.5 Stakeholders Are Losing Interest 2958.7.6 Untrustworthy Design 2958.7.7 Feature Set Is Not Economically Viable 2968.7.8 Feature Set Is Too Large 2968.7.9 Technology Is Immature 2968.7.10 Late Planned Deliveries of Hardware and Operating System 2988.8 Manage the Cost Risk to Avoid Outsourcing 2998.8.1 Technology Selection 3008.8.2 Tools 3008.8.3 Software Manufacturing 3008.8.4 Integration, Reliability, and Stress Testing 3018.8.5 Computer Facilities 3018.8.6 Human Interaction Design and Documentation 3018.9 Software Project Management Audits 3038.10 Running an Audit 3048.11 Risks with Risk Management 3048.12 Problems 3059. Human Factors in Software Engineering 3099.1 A Click in the Right Direction 3099.2 Managing Things, Managing People 3129.2.1 Knowledge Workers 3139.2.2 Collaborative Management 3139.3 FAA Rationale for Human Factors Design 3169.4 Reach Out and Touch Something 3199.4.1 Maddening Counterintuitive Cues 3199.4.2 GUI 3199.4.3 Customer Care and Web Agents 3199.5 System Effectiveness in Human Factors Terms 3209.5.1 What to Look for in COTS 3209.5.2 Simple Guidelines for Managing Development 3229.6 How Much Should the System Do? 3239.6.1 Screen Icon Design 3249.6.2 Short- and Long-Term Memory 3269.7 Emerging Technology 3279.8 Applying the Principles to Developers 3349.9 The Bell Laboratories Philosophy 3369.10 So You Want to Be a Manager 3389.11 Problems 33810. Implementation Details 34410.1 Structured Programming 34510.2 Rational Unified Process and Unified Modeling Language 34610.3 Measuring Complexity 35310.4 Coding Styles 36010.4.1 Data Structures 36010.4.2 Team Coding 36310.4.3 Code Reading 36410.4.4 Code Review 36410.4.5 Code Inspections 36410.5 A Must Read for Trustworthy Software Engineers 36510.6 Coding for Parallelism 36610.7 Threats 36610.8 Open-Source Software 36810.9 Problems 36911. Testing and Configuration Management 37211.1 The Price of Quality 37311.1.1 Unit Testing 37311.1.2 Integration Testing 37311.1.3 System Testing 37311.1.4 Reliability Testing 37411.1.5 Stress Testing 37411.2 Robust Testing 37411.2.1 Robust Design 37411.2.2 Prototypes 37511.2.3 Identify Expected Results 37511.2.4 Orthogonal Array Test Sets (OATS) 37611.3 Testing Techniques 37611.3.1 One-Factor-at-a-Time 37711.3.2 Exhaustive 37711.3.3 Deductive Analytical Method 37711.3.4 Random/Intuitive Method 37711.3.5 Orthogonal Array-Based Method 37711.3.6 Defect Analysis 37811.4 Case Study: The Case of the Impossible Overtime 37911.5 Cooperative Testing 38011.6 Graphic Footprint 38211.7 Testing Strategy 38411.7.1 Test Incrementally 38411.7.2 Test Under No-Load 38411.7.3 Test Under Expected-Load 38411.7.4 Test Under Heavy-Load 38411.7.5 Test Under Overload 38511.7.6 Reject Insufficiently Tested Code 38511.7.7 Diabolic Testing 38511.7.8 Reliability Tests 38511.7.9 Footprint 38511.7.10 Regression Tests 38511.8 Software Hot Spots 38611.9 Software Manufacturing Defined 39211.10 Configuration Management 39311.11 Outsourcing 39811.11.1 Test Models 39811.11.2 Faster Iteration 40011.11.3 Meaningful Test Process Metrics 40011.12 Problems 40012. The Final Project: By Students, For Students 40412.1 How to Make the Course Work for You 40412.2 Sample Call for Projects 40512.3 A Real Student Project 40712.4 The Rest of the Story 42812.5 Our Hope 428Index 429

"In a study, the book was found to be successful at significantly increasing the students' willingness and competency in using good software engineering processes." (Computing Reviews.com, May 10, 2006) "…the book is an excellent and very readable guide to the development of reliable software, augmented with humor, case studies, useful tidbits…highly recommended for all software engineers." (CHOICE, March 2006)