Trustworthy Systems Through Quantitative Software Engineering

by Bernstein, Lawrence; Yuhas, C. M.

• ISBN13: 9780471696919
• ISBN10: 0471696919
• Edition: 1st
• Format: Hardcover
• Copyright: 2005-10-19
• Publisher: Wiley-IEEE Computer Society Pr

Summary

A benchmark text on software development and quantitative software engineering "We all trust software. All too frequently, this trust is misplaced. Larry Bernstein has created and applied quantitative techniques to develop trustworthy software systems. He and C. M. Yuhas have organized this quantitative experience into a book of great value to make software trustworthy for all of us." -Barry Boehm Trustworthy Systems Through Quantitative Software Engineering proposes a novel, reliability-driven software engineering approach, and discusses human factors in software engineering and how these affect team dynamics. This practical approach gives software engineering students and professionals a solid foundation in problem analysis, allowing them to meet customers' changing needs by tailoring their projects to meet specific challenges, and complete projects on schedule and within budget. Specifically, it helps developers identify customer requirements, develop software designs, manage a software development team, and evaluate software products to customer specifications. Students learn "magic numbers of software engineering," rules of thumb that show how to simplify architecture, design, and implementation. Case histories and exercises clearly present successful software engineers' experiences and illustrate potential problems, results, and trade-offs. Also featuring an accompanying Web site with additional and related material, Trustworthy Systems Through Quantitative Software Engineering is a hands-on, project-oriented resource for upper-level software and computer science students, engineers, professional developers, managers, and professionals involved in software engineering projects. An Instructor's Manual presenting detailed solutions to all the problems in the book is available from the Wiley editorial department. An Instructor Support FTP site is also available.

Author Biography

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.

Table of Contents

PREFACE	xvii
ACKNOWLEDGMENT	xxv
PART 1 GETTING STARTED	1	(72)
1. Think Like an Engineer—Especially for Software	3	(36)
1.1 Making a Judgment	4	(2)
1.2 The Software Engineer's Responsibilities	6	(1)
1.3 Ethics	6	(5)
1.4 Software Development Processes	11	(1)
1.5 Choosing a Process	12	(14)
1.5.1 No-Method "Code and Fix" Approach	15	(1)
1.5.2 Waterfall Model	16	(2)
1.5.3 Planned Incremental Development Process	18	(1)
1.5.4 Spiral Model: Planned Risk Assessment-Driven Process	18	(5)
1.5.5 Development Plan Approach	23	(2)
1.5.6 Agile Process: an Apparent Oxymoron	25	(1)
1.6 Reemergence of Model-Based Software Development	26	(1)
1.7 Process Evolution	27	(2)
1.8 Organization Structure	29	(2)
1.9 Principles of Sound Organizations	31	(2)
1.10 Short Projects-4 to 6 Weeks	33	(2)
1.10.1 Project 1: Automating Library Overdue Book Notices	33	(1)
1.10.2 Project 2: Ajax Transporters, Inc. Maintenance Project	34	(1)
1.11 Problems	35	(4)
2. People, Product, Process, Project—The Big Four	39	(34)
2.1 People: Cultivate the Guru and Support the Majority	40	(5)
2.1.1 How to Recognize a Guru	41	(1)
2.1.2 How to Attract a Guru to Your Project	42	(1)
2.1.3 How to Keep Your Gurus Working	43	(1)
2.1.4 How to Support the Majority	43	(2)
2.2 Product: "Buy Me!"	45	(4)
2.2.1 Reliable Software Products	46	(1)
2.2.2 Useful Software Products	47	(1)
2.2.3 Good User Experience	48	(1)
2.3 Process: "OK, How Will We Build This?"	49	(12)
2.3.1 Agile Processes	49	(4)
2.3.2 Object-Oriented Opportunities	53	(7)
2.3.3 Meaningful Metrics	60	(1)
2.4 Project: Making It Work	61	(4)
2.5 Problems	65	(2)
2.6 Additional Problems Based on Case Studies	67	(6)
PART 2 ETHICS AND PROFESSIONALISM	73	(202)
3. Software Requirements	75	(32)
3.1 What Can Go Wrong With Requirements	75	(1)
3.2 The Formal Processes	76	(5)
3.3 Robust Requirements	81	(3)
3.4 Requirements Synthesis	84	(2)
3.5 Requirements Specification	86	(1)
3.6 Quantitative Software Engineering Gates	87	(1)
3.7 sQFD	88	(3)
3.8 ICED-T Metrics	91	(4)
3.8.1 ICED-T Insights	92	(2)
3.8.2 Using the ICED-T Model	94	(1)
3.9 Development Sizing and Scheduling With Function Points	95	(3)
3.9.1 Function Point Analysis Experience	95	(1)
3.9.2 NCSLOC vs Function Points	96	(1)
3.9.3 Computing Simplified Function Points (sFP)	97	(1)
3.10 Case Study: The Case of the Emergency No-Show Service	98	(5)
3.11 Problems	103	(4)
4. Prototyping	107	(30)
4.1 Make It Work; Then Make It Work Right	107	(4)
4.1.1 How to Get at the Governing Requirements	108	(1)
4.1.2 Rapid Application Prototype	108	(2)
4.1.3 What's Soft Is Hard	110	(1)
4.2 So What Happens Monday Morning?	111	(5)
4.2.1 What Needs to Be Prototyped?	111	(1)
4.2.2 How Do You Build a Prototype?	112	(1)
4.2.3 How Is the Prototype Used?	112	(2)
4.2.4 What Happens to the Prototype?	114	(2)
4.3 It Works, But Will It Continue to Work?	116	(1)
4.4 Case Study: The Case of the Driven Development	116	(12)
4.4.1 Significant Results	119	(3)
4.4.2 Lessons Learned	122	(1)
4.4.3 Additional Business Histories	123	(5)
4.5 Why Is Prototyping So Important?	128	(2)
4.6 Prototyping Deficiencies	130	(1)
4.7 Iterative Prototyping	130	(1)
4.8 Case Study: The Case of the Famished Fish	131	(2)
4.9 Problems	133	(4)
5. Architecture	137	(36)
5.1 Architecture Is a System's DNA	137	(2)
5.2 Pity the Poor System Administrator	139	(2)
5.3 Software Architecture Experience	141	(1)
5.4 Process and Model	142	(2)
5.5 Components	144	(4)
5.5.1 Components as COTS	144	(1)
5.5.2 Encapsulation and Abstraction	145	(1)
5.5.3 Ready or Not, Objects Are Here	146	(2)
5.6 UNIX	148	(1)
5.7 TL1	149	(4)
5.7.1 Mission	150	(1)
5.7.2 Comparative Analysis	151	(1)
5.7.3 Message Formatting	152	(1)
5.7.4 TL1 Message Formulation	152	(1)
5.7.5 Industry Support of TL1	152	(1)
5.8 Documenting the Architecture	153	(2)
5.8.1 Debriefing Report	154	(1)
5.8.2 Lessons Learned	154	(1)
5.8.3 Users of Architecture Documentation	154	(1)
5.9 Architecture Reviews	155	(1)
5.10 Middleware	156	(2)
5.11 How Many Times Before We Learn?	158	(5)
5.11.1 Comair Cancels 1100 Flights on Christmas 2004	158	(1)
5.11.2 Air Traffic Shutdown in September 2004	159	(1)
5.11.3 NASA Crashes into Mars, 2004	159	(1)
5.11.4 Case Study: The Case of the Preempted Priorities	160	(3)
5.12 Financial Systems Architecture	163	(3)
5.12.1 Typical Business Processes	163	(1)
5.12.2 Product-Related Layer in the Architecture	164	(1)
5.12.3 Finding Simple Components	165	(1)
5.13 Design and Architectural Process	166	(4)
5.14 Problems	170	(3)
6. Estimation, Planning, and Investment	173	(50)
6.1 Software Size Estimation	174	(2)
6.1.1 Pitfalls and Pratfalls	174	(1)
6.1.2 Software Size Metrics	175	(1)
6.2 Function Points	176	(1)
6.2.1 Fundamentals of FPA	176	(1)
6.2.2 Brief History	176	(1)
6.2.3 Objectives of FPA	177	(1)
6.2.4 Characteristics of Quality FPA	177	(1)
6.3 Five Major Elements of Function Point Counting	177	(2)
6.3.1 EI	177	(1)
6.3.2 E0	178	(1)
6.3.3 EQ	178	(1)
6.3.4 ILF	178	(1)
6.3.5 EIF	179	(1)
6.4 Each Element Can Be Simple, Average, or Complex	179	(3)
6.5 Sizing an Automation Project With FPA	182	(4)
6.5.1 Advantages of Function Point Measurement	183	(1)
6.5.2 Disadvantages of Function Point Measurement	184	(1)
6.5.3 Results Common to FPA	184	(1)
6.5.4 FPA Accuracy	185	(1)
6.6 NCSLOC Metric	186	(6)
6.6.1 Company Statistics	187	(1)
6.6.2 Reuse	187	(2)
6.6.3 Wideband Delphi	189	(1)
6.6.4 Disadvantages of SLOC	190	(2)
6.7 Production Planning	192	(3)
6.7.1 Productivity	192	(1)
6.7.2 Mediating Culture	192	(1)
6.7.3 Customer Relations	193	(1)
6.7.4 Centralized Support Functions	193	(2)
6.8 Investment	195	(13)
6.8.1 Cost Estimation Models	195	(2)
6.8.2 COCOMO	197	(8)
6.8.3 Scheduling Tools—PERT, Gantt	205	(2)
6.8.4 Project Manager's Job	207	(1)
6.9 Example: Apply the Process to a Problem	208	(8)
6.9.1 Prospectus	208	(1)
6.9.2 Measurable Operational Value (MOV)	209	(1)
6.9.3 Requirements Specification	209	(5)
6.9.4 Schedule, Resources, Features—What to Change?	214	(2)
6.10 Additional Problems	216	(7)
7. Design for Trustworthiness	223	(52)
7.1 Why Trustworthiness Matters	224	(1)
7.2 Software Reliability Overview	225	(3)
7.3 Design Reviews	228	(15)
7.3.1 Topics for Design Reviews	229	(1)
7.3.2 Modules, Interfaces, and Components	230	(4)
7.3.3 Interfaces	234	(2)
7.3.4 Software Structure Influences Reliability	236	(2)
7.3.5 Components	238	(1)
7.3.6 Open&Closed Principle	238	(1)
7.3.7 The Liskov Substitution Principle	239	(1)
7.3.8 Comparing Object-Oriented Programming With Componentry	240	(1)
7.3.9 Politics of Reuse	240	(3)
7.4 Design Principles	243	(3)
7.4.1 Strong Cohesion	243	(1)
7.4.2 Weak Coupling	243	(1)
7.4.3 Information Hiding	244	(1)
7.4.4 Inheritance	244	(1)
7.4.5 Generalization Abstraction	244	(1)
7.4.6 Separation of Concerns	245	(1)
7.4.7 Removal of Context	245	(1)
7.5 Documentation	246	(2)
7.6 Design Constraints That Make Software Trustworthy	248	(20)
7.6.1 Simplify the Design	248	(1)
7.6.2 Software Fault Tolerance	249	(2)
7.6.3 Software Rejuvenation	251	(3)
7.6.4 Hire Good People and Keep Them	254	(1)
7.6.5 Limit the Language Features Used	254	(1)
7.6.6 Limit Module Size and Initialize Memory	255	(1)
7.6.7 Check the Design Stability	255	(4)
7.6.8 Bound the Execution Domain	259	(1)
7.6.9 Engineer to Performance Budgets	260	(3)
7.6.10 Reduce Algorithm Complexity	263	(3)
7.6.11 Factor and Refactor	266	(2)
7.7 Problems	268	(7)
PART 3 TAKING THE MEASURE OF THE SYSTEM	275	(154)
8. Identifying and Managing Risk	277	(32)
8.1 Risk Potential	278	(1)
8.2 Risk Management Paradigm	279	(1)
8.3 Functions of Risk Management	279	(1)
8.4 Risk Analysis	280	(2)
8.5 Calculating Risk	282	(4)
8.6 Using Risk Assessment in Project Development: The Spiral Model	286	(3)
8.7 Containing Risks	289	(10)
8.7.1 Incomplete and Fuzzy Requirements	289	(1)
8.7.2 Schedule Too Short	290	(1)
8.7.3 Not Enough Staff	291	(1)
8.7.4 Morale of Key Staff Is Poor	292	(3)
8.7.5 Stakeholders Are Losing Interest	295	(1)
8.7.6 Untrustworthy Design	295	(1)
8.7.7 Feature Set Is Not Economically Viable	296	(1)
8.7.8 Feature Set Is Too Large	296	(1)
8.7.9 Technology Is Immature	296	(2)
8.7.10 Late Planned Deliveries of Hardware and Operating System	298	(1)
8.8 Manage the Cost Risk to Avoid Outsourcing	299	(4)
8.8.1 Technology Selection	300	(1)
8.8.2 Tools	300	(1)
8.8.3 Software Manufacturing	300	(1)
8.8.4 Integration, Reliability, and Stress Testing	301	(1)
8.8.5 Computer Facilities	301	(1)
8.8.6 Human Interaction Design and Documentation	301	(2)
8.9 Software Project Management Audits	303	(1)
8.10 Running an Audit	304	(1)
8.11 Risks with Risk Management	304	(1)
8.12 Problems	305	(4)
9. Human Factors in Software Engineering	309	(35)
9.1 A Click in the Right Direction	309	(3)
9.2 Managing Things, Managing People	312	(4)
9.2.1 Knowledge Workers	313	(1)
9.2.2 Collaborative Management	313	(3)
9.3 FAA Rationale for Human Factors Design	316	(3)
9.4 Reach Out and Touch Something	319	(1)
9.4.1 Maddening Counterintuitive Cues	319	(1)
9.4.2 GUI	319	(1)
9.4.3 Customer Care and Web Agents	319	(1)
9.5 System Effectiveness in Human Factors Terms	320	(3)
9.5.1 What to Look for in COTS	320	(2)
9.5.2 Simple Guidelines for Managing Development	322	(1)
9.6 How Much Should the System Do?	323	(4)
9.6.1 Screen Icon Design	324	(2)
9.6.2 Short- and Long-Term Memory	326	(1)
9.7 Emerging Technology	327	(7)
9.8 Applying the Principles to Developers	334	(2)
9.9 The Bell Laboratories Philosophy	336	(2)
9.10 So You Want to Be a Manager	338	(1)
9.11 Problems	338	(6)
10. Implementation Details	344	(28)
10.1 Structured Programming	345	(1)
10.2 Rational Unified Process and Unified Modeling Language	346	(7)
10.3 Measuring Complexity	353	(7)
10.4 Coding Styles	360	(5)
10.4.1 Data Structures	360	(3)
10.4.2 Team Coding	363	(1)
10.4.3 Code Reading	364	(1)
10.4.4 Code Review	364	(1)
10.4.5 Code Inspections	364	(1)
10.5 A Must Read for Trustworthy Software Engineers	365	(1)
10.6 Coding for Parallelism	366	(1)
10.7 Threats	366	(2)
10.8 Open-Source Software	368	(1)
10.9 Problems	369	(3)
11. Testing and Configuration Management	372	(32)
11.1 The Price of Quality	373	(1)
11.1.1 Unit Testing	373	(1)
11.1.2 Integration Testing	373	(1)
11.1.3 System Testing	373	(1)
11.1.4 Reliability Testing	374	(1)
11.1.5 Stress Testing	374	(1)
11.2 Robust Testing	374	(2)
11.2.1 Robust Design	374	(1)
11.2.2 Prototypes	375	(1)
11.2.3 Identify Expected Results	375	(1)
11.2.4 Orthogonal Array Test Sets (OATS)	376	(1)
11.3 Testing Techniques	376	(3)
11.3.1 One-Factor-at-a-Time	377	(1)
11.3.2 Exhaustive	377	(1)
11.3.3 Deductive Analytical Method	377	(1)
11.3.4 Random Intuitive Method	377	(1)
11.3.5 Orthogonal Array-Based Method	377	(1)
11.3.6 Defect Analysis	378	(1)
11.4 Case Study: The Case of the Impossible Overtime	379	(1)
11.5 Cooperative Testing	380	(2)
11.6 Graphic Footprint	382	(2)
11.7 Testing Strategy	384	(2)
11.7.1 Test Incrementally	384	(1)
11.7.2 Test Under No-Load	384	(1)
11.7.3 Test Under Expected-Load	384	(1)
11.7.4 Test Under Heavy-Load	384	(1)
11.7.5 Test Under Overload	385	(1)
11.7.6 Reject Insufficiently Tested Code	385	(1)
11.7.7 Diabolic Testing	385	(1)
11.7.8 Reliability Tests	385	(1)
11.7.9 Footprint	385	(1)
11.7.10 Regression Tests	385	(1)
11.8 Software Hot Spots	386	(6)
11.9 Software Manufacturing Defined	392	(1)
11.10 Configuration Management	393	(5)
11.11 Outsourcing	398	(2)
11.11.1 Test Models	398	(2)
11.11.2 Faster Iteration	400	(1)
11.11.3 Meaningful Test Process Metrics	400	(1)
11.12 Problems	400	(4)
12. The Final Project: By Students, For Students	404	(25)
12.1 How to Make the Course Work for You	404	(1)
12.2 Sample Call for Projects	405	(2)
12.3 A Real Student Project	407	(21)
12.4 The Rest of the Story	428	(1)
12.5 Our Hope	428	(1)
INDEX	429