SWEBOK Guide V3.0 May Be Downloaded Free of Charge for Personal and Academic Use Via

Home , IEEE 754, Requirements engineering, Semantic discord

Guide to the Software Engineering Body of Knowledge

Version 3.0

SWEBOK®

A Project of the IEEE Computer Society Guide to the Software Engineering Body of Knowledge

Version 3.0

Editors

Pierre Bourque, École de technologie supérieure (ÉTS) Richard E. (Dick) Fairley, Software and Systems Engineering Associates (S2EA) Copyright and Reprint Permissions. Educational or personal use of this material is permitted without fee provided such copies 1) are not made for profit or in lieu of purchasing copies for classes, and that this notice and a full citation to the original work appear on the first page of the copy and 2) do not imply IEEE endorsement of any third-party products or services. Permission to reprint/republish this material for commercial, advertising or promotional purposes or for creating new collective works for resale or redistribution must be obtained from IEEE by writing to the IEEE Intellectual Property Rights Office, 445 Hoes Lane, Piscataway, NJ 08854-4141 or [email protected].

Reference to any specific commercial products, process, or service does not imply endorsement by IEEE. The views and opin- ions expressed in this work do not necessarily reflect those of IEEE.

IEEE makes this document available on an “as is” basis and makes no warranty, express or implied, as to the accuracy, capability, efficiency merchantability, or functioning of this document. In no event will IEEE be liable for any general, consequential, indirect, incidental, exemplary, or special damages, even if IEEE has been advised of the possibility of such damages.

Digital copies of SWEBOK Guide V3.0 may be downloaded free of charge for personal and academic use via www.swebok.org.

IEEE Computer Society Staff for This Publication Angela Burgess, Executive Director Anne Marie Kelly, Associate Executive Director, Director of Governance Evan M. Butterfield, Director of Products and Services John Keppler, Senior Manager, Professional Education Kate Guillemette, Product Development Editor Dorian McClenahan, Education Program Product Developer Michelle Phon, Professional Education & Certification Program Coordinator Jennie Zhu-Mai, Editorial Designer

IEEE Computer Society Products and Services. The world-renowned IEEE Computer Society publishes, promotes, and dis- tributes a wide variety of authoritative computer science and engineering journals, magazines, conference proceedings, and professional education products. Visit the Computer Society at www.computer.org for more information. TABLE OF CONTENTS

Foreword xvii Foreword to the 2004 Edition xix Editors xxi Coeditors xxi Contributing Editors xxi Change Control Board xxi Knowledge Area Editors xxiii Knowledge Area Editors of Previous SWEBOK Versions xxv Review Team xxvii Acknowledgements xxix Professional Activities Board, 2013 Membership xxix Motions Regarding the Approval of SWEBOK Guide V3.0 xxx Motions Regarding the Approval of SWEBOK Guide 2004 Version xxx Introduction to the Guide xxxi

Chapter 1: Software Requirements 1-1 1. Software Requirements Fundamentals 1-1 1.1. Definition of a Software Requirement 1-1 1.2. Product and Process Requirements 1-2 1.3. Functional and Nonfunctional Requirements 1-3 1.4. Emergent Properties 1-3 1.5. Quantifiable Requirements 1-3 1.6. System Requirements and Software Requirements 1-3 2. Requirements Process 1-3 2.1. Process Models 1-4 2.2. Process Actors 1-4 2.3. Process Support and Management 1-4 2.4. Process Quality and Improvement 1-4 3. Requirements Elicitation 1-5 3.1. Requirements Sources 1-5 3.2. Elicitation Techniques 1-6 4. Requirements Analysis 1-7 4.1. Requirements Classification 1-7 4.2. Conceptual Modeling 1-8 4.3. Architectural Design and Requirements Allocation 1-9 4.4. Requirements Negotiation 1-9 4.5. Formal Analysis 1-10 5. Requirements Specification 1-10 5.1. System Definition Document 1-10 5.2. System Requirements Specification 1-10 5.3. Software Requirements Specification 1-11 6. Requirements Validation 1-11 6.1. Requirements Reviews 1-11 6.2. Prototyping 1-12

v vi SWEBOK® Guide V3.0

6.3. Model Validation 1-12 6.4. Acceptance Tests 1-12 7. Practical Considerations 1-12 7.1. Iterative Nature of the Requirements Process 1-13 7.2. Change Management 1-13 7.3. Requirements Attributes 1-13 7.4. Requirements Tracing 1-14 7.5. Measuring Requirements 1-14 8. Software Requirements Tools 1-14 Matrix of Topics vs. Reference Material 1-15

Chapter 2: Software Design 2-1 1. Software Design Fundamentals 2-2 1.1. General Design Concepts 2-2 1.2. Context of Software Design 2-2 1.3. Software Design Process 2-2 1.4. Software Design Principles 2-3 2. Key Issues in Software Design 2-3 2.1. Concurrency 2-4 2.2. Control and Handling of Events 2-4 2.3. Data Persistence 2-4 2.4. Distribution of Components 2-4 2.5. Error and Exception Handling and Fault Tolerance 2-4 2.6. Interaction and Presentation 2-4 2.7. Security 2-4 3. Software Structure and Architecture 2-4 3.1. Architectural Structures and Viewpoints 2-5 3.2. Architectural Styles 2-5 3.3. Design Patterns 2-5 3.4. Architecture Design Decisions 2-5 3.5. Families of Programs and Frameworks 2-5 4. User Interface Design 2-5 4.1. General User Interface Design Principles 2-6 4.2. User Interface Design Issues 2-6 4.3. The Design of User Interaction Modalities 2-6 4.4. The Design of Information Presentation 2-6 4.5. User Interface Design Process 2-7 4.6. Localization and Internationalization 2-7 4.7. Metaphors and Conceptual Models 2-7 5. Software Design Quality Analysis and Evaluation 2-7 5.1. Quality Attributes 2-7 5.2. Quality Analysis and Evaluation Techniques 2-8 5.3. Measures 2-8 6. Software Design Notations 2-8 6.1. Structural Descriptions (Static View) 2-8 6.2. Behavioral Descriptions (Dynamic View) 2-9 7. Software Design Strategies and Methods 2-10 7.1. General Strategies 2-10 7.2. Function-Oriented (Structured) Design 2-10 7.3. Object-Oriented Design 2-10 Table of Contents vii

7.4. Data Structure-Centered Design 2-10 7.5. Component-Based Design (CBD) 2-10 7.6. Other Methods 2-10 8. Software Design Tools 2-11 Matrix of Topics vs. Reference Material 2-12

Chapter 3: Software Construction 3-1 1. Software Construction Fundamentals 3-1 1.1. Minimizing Complexity 3-3 1.2. Anticipating Change 3-3 1.3. Constructing for Verification 3-3 1.4. Reuse 3-3 1.5. Standards in Construction 3-3 2. Managing Construction 3-4 2.1. Construction in Life Cycle Models 3-4 2.2. Construction Planning 3-4 2.3. Construction Measurement 3-4 3. Practical Considerations 3-5 3.1. Construction Design 3-5 3.2. Construction Languages 3-5 3.3. Coding 3-6 3.4. Construction Testing 3-6 3.5. Construction for Reuse 3-6 3.6. Construction with Reuse 3-7 3.7. Construction Quality 3-7 3.8. Integration 3-7 4. Construction Technologies 3-8 4.1. API Design and Use 3-8 4.2. Object-Oriented Runtime Issues 3-8 4.3. Parameterization and Generics 3-8 4.4. Assertions, Design by Contract, and Defensive Programming 3-8 4.5. Error Handling, Exception Handling, and Fault Tolerance 3-9 4.6. Executable Models 3-9 4.7. State-Based and Table-Driven Construction Techniques 3-9 4.8. Runtime Configuration and Internationalization 3-10 4.9. Grammar-Based Input Processing 3-10 4.10. Concurrency Primitives 3-10 4.11. Middleware 3-10 4.12. Construction Methods for Distributed Software 3-11 4.13. Constructing Heterogeneous Systems 3-11 4.14. Performance Analysis and Tuning 3-11 4.15. Platform Standards 3-11 4.16. Test-First Programming 3-11 5. Software Construction Tools 3-12 5.1. Development Environments 3-12 5.2. GUI Builders 3-12 5.3. Unit Testing Tools 3-12 5.4. Profiling, Performance Analysis, and Slicing Tools 3-12 Matrix of Topics vs. Reference Material 3-13 viii SWEBOK® Guide V3.0

Chapter 4: Software Testing 4-1 1. Software Testing Fundamentals 4-3 1.1. Testing-Related Terminology 4-3 1.2. Key Issues 4-3 1.3. Relationship of Testing to Other Activities 4-4 2. Test Levels 4-5 2.1. The Target of the Test 4-5 2.2. Objectives of Testing 4-5 3. Test Techniques 4-7 3.1. Based on the Software Engineer’s Intuition and Experience 4-8 3.2. Input Domain-Based Techniques 4-8 3.3. Code-Based Techniques 4-8 3.4. Fault-Based Techniques 4-9 3.5. Usage-Based Techniques 4-9 3.6. Model-Based Testing Techniques 4-10 3.7. Techniques Based on the Nature of the Application 4-10 3.8. Selecting and Combining Techniques 4-11 4. Test-Related Measures 4-11 4.1. Evaluation of the Program Under Test 4-11 4.2. Evaluation of the Tests Performed 4-12 5. Test Process 4-12 5.1. Practical Considerations 4-13 5.2. Test Activities 4-14 6. Software Testing Tools 4-15 6.1. Testing Tool Support 4-15 6.2. Categories of Tools 4-15 Matrix of Topics vs. Reference Material 4-17

Chapter 5: Software Maintenance 5-1 1. Software Maintenance Fundamentals 5-1 1.1. Definitions and Terminology 5-1 1.2. Nature of Maintenance 5-2 1.3. Need for Maintenance 5-3 1.4. Majority of Maintenance Costs 5-3 1.5. Evolution of Software 5-3 1.6. Categories of Maintenance 5-3 2. Key Issues in Software Maintenance 5-4 2.1. Technical Issues 5-4 2.2. Management Issues 5-5 2.3. Maintenance Cost Estimation 5-6 2.4. Software Maintenance Measurement 5-7 3. Maintenance Process 5-7 3.1. Maintenance Processes 5-7 3.2. Maintenance Activities 5-8 4. Techniques for Maintenance 5-10 4.1. Program Comprehension 5-10 4.2. Reengineering 5-10 4.3. Reverse Engineering 5-10 4.4. Migration 5-10 4.5. Retirement 5-11 Table of Contents ix

5. Software Maintenance Tools 5-11 Matrix of Topics vs. Reference Material 5-12

Chapter 6: Software Configuration Management 6-1 1. Management of the SCM Process 6-2 1.1. Organizational Context for SCM 6-2 1.2. Constraints and Guidance for the SCM Process 6-3 1.3. Planning for SCM 6-3 1.4. SCM Plan 6-5 1.5. Surveillance of Software Configuration Management 6-5 2. Software Configuration Identification 6-6 2.1. Identifying Items to Be Controlled 6-6 2.2. Software Library 6-8 3. Software Configuration Control 6-8 3.1. Requesting, Evaluating, and Approving Software Changes 6-8 3.2. Implementing Software Changes 6-9 3.3. Deviations and Waivers 6-10 4. Software Configuration Status Accounting 6-10 4.1. Software Configuration Status Information 6-10 4.2. Software Configuration Status Reporting 6-10 5. Software Configuration Auditing 6-10 5.1. Software Functional Configuration Audit 6-11 5.2. Software Physical Configuration Audit 6-11 5.3. In-Process Audits of a Software Baseline 6-11 6. Software Release Management and Delivery 6-11 6.1. Software Building 6-11 6.2. Software Release Management 6-12 7. Software Configuration Management Tools 6-12 Matrix of Topics vs. Reference Material 6-13

Chapter 7: Software Engineering Management 7-1 1. Initiation and Scope Definition 7-4 1.1. Determination and Negotiation of Requirements 7-4 1.2. Feasibility Analysis 7-4 1.3. Process for the Review and Revision of Requirements 7-5 2. Software Project Planning 7-5 2.1. Process Planning 7-5 2.2. Determine Deliverables 7-5 2.3. Effort, Schedule, and Cost Estimation 7-6 2.4. Resource Allocation 7-6 2.5. Risk Management 7-6 2.6. Quality Management 7-6 2.7. Plan Management 7-7 3. Software Project Enactment 7-7 3.1. Implementation of Plans 7-7 3.2. Software Acquisition and Supplier Contract Management 7-7 3.3. Implementation of Measurement Process 7-7 3.4. Monitor Process 7-7 3.5. Control Process 7-8 3.6. Reporting 7-8 x SWEBOK® Guide V3.0

4. Review and Evaluation 7-8 4.1. Determining Satisfaction of Requirements 7-8 4.2. Reviewing and Evaluating Performance 7-9 5. Closure 7-9 5.1. Determining Closure 7-9 5.2. Closure Activities 7-9 6. Software Engineering Measurement 7-9 6.1. Establish and Sustain Measurement Commitment 7-9 6.2. Plan the Measurement Process 7-10 6.3. Perform the Measurement Process 7-11 6.4. Evaluate Measurement 7-11 7. Software Engineering Management Tools 7-11 Matrix of Topics vs. Reference Material 7-13

Chapter 8: Software Engineering Process 8-1 1. Software Process Definition 8-2 1.1. Software Process Management 8-3 1.2. Software Process Infrastructure 8-4 2. Software Life Cycles 8-4 2.1. Categories of Software Processes 8-5 2.2. Software Life Cycle Models 8-5 2.3. Software Process Adaptation 8-6 2.4. Practical Considerations 8-6 3. Software Process Assessment and Improvement 8-6 3.1. Software Process Assessment Models 8-7 3.2. Software Process Assessment Methods 8-7 3.3. Software Process Improvement Models 8-7 3.4. Continuous and Staged Software Process Ratings 8-8 4. Software Measurement 8-8 4.1. Software Process and Product Measurement 8-9 4.2. Quality of Measurement Results 8-10 4.3. Software Information Models 8-10 4.4. Software Process Measurement Techniques 8-11 5. Software Engineering Process Tools 8-12 Matrix of Topics vs. Reference Material 8-13

Chapter 9: Software Engineering Models and Methods 9-1 1. Modeling 9-1 1.1. Modeling Principles 9-2 1.2. Properties and Expression of Models 9-3 1.3. Syntax, Semantics, and Pragmatics 9-3 1.4. Preconditions, Postconditions, and Invariants 9-4 2. Types of Models 9-4 2.1. Information Modeling 9-5 2.2. Behavioral Modeling 9-5 2.3. Structure Modeling 9-5 3. Analysis of Models 9-5 3.1. Analyzing for Completeness 9-5 3.2. Analyzing for Consistency 9-6 Table of Contents xi

3.3. Analyzing for Correctness 9-6 3.4. Traceability 9-6 3.5. Interaction Analysis 9-6 4. Software Engineering Methods 9-7 4.1. Heuristic Methods 9-7 4.2. Formal Methods 9-7 4.3. Prototyping Methods 9-8 4.4. Agile Methods 9-9 Matrix of Topics vs. Reference Material 9-10

Chapter 10: Software Quality 10-1 1. Software Quality Fundamentals 10-2 1.1. Software Engineering Culture and Ethics 10-2 1.2. Value and Costs of Quality 10-3 1.3. Models and Quality Characteristics 10-3 1.4. Software Quality Improvement 10-4 1.5. Software Safety 10-4 2. Software Quality Management Processes 10-5 2.1. Software Quality Assurance 10-5 2.2. Verification & Validation 10-6 2.3. Reviews and Audits 10-6 3. Practical Considerations 10-9 3.1. Software Quality Requirements 10-9 3.2. Defect Characterization 10-10 3.3. Software Quality Management Techniques 10-11 3.4. Software Quality Measurement 10-12 4. Software Quality Tools 10-12 Matrix of Topics vs. Reference Material 10-14

Chapter 11: Software Engineering Professional Practice 11-1 1. Professionalism 11-2 1.1. Accreditation, Certification, and Licensing 11-3 1.2. Codes of Ethics and Professional Conduct 11-4 1.3. Nature and Role of Professional Societies 11-4 1.4. Nature and Role of Software Engineering Standards 11-4 1.5. Economic Impact of Software 11-5 1.6. Employment Contracts 11-5 1.7. Legal Issues 11-5 1.8. Documentation 11-7 1.9. Tradeoff Analysis 11-8 2. Group Dynamics and Psychology 11-9 2.1. Dynamics of Working in Teams/Groups 11-9 2.2. Individual Cognition 11-9 2.3. Dealing with Problem Complexity 11-10 2.4. Interacting with Stakeholders 11-10 2.5. Dealing with Uncertainty and Ambiguity 11-10 2.6. Dealing with Multicultural Environments 11-10 3. Communication Skills 11-11 3.1. Reading, Understanding, and Summarizing 11-11 xii SWEBOK® Guide V3.0

3.2. Writing 11-11 3.3. Team and Group Communication 11-11 3.4. Presentation Skills 11-12 Matrix of Topics vs. Reference Material 11-13

Chapter 12: Software Engineering Economics 12-1 1. Software Engineering Economics Fundamentals 12-3 1.1. Finance 12-3 1.2. Accounting 12-3 1.3. Controlling 12-3 1.4. Cash Flow 12-3 1.5. Decision-Making Process 12-4 1.6. Valuation 12-5 1.7. Inflation 12-6 1.8. Depreciation 12-6 1.9. Taxation 12-6 1.10. Time-Value of Money 12-6 1.11. Efficiency 12-6 1.12. Effectiveness 12-6 1.13. Productivity 12-6 2. Life Cycle Economics 12-7 2.1. Product 12-7 2.2. Project 12-7 2.3. Program 12-7 2.4. Portfolio 12-7 2.5. Product Life Cycle 12-7 2.6. Project Life Cycle 12-7 2.7. Proposals 12-8 2.8. Investment Decisions 12-8 2.9. Planning Horizon 12-8 2.10. Price and Pricing 12-8 2.11. Cost and Costing 12-9 2.12. Performance Measurement 12-9 2.13. Earned Value Management 12-9 2.14. Termination Decisions 12-9 2.15. Replacement and Retirement Decisions 12-10 3. Risk and Uncertainty 12-10 3.1. Goals, Estimates, and Plans 12-10 3.2. Estimation Techniques 12-11 3.3. Addressing Uncertainty 12-11 3.4. Prioritization 12-11 3.5. Decisions under Risk 12-11 3.6. Decisions under Uncertainty 12-12 4. Economic Analysis Methods 12-12 4.1. For-Profit Decision Analysis 12-12 4.2. Minimum Acceptable Rate of Return 12-13 4.3. Return on Investment 12-13 4.4. Return on Capital Employed 12-13 4.5. Cost-Benefit Analysis 12-13 Table of Contents xiii

4.6. Cost-Effectiveness Analysis 12-13 4.7. Break-Even Analysis 12-13 4.8. Business Case 12-13 4.9. Multiple Attribute Evaluation 12-14 4.10. Optimization Analysis 12-14 5. Practical Considerations 12-14 5.1. The “Good Enough” Principle 12-14 5.2. Friction-Free Economy 12-15 5.3. Ecosystems 12-15 5.4. Offshoring and Outsourcing 12-15 Matrix of Topics vs. Reference Material 12-16

Chapter 13: Computing Foundations 13-1 1. Problem Solving Techniques 13-3 1.1. Definition of Problem Solving 13-3 1.2. Formulating the Real Problem 13-3 1.3. Analyze the Problem 13-3 1.4. Design a Solution Search Strategy 13-3 1.5. Problem Solving Using Programs 13-3 2. Abstraction 13-4 2.1. Levels of Abstraction 13-4 2.2. Encapsulation 13-4 2.3. Hierarchy 13-4 2.4. Alternate Abstractions 13-5 3. Programming Fundamentals 13-5 3.1. The Programming Process 13-5 3.2. Programming Paradigms 13-5 4. Programming Language Basics 13-6 4.1. Programming Language Overview 13-6 4.2. Syntax and Semantics of Programming Languages 13-6 4.3. Low-Level Programming Languages 13-7 4.4. High-Level Programming Languages 13-7 4.5. Declarative vs. Imperative Programming Languages 13-7 5. Debugging Tools and Techniques 13-8 5.1. Types of Errors 13-8 5.2. Debugging Techniques 13-8 5.3. Debugging Tools 13-8 6. Data Structure and Representation 13-9 6.1. Data Structure Overview 13-9 6.2. Types of Data Structure 13-9 6.3. Operations on Data Structures 13-9 7. Algorithms and Complexity 13-10 7.1. Overview of Algorithms 13-10 7.2. Attributes of Algorithms 13-10 7.3. Algorithmic Analysis 13-10 7.4. Algorithmic Design Strategies 13-11 7.5. Algorithmic Analysis Strategies 13-11 8. Basic Concept of a System 13-11 8.1. Emergent System Properties 13-11 xiv SWEBOK® Guide V3.0

8.2. Systems Engineering 13-12 8.3. Overview of a Computer System 13-12 9. Computer Organization 13-13 9.1. Computer Organization Overview 13-13 9.2. Digital Systems 13-13 9.3. Digital Logic 13-13 9.4. Computer Expression of Data 13-13 9.5. The Central Processing Unit (CPU) 13-14 9.6. Memory System Organization 13-14 9.7. Input and Output (I/O) 13-14 10. Compiler Basics 13-15 10.1. Compiler/Interpreter Overview 13-15 10.2. Interpretation and Compilation 13-15 10.3. The Compilation Process 13-15 11. Operating Systems Basics 13-16 11.1. Operating Systems Overview 13-16 11.2. Tasks of an Operating System 13-16 11.3. Operating System Abstractions 13-17 11.4. Operating Systems Classification 13-17 12. Database Basics and Data Management 13-17 12.1. Entity and Schema 13-18 12.2. Database Management Systems (DBMS) 13-18 12.3. Database Query Language 13-18 12.4. Tasks of DBMS Packages 13-18 12.5. Data Management 13-19 12.6. Data Mining 13-19 13. Network Communication Basics 13-19 13.1. Types of Network 13-19 13.2. Basic Network Components 13-19 13.3. Networking Protocols and Standards 13-20 13.4. The Internet 13-20 13.5. Internet of Things 13-20 13.6. Virtual Private Network (VPN) 13-21 14. Parallel and Distributed Computing 13-21 14.1. Parallel and Distributed Computing Overview 13-21 14.2. Difference between Parallel and Distributed Computing 13-21 14.3. Parallel and Distributed Computing Models 13-21 14.4. Main Issues in Distributed Computing 13-22 15. Basic User Human Factors 13-22 15.1. Input and Output 13-22 15.2. Error Messages 13-23 15.3. Software Robustness 13-23 16. Basic Developer Human Factors 13-23 16.1. Structure 13-24 16.2. Comments 13-24 17. Secure Software Development and Maintenance 13-24 17.1. Software Requirements Security 13-24 17.2. Software Design Security 13-25 17.3. Software Construction Security 13-25 17.4. Software Testing Security 13-25 Table of Contents xv

17.5. Build Security into Software Engineering Process 13-25 17.6. Software Security Guidelines 13-25 Matrix of Topics vs. Reference Material 13-27

Chapter 14: Mathematical Foundations 14-1 1. Set, Relations, Functions 14-1 1.1. Set Operations 14-2 1.2. Properties of Set 14-3 1.3. Relation and Function 14-4 2. Basic Logic 14-5 2.1. Propositional Logic 14-5 2.2. Predicate Logic 14-5 3. Proof Techniques 14-6 3.1. Methods of Proving Theorems 14-6 4. Basics of Counting 14-7 5. Graphs and Trees 14-8 5.1. Graphs 14-8 5.2. Trees 14-10 6. Discrete Probability 14-13 7. Finite State Machines 14-14 8. Grammars 14-15 8.1. Language Recognition 14-16 9. Numerical Precision, Accuracy, and Errors 14-17 10. Number Theory 14-18 10.1. Divisibility 14-18 10.2. Prime Number, GCD 14-19 11. Algebraic Structures 14-19 11.1. Group 14-19 11.2. Rings 14-20 Matrix of Topics vs. Reference Material 14-21

Chapter 15: Engineering Foundations 15-1 1. Empirical Methods and Experimental Techniques 15-1 1.1. Designed Experiment 15-1 1.2. Observational Study 15-2 1.3. Retrospective Study 15-2 2. Statistical Analysis 15-2 2.1. Unit of Analysis (Sampling Units), Population, and Sample 15-2 2.2. Concepts of Correlation and Regression 15-5 3. Measurement 15-5 3.1. Levels (Scales) of Measurement 15-6 3.2. Direct and Derived Measures 15-7 3.3. Reliability and Validity 15-8 3.4. Assessing Reliability 15-8 4. Engineering Design 15-8 4.1. Engineering Design in Engineering Education 15-8 4.2. Design as a Problem Solving Activity 15-9 4.3. Steps Involved in Engineering Design 15-9 5. Modeling, Simulation, and Prototyping 15-10 5.1. Modeling 15-10 xvi SWEBOK® Guide V3.0

5.2. Simulation 15-11 5.3. Prototyping 15-11 6. Standards 15-12 7. Root Cause Analysis 15-12 7.1. Techniques for Conducting Root Cause Analysis 15-13 Matrix of Topics vs. Reference Material 15-14

Appendix A: Knowledge Area Description Specifications A-1

Appendix B: IEEE and ISO/IEC Standards Supporting the Software Engineering Body of Knowledge (SWEBOK) B-1

Appendix C: Consolidated Reference List C-1 FOREWORD

Every profession is based on a body of knowl- In 1958, John Tukey, the world-renowned stat- edge, although that knowledge is not always istician, coined the term software. The term soft- defined in a concise manner. In cases where no ware engineering was used in the title of a NATO formality exists, the body of knowledge is “gen- conference held in Germany in 1968. The IEEE erally recognized” by practitioners and may Computer Society first published itsTransactions be codified in a variety of ways for a variety of on Software Engineering in 1972, and a commit- different uses. But in many cases, a guide to a tee for developing software engineering stan- body of knowledge is formally documented, usu- dards was established within the IEEE Computer ally in a form that permits it to be used for such Society in 1976. purposes as development and accreditation of In 1990, planning was begun for an interna- academic and training programs, certification of tional standard to provide an overall view of soft- specialists, or professional licensing. Generally, ware engineering. The standard was completed in a professional society or similar body maintains 1995 with designation ISO/IEC 12207 and given stewardship of the formal definition of a body of the title of Standard for Software Life Cycle Pro- knowledge. cesses. The IEEE version of 12207 was published During the past forty-five years, software engi- in 1996 and provided a major foundation for the neering has evolved from a conference catch- body of knowledge captured in SWEBOK 2004. phrase into an engineering profession, character- The current version of 12207 is designated as ized by 1) a professional society, 2) standards that ISO/IEC 12207:2008 and IEEE 12207-2008; it specify generally accepted professional practices, provides the basis for this SWEBOK V3. 3) a code of ethics, 4) conference proceedings, This Guide to the Software Engineering Body 5) textbooks, 6) curriculum guidelines and cur- of Knowledge is presented to you, the reader, as ricula, 7) accreditation criteria and accredited a mechanism for acquiring the knowledge you degree programs, 8) certification and licensing, need in your lifelong career development as a and 9) this Guide to the Body of Knowledge. software engineering professional. In this Guide to the Software Engineering Body of Knowledge, the IEEE Computer Society presents a revised and updated version of the body of Dick Fairley, Chair knowledge formerly documented as SWEBOK Software and Systems Engineering Committee 2004; this revised and updated version is denoted IEEE Computer Society SWEBOK V3. This work is in partial fulfillment of the Society’s responsibility to promote the advancement of both theory and practice for the Don Shafer, Vice President profession of software engineering. Professional Activities Board It should be noted that this Guide does not IEEE Computer Society present the entire the body of knowledge for software engineering but rather serves as a guide to the body of knowledge that has been developed over more than four decades. The software engineering body of knowledge is constantly evolving. Nevertheless, this Guide constitutes a valuable characterization of the software engineering profession.

xvii FOREWORD TO THE 2004 EDITION

In this Guide, the IEEE Computer Society estab- standards. These workshops involved practitio- lishes for the first time a baseline for the body ners sharing their experiences with existing stan- of knowledge for the field of software engineer- dards. The workshops also held sessions on plan- ing, and the work partially fulfills the Society’s ning for future standards, including one involving responsibility to promote the advancement of measures and metrics for software engineer- both theory and practice in this field. In so doing, ing products and processes. The planning also the Society has been guided by the experience resulted in IEEE Std. 1002, Taxonomy of Software of disciplines with longer histories but was not Engineering Standards (1986), which provided a bound either by their problems or their solutions. new, holistic view of software engineering. The It should be noted that the Guide does not pur- standard describes the form and content of a soft- port to define the body of knowledge but rather to ware engineering standards taxonomy. It explains serve as a compendium and guide to the body of the various types of software engineering stan- knowledge that has been developing and evolv- dards, their functional and external relationships, ing over the past four decades. Furthermore, and the role of various functions participating in this body of knowledge is not static. The Guide the software life cycle. must, necessarily, develop and evolve as software In 1990, planning for an international stan- engineering matures. It nevertheless constitutes dard with an overall view was begun. The plan- a valuable element of the software engineering ning focused on reconciling the software process infrastructure. views from IEEE Std. 1074 and the revised US In 1958, John Tukey, the world-renowned stat- DoD standard 2167A. The revision was eventu- istician, coined the term software. The term soft- ally published as DoD Std. 498. The international ware engineering was used in the title of a NATO standard was completed in 1995 with designa- conference held in Germany in 1968. The IEEE tion, ISO/IEC 12207, and given the title of Stan- Computer Society first published itsTransactions dard for Software Life Cycle Processes. Std. ISO/ on Software Engineering in 1972. The committee IEC 12207 provided a major point of departure established within the IEEE Computer Society for the body of knowledge captured in this book. for developing software engineering standards It was the IEEE Computer Society Board of was founded in 1976. Governors’ approval of the motion put forward The first holistic view of software engineer- in May 1993 by Fletcher Buckley which resulted ing to emerge from the IEEE Computer Society in the writing of this book. The Association for resulted from an effort led by Fletcher Buckley Computing Machinery (ACM) Council approved to develop IEEE standard 730 for software qual- a related motion in August 1993. The two motions ity assurance, which was completed in 1979. led to a joint committee under the leadership of The purpose of IEEE Std. 730 was to provide Mario Barbacci and Stuart Zweben who served as uniform, minimum acceptable requirements for cochairs. The mission statement of the joint com- preparation and content of software quality assur- mittee was “To establish the appropriate sets(s) ance plans. This standard was influential in com- of criteria and norms for professional practice of pleting the developing standards in the following software engineering upon which industrial deci- topics: configuration management, software test- sions, professional certification, and educational ing, software requirements, software design, and curricula can be based.” The steering committee software verification and validation. organized task forces in the following areas: During the period 1981–1985, the IEEE Com- puter Society held a series of workshops con- 1. Define Required Body of Knowledge and cerning the application of software engineering Recommended Practices.

xix xx SWEBOK® Guide V3.0

2. Define Ethics and Professional Standards. It is hoped that readers will find this book use- 3. Define Educational Curricula for undergradu- ful in guiding them toward the knowledge and ate, graduate, and continuing education. resources they need in their lifelong career development as software engineering professionals. This book supplies the first component: required The book is dedicated to Fletcher Buckley in body of knowledge and recommend practices. recognition of his commitment to promoting soft- The code of ethics and professional practice ware engineering as a professional discipline and for software engineering was completed in 1998 his excellence as a software engineering practi- and approved by both the ACM Council and the tioner in radar applications. IEEE Computer Society Board of Governors. It has been adopted by numerous corporations and other organizations and is included in several Leonard L. Tripp, IEEE Fellow 2003 recent textbooks. Chair, Professional Practices Committee, IEEE The educational curriculum for undergraduates Computer Society (2001–2003) is being completed by a joint effort of the IEEE Computer Society and the ACM and is expected Chair, Joint IEEE Computer Society and ACM to be completed in 2004. Steering Committee for the Establishment of Every profession is based on a body of knowl- Software Engineering as a Profession (1998–1999) edge and recommended practices, although they are not always defined in a precise manner. In Chair, Software Engineering Standards Committee, many cases, these are formally documented, usu- IEEE Computer Society (1992–1998) ally in a form that permits them to be used for such purposes as accreditation of academic programs, development of education and training programs, certification of specialists, or professional licensing. Generally, a professional society or related body maintains custody of such a formal definition. In cases where no such formality exists, the body of knowledge and recommended practices are “generally recognized” by practitioners and may be codified in a variety of ways for different uses. EDITORS

Pierre Bourque, Department of Software and IT Engineering, École de technologie supérieure (ÉTS), Canada, [email protected] Richard E. (Dick) Fairley, Software and Systems Engineering Associates (S2EA), USA, [email protected]

COEDITORS

Alain Abran, Department of Software and IT Engineering, École de technologie supérieure (ÉTS), Canada, [email protected] Juan Garbajosa, Universidad Politecnica de Madrid (Technical University of Madrid, UPM), Spain, [email protected] Gargi Keeni, Tata Consultancy Services, India, [email protected] Beijun Shen, School of Software, Shanghai Jiao Tong University, China, [email protected]

CONTRIBUTING EDITORS

The following persons contributed to editing the SWEBOK Guide V3: Don Shafer Linda Shafer Mary Jane Willshire Kate Guillemette

CHANGE CONTROL BOARD

The following persons served on the SWEBOK Guide V3 Change Control Board: Pierre Bourque Richard E. (Dick) Fairley, Chair Dennis Frailey Michael Gayle Thomas Hilburn Paul Joannou James W. Moore Don Shafer Steve Tockey

xxi KNOWLEDGE AREA EDITORS

Software Requirements Gerald Kotonya, School of Computing and Communications, Lancaster University, UK, [email protected] Peter Sawyer, School of Computing and Communications, Lancaster University, UK, [email protected]

Software Design Yanchun Sun, School of Electronics Engineering and Computer Science, Peking University, China, [email protected]

Software Construction Xin Peng, Software School, Fudan University, China, [email protected]

Software Testing Antonia Bertolino, ISTI-CNR, Italy, [email protected] Eda Marchetti, ISTI-CNR, Italy, [email protected]

Software Maintenance Alain April, École de technologie supérieure (ÉTS), Canada, [email protected] Mira Kajko-Mattsson, School of Information and Communication Technology, KTH Royal Institute of Technology, [email protected]

Software Configuration Management Roger Champagne, École de technologie supérieure (ÉTS), Canada, [email protected] Alain April, École de technologie supérieure (ÉTS), Canada, [email protected]

Software Engineering Management James McDonald, Department of Computer Science and Software Engineering, Monmouth University, USA, [email protected]

Software Engineering Process Annette Reilly, Lockheed Martin Information Systems & Global Solutions, USA, [email protected] Richard E. Fairley, Software and Systems Engineering Associates (S2EA), USA, [email protected]

Software Engineering Models and Methods Michael F. Siok, Lockheed Martin Aeronautics Company, USA, [email protected]

Software Quality J. David Blaine, USA, [email protected] Durba Biswas, Tata Consultancy Services, India, [email protected]

xxiii xxiv SWEBOK® Guide V3.0

Software Engineering Professional Practice Aura Sheffield, USA, [email protected] Hengming Zou, Shanghai Jiao Tong University, China, [email protected]

Software Engineering Economics Christof Ebert, Vector Consulting Services, Germany, [email protected]

Computing Foundations Hengming Zou, Shanghai Jiao Tong University, China, [email protected]

Mathematical Foundations Nabendu Chaki, University of Calcutta, India, [email protected]

Engineering Foundations Amitava Bandyopadhayay, Indian Statistical Institute, India, [email protected] Mary Jane Willshire, Software and Systems Engineering Associates (S2EA), USA, [email protected]

Appendix B: IEEE and ISO/IEC Standards Supporting SWEBOK James W. Moore, USA, [email protected] KNOWLEDGE AREA EDITORS OF PREVIOUS SWEBOK VERSIONS

The following persons served as Associate Editors for either the Trial version published in 2001 or for the 2004 version.

Software Requirements Peter Sawyer, Computing Department, Lancaster University, UK Gerald Kotonya, Computing Department, Lancaster University, UK

Software Design Guy Tremblay, Département d’informatique, UQAM, Canada

Software Construction Steve McConnell, Construx Software, USA Terry Bollinger, the MITRE Corporation, USA Philippe Gabrini, Département d’informatique, UQAM, Canada Louis Martin, Département d’informatique, UQAM, Canada

Software Testing Antonia Bertolino, ISTI-CNR, Italy Eda Marchetti, ISTI-CNR, Italy

Software Maintenance Thomas M. Pigoski, Techsoft Inc., USA Alain April, École de technologie supérieure, Canada

Software Configuration Management John A. Scott, Lawrence Livermore National Laboratory, USA David Nisse, USA

Software Engineering Management Dennis Frailey, Raytheon Company, USA Stephen G. MacDonell, Auckland University of Technology, New Zealand Andrew R. Gray, University of Otago, New Zealand

Software Engineering Process Khaled El Emam, served while at the Canadian National Research Council, Canada

Software Engineering Tools and Methods David Carrington, School of Information Technology and Electrical Engineering, The University of Queensland, Australia

xxv xxvi SWEBOK® Guide V3.0

Software Quality Alain April, École de technologie supérieure, Canada Dolores Wallace, retired from the National Institute of Standards and Technology, USA Larry Reeker, NIST, USA

References Editor Marc Bouisset, Département d’informatique, UQAM REVIEW TEAM

The people listed below participated in the public review process of SWEBOK Guide V3. Member- ship of the IEEE Computer Society was not a requirement to participate in this review process, and membership information was not requested from reviewers. Over 1500 individual comments were collected and duly adjudicated.

Carlos C. Amaro, USA Istvan Fay, Hungary Mark Ardis, USA Jose L. Fernandez-Sanchez, Spain Mora-Soto Arturo, Spain Dennis J. Frailey, USA Ohad Barzilay, Israel Tihana Galinac Grbac, Croatia Gianni Basaglia, Italy Colin Garlick, New Zealand Denis J. Bergquist, USA Garth J.G. Glynn, UK Alexander Bogush, UK Jill Gostin, USA Christopher Bohn, USA Christiane Gresse von Wangenheim, Brazil Steve Bollweg, USA Thomas Gust, USA Reto Bonderer, Switzerland H.N. Mok, Singapore Alexei Botchkarev, Canada Jon D. Hagar, USA Pieter Botman, Canada Anees Ahmed Haidary, India Robert Bragner, USA Duncan Hall, New Zealand Kevin Brune, USA James Hart, USA Ogihara Bryan, USA Jens H.J. Heidrich, Germany Luigi Buglione, Italy Rich Hilliard, USA Rick Cagle, USA Bob Hillier, Canada Barbara Canody, USA Norman M. Hines, USA Rogerio A. Carvalho, Brazil Dave Hirst, USA Daniel Cerys, USA Theresa L. Hunt, USA Philippe Cohard, France Kenneth Ingham, USA Ricardo Colomo-Palacios, Spain Masahiko Ishikawa, Japan Mauricio Coria, Argentina Michael A. Jablonski, USA Marek Cruz, UK G. Jagadeesh, India Stephen Danckert, USA Sebastian Justicia, Spain Bipul K. Das, Canada Umut Kahramankaptan, Belgium James D. Davidson, USA Pankaj Kamthan, Canada Jon Dehn, USA Perry Kapadia, USA Lincoln P. Djang, USA Tarig A. Khalid, Sudan Andreas Doblander, Austria Michael K.A. Klaes, Germany Yi-Ben Doo, USA Maged Koshty, Egypt Scott J. Dougherty, UK Claude C. Laporte, Canada Regina DuBord, USA Dong Li, China Fedor Dzerzhinskiy, Russia Ben Linders, Netherlands Ann M. Eblen, Australia Claire Lohr, USA David M. Endres, USA Vladimir Mandic, Serbia Marilyn Escue, USA Matt Mansell, New Zealand Varuna Eswer, India John Marien, USA

xxvii xxviii SWEBOK® Guide V3.0

Stephen P. Masticola, USA Thom Schoeffling, USA Nancy Mead, USA Reinhard Schrage, Germany Fuensanta Medina-Dominguez, Spain Neetu Sethia, India Silvia Judith Meles, Argentina Cindy C. Shelton, USA Oscar A. Mondragon, Mexico Alan Shepherd, Germany David W. Mutschler, USA Katsutoshi Shintani, Japan Maria Nelson, Brazil Erik Shreve, USA John Noblin, USA Jaguaraci Silva, Brazil Bryan G. Ogihara, USA M. Somasundaram, India Takehisa Okazaki, Japan Peraphon Sophatsathit, Thailand Hanna Oktaba, Mexico John Standen, UK Chin Hwee Ong, Hong Kong Joyce Statz, USA Venkateswar Oruganti, India Perdita P. Stevens, UK Birgit Penzenstadler, Germany David Struble, USA Larry Peters, USA Ohno Susumu, Japan S.K. Pillai, India Urcun Tanik, USA Vaclav Rajlich, USA Talin Tasciyan, USA Kiron Rao, India J. Barrie Thompson, UK Luis Reyes, USA Steve Tockey, USA Hassan Reza, USA Miguel Eduardo Torres Moreno, Colombia Steve Roach, USA Dawid Trawczynski, USA Teresa L. Roberts, USA Adam Trendowicz, Germany Dennis Robi, USA Norio Ueno, Japan Warren E. Robinson, USA Cenk Uyan, Turkey Jorge L. Rodriguez, USA Chandra Sekar Veerappan, Singapore Alberto C. Sampaio, Portugal Oruganti Venkateswar, India Ed Samuels, USA Jochen Vogt, Germany Maria-Isabel Sanchez-Segura, Spain Hironori Washizaki, Japan Vineet Sawant, USA Ulf Westermann, Germany R. Schaaf, USA Don Wilson, USA James C. Schatzman, USA Aharon Yadin, Israel Oscar A. Schivo, Argentina Hong Zhou, UK Florian Schneider, Germany ACKNOWLEDGEMENTS

Funding for the development of SWEBOK Guide various ways: Pieter Botman, Evan Butterfield, V3 has been provided by the IEEE Computer Carine Chauny, Pierce Gibbs, Diane Girard, John Society. The editors and coeditors appreciate the Keppler, Dorian McClenahan, Kenza Meridji, Sam- important work performed by the KA editors and uel Redwine, Annette Reilly, and Pam Thompson. the contributing editors as well as by the the mem- Finally, there are surely other people who have bers of the Change Control Board. The editorial contributed to this Guide, either directly or indi- team must also acknowledge the indispensable rectly, whose names we have inadvertently omit- contribution of reviewers. ted. To those people, we offer our tacit appre- The editorial team also wishes to thank the fol- ciation and apologize for having omitted explicit lowing people who contributed to the project in recognition.

IEEE COMPUTER SOCIETY PRESIDENTS

Dejan Milojicic, 2014 President David Alan Grier, 2013 President Thomas Conte, 2015 President

PROFESSIONAL ACTIVITIES BOARD, 2013 MEMBERSHIP

Donald F. Shafer, Chair Pieter Botman, CSDP Pierre Bourque Richard Fairley, CSDP Dennis Frailey S. Michael Gayle Phillip Laplante, CSDP Jim Moore, CSDP Linda Shafer, CSDP Steve Tockey, CSDP Charlene “Chuck” Walrad

xxix xxx SWEBOK® Guide V3.0

MOTIONS REGARDING THE APPROVAL OF SWEBOK GUIDE V3.0

The SWEBOK Guide V3.0 was submitted to ballot by verified IEEE Computer Society members in November 2013 with the following question: “Do you approve this manuscript of the SWEBOK Guide V3.0 to move forward to formatting and publication?” The results of this ballot were 259 Yes votes and 5 No votes.

The following motion was unanimously adopted by the Professional Activities Board of the IEEE Com- puter Society in December 2013:

The Professional Activities Board of the IEEE Computer Society finds that the Guide to the Soft- ware Engineering Body of Knowledge Version 3.0 has been successfully completed; and endorses the Guide to the Software Engineering Body of Knowledge Version 3.0 and commends it to the IEEE Computer Society Board of Governors for their approval.

The following motion was adopted by the IEEE Computer Society Board of Governors in December 2013:

MOVED, that the Board of Governors of the IEEE Computer Society approves Version 3.0 of the Guide to the Software Engineering Body of Knowledge and authorizes the Chair of the Profes- sional Activities Board to proceed with printing.

MOTIONS REGARDING THE APPROVAL OF SWEBOK GUIDE 2004 VERSION

The following motion was unanimously adopted by the Industrial Advisory Board of the SWEBOK Guide project in February 2004:

The Industrial Advisory Board finds that the Software Engineering Body of Knowledge project initiated in 1998 has been successfully completed; and endorses the 2004 Version of the Guide to the SWEBOK and commends it to the IEEE Computer Society Board of Governors for their approval.

The following motion was adopted by the IEEE Computer Society Board of Governors in February 2004:

MOVED, that the Board of Governors of the IEEE Computer Society approves the 2004 Edition of the Guide to the Software Engineering Body of Knowledge and authorizes the Chair of the Profes- sional Practices Committee to proceed with printing.

Please also note that the 2004 edition of the Guide to the Software Engineering Body of Knowledge was submitted by the IEEE Computer Society to ISO/IEC without any change and was recognized as Technical Report ISO/IEC TR 19759:2005. INTRODUCTION TO THE GUIDE

KA Knowledge Area literature. The purpose of the Guide is to describe Software Engineering Body of SWEBOK the portion of the Body of Knowledge that is gen- Knowledge erally accepted, to organize that portion, and to provide topical access to it. Publication of the 2004 version of this Guide to the The Guide to the Software Engineering Body Software Engineering Body of Knowledge (SWE- of Knowledge (SWEBOK Guide) was established BOK 2004) was a major milestone in establishing with the following five objectives: software engineering as a recognized engineering discipline. The goal in developing this update to 1. To promote a consistent view of software SWEBOK is to improve the currency, readability, engineering worldwide consistency, and usability of the Guide. 2. To specify the scope of, and clarify the place All knowledge areas (KAs) have been updated of software engineering with respect to other to reflect changes in software engineering since disciplines such as computer science, proj- publication of SWEBOK 2004. Four new foun- ect management, computer engineering, and dation KAs and a Software Engineering Profes- mathematics sional Practices KA have been added. The Soft- 3. To characterize the contents of the software ware Engineering Tools and Methods KA has engineering discipline been revised as Software Engineering Models 4. To provide a topical access to the Software and Methods. Software engineering tools is now Engineering Body of Knowledge a topic in each of the KAs. Three appendices pro- 5. To provide a foundation for curriculum vide the specifications for the KA description, an development and for individual certification annotated set of relevant standards for each KA, and licensing material and a listing of the references cited in the Guide. This Guide, written under the auspices of the The first of these objectives, a consistent world- Professional Activities Board of the IEEE Com- wide view of software engineering, was supported puter Society, represents a next step in the evolu- by a development process which engaged approxi- tion of the software engineering profession. mately 150 reviewers from 33 countries. More information regarding the development process can WHAT IS SOFTWARE ENGINEERING? be found on the website (www.swebok.org). Pro- fessional and learned societies and public agencies ISO/IEC/IEEE Systems and Software Engineering involved in software engineering were contacted, Vocabulary (SEVOCAB) defines software engi- made aware of this project to update SWEBOK, and neering as “the application of a systematic, disci- invited to participate in the review process. KA edi- plined, quantifiable approach to the development, tors were recruited from North America, the Pacific operation, and maintenance of software; that is, the Rim, and Europe. Presentations on the project were application of engineering to software).”1 made at various international venues. The second of the objectives, the desire to WHAT ARE THE OBJECTIVES OF THE specify the scope of software engineering, moti- SWEBOK GUIDE? vates the fundamental organization of the Guide. The material that is recognized as being within The Guide should not be confused with the Body this discipline is organized into the fifteen KAs of Knowledge itself, which exists in the published listed in Table I.1. Each of these KAs is treated in a chapter in this Guide. 1 See www.computer.org/sevocab.

xxxi xxxii SWEBOK® Guide V3.0

Table I.1. The 15 SWEBOK KAs HIERARCHICAL ORGANIZATION Software Requirements Software Design The organization of the KA chapters supports the third of the project’s objectives—a characteriza- Software Construction tion of the contents of software engineering. The Software Testing detailed specifications provided by the project’s Software Maintenance editorial team to the associate editors regarding Software Configuration Management the contents of the KA descriptions can be found in Appendix A. Software Engineering Management The Guide uses a hierarchical organization to Software Engineering Process decompose each KA into a set of topics with rec- Software Engineering Models and Methods ognizable labels. A two (sometime three) level Software Quality breakdown provides a reasonable way to find topics of interest. The Guide treats the selected Software Engineering Professional Practice topics in a manner compatible with major schools Software Engineering Economics of thought and with breakdowns generally found Computing Foundations in industry and in software engineering literature Mathematical Foundations and standards. The breakdowns of topics do not presume particular application domains, business Engineering Foundations uses, management philosophies, development methods, and so forth. The extent of each topic’s In specifying scope, it is also important to iden- description is only that needed to understand the tify the disciplines that intersect with software generally accepted nature of the topics and for engineering. To this end, SWEBOK V3 also rec- the reader to successfully find reference material; ognizes seven related disciplines, listed in Table the Body of Knowledge is found in the reference I.2. Software engineers should, of course, have materials themselves, not in the Guide. knowledge of material from these disciplines (and the KA descriptions in this Guide may make REFERENCE MATERIAL AND MATRIX reference to them). It is not, however, an objective of the SWEBOK Guide to characterize the To provide topical access to the knowledge—the knowledge of the related disciplines. fourth of the project’s objectives—the Guide identifies authoritative reference material for Table I.2. Related Disciplines each KA. Appendix C provides a Consolidated Computer Engineering Reference List for the Guide. Each KA includes relevant references from the Consolidated Refer- Computer Science ence List and also includes a matrix relating the General Management reference material to the included topics. Mathematics It should be noted that the Guide does not Project Management attempt to be comprehensive in its citations. Much material that is both suitable and excellent Quality Management is not referenced. Material included in the Con- Systems Engineering solidated Reference List provides coverage of the topics described. The relevant elements of computer science and mathematics are presented in the Computing DEPTH OF TREATMENT Foundations and Mathematical Foundations KAs of the Guide (Chapters 13 and 14). To achieve the SWEBOK fifth objective—providing a foundation for curriculum development, Introduction xxxiii

certification, and licensing, the criterion of gen- The breakdown of topics in each KA consti- erally accepted knowledge has been applied, to tutes the core the KA description, describing be distinguished from advanced and research the decomposition of the KA into subareas, top- knowledge (on the grounds of maturity) and from ics, and sub-topics. For each topic or subtopic, a specialized knowledge (on the grounds of gener- short description is given, along with one or more ality of application). references. The equivalent term generally recognized The reference material was chosen because it is comes from the Project Management Institute: considered to constitute the best presentation of “Generally recognized means the knowledge the knowledge relative to the topic. A matrix links and practices described are applicable to most the topics to the reference material. projects most of the time, and there is consensus The last part of each KA description is the list about their value and usefulness.”2 of recommended references and (optionally) fur- However, the terms “generally accepted” or ther readings. Relevant standards for each KA are “generally recognized” do not imply that the des- presented in Appendix B of the Guide. ignated knowledge should be uniformly applied to all software engineering endeavors—each proj- APPENDIX A. KA DESCRIPTION ect’s needs determine that—but it does imply that SPECIFICATIONS competent, capable software engineers should be equipped with this knowledge for potential Appendix A describes the specifications provided application. More precisely, generally accepted by the editorial team to the associate editors for knowledge should be included in the study mate- the content, recommended references, format, rial for the software engineering licensing exami- and style of the KA descriptions. nation that graduates would take after gaining four years of work experience. Although this cri- APPENDIX B. ALLOCATION OF STAN- terion is specific to the US style of education and DARDS TO KAS does not necessarily apply to other countries, we deem it useful. Appendix B is an annotated list of the relevant standards, mostly from the IEEE and the ISO, for STRUCTURE OF THE KA DESCRIPTIONS each of the KAs of the SWEBOK Guide.

The KA descriptions are structured as follows. APPENDIX C. CONSOLIDATED In the introduction, a brief definition of the KA REFERENCE LIST and an overview of its scope and of its relationship with other KAs are presented. Appendix C contains the consolidated list of recommended references cited in the KAs (these 2 A Guide to the Project Management Body of references are marked with an asterisk (*) in the Knowledge, 5th ed., Project Management Institute, text). 2013; www.pmi.org. CHAPTER 1

SOFTWARE REQUIREMENTS

ACRONYMS does not imply, however, that a software engineer could not perform the function. Confidentiality, Integrity, and CIA A risk inherent in the proposed breakdown is Availability that a waterfall-like process may be inferred. To DAG Directed Acyclic Graph guard against this, topic 2, Requirements Process, FSM Functional Size Measurement is designed to provide a high-level overview of the International Council on Systems requirements process by setting out the resources INCOSE Engineering and constraints under which the process operates and which act to configure it. UML Unified Modeling Language An alternate decomposition could use a prod- SysML Systems Modeling Language uct-based structure (system requirements, software requirements, prototypes, use cases, and so on). The process-based breakdown reflects INTRODUCTION the fact that the requirements process, if it is to be successful, must be considered as a process The Software Requirements knowledge area (KA) involving complex, tightly coupled activities is concerned with the elicitation, analysis, speci- (both sequential and concurrent), rather than as a fication, and validation of software requirements discrete, one-off activity performed at the outset as well as the management of requirements dur- of a software development project. ing the whole life cycle of the software product. The Software Requirements KA is related It is widely acknowledged amongst researchers closely to the Software Design, Software Testing, and industry practitioners that software projects Software Maintenance, Software Configuration are critically vulnerable when the requirements- Management, Software Engineering Manage- related activities are poorly performed. ment, Software Engineering Process, Software Software requirements express the needs and Engineering Models and Methods, and Software constraints placed on a software product that Quality KAs. contribute to the solution of some real-world problem. BREAKDOWN OF TOPICS FOR The term “requirements engineering” is widely SOFTWARE REQUIREMENTS used in the field to denote the systematic handling of requirements. For reasons of consistency, the The breakdown of topics for the Software term “engineering” will not be used in this KA Requirements KA is shown in Figure 1.1. other than for software engineering per se. For the same reason, “requirements engineer,” 1. Software Requirements Fundamentals a term which appears in some of the literature, [1*, c4, c4s1, c10s1, c10s4] [2*, c1, c6, c12] will not be used either. Instead, the term “software engineer” or, in some specific cases, “require- 1.1. Definition of a Software Requirement ments specialist” will be used, the latter where the role in question is usually performed by an At its most basic, a software requirement is a individual other than a software engineer. This property that must be exhibited by something in

1-1 1-2 SWEBOK® Guide V3.0

Figure 1.1. Breakdown of Topics for the Software Requirements KA order to solve some problem in the real world. It requirements can be verified within available may aim to automate part of a task for someone resource constraints. to support the business processes of an organiza- Requirements have other attributes in addition, to correct shortcomings of existing software, tion to behavioral properties. Common examples or to control a device—to name just a few of the include a priority rating to enable tradeoffs in many problems for which software solutions are the face of finite resources and a status value to possible. The ways in which users, business pro- enable project progress to be monitored. Typi- cesses, and devices function are typically complex. cally, software requirements are uniquely identi- By extension, therefore, the requirements on par- fied so that they can be subjected to software con- ticular software are typically a complex combina- figuration management over the entire life cycle tion from various people at different levels of an of the feature and of the software. organization, and who are in one way or another involved or connected with this feature from the 1.2. Product and Process Requirements environment in which the software will operate. An essential property of all software require- A product requirement is a need or constraint on ments is that they be verifiable as an individual the software to be developed (for example, “The feature as a functional requirement or at the software shall verify that a student meets all pre- system level as a nonfunctional requirement. It requisites before he or she registers for a course”). may be difficult or costly to verify certain soft- A process requirement is essentially a con- ware requirements. For example, verification straint on the development of the software (for of the throughput requirement on a call center example, “The software shall be developed using may necessitate the development of simulation a RUP process”). software. Software requirements, software test- Some software requirements generate implicit ing, and quality personnel must ensure that the process requirements. The choice of verification Software Requirements 1-3

technique is one example. Another might be the depend for their interpretation on subjective use of particularly rigorous analysis techniques judgment (“the software shall be reliable”; “the (such as formal specification methods) to reduce software shall be user-friendly”). This is par- faults that can lead to inadequate reliability. Pro- ticularly important for nonfunctional require- cess requirements may also be imposed directly ments. Two examples of quantified requirements by the development organization, their customer, are the following: a call center’s software must or a third party such as a safety regulator. increase the center’s throughput by 20%; and a system shall have a probability of generating a 1.3. Functional and Nonfunctional Requirements fatal error during any hour of operation of less than 1 * 10−8. The throughput requirement is at a Functional requirements describe the functions very high level and will need to be used to derive that the software is to execute; for example, for- a number of detailed requirements. The reliabil- matting some text or modulating a signal. They ity requirement will tightly constrain the system are sometimes known as capabilities or features. architecture. A functional requirement can also be described as one for which a finite set of test steps can be 1.6. System Requirements and Software written to validate its behavior. Requirements Nonfunctional requirements are the ones that act to constrain the solution. Nonfunctional In this topic, “system” means requirements are sometimes known as constraints or quality requirements. They can be further clas- an interacting combination of elements sified according to whether they are performance to accomplish a defined objective. These requirements, maintainability requirements, include hardware, software, firmware, safety requirements, reliability requirements, people, information, techniques, facilities, security requirements, interoperability require- services, and other support elements, ments or one of many other types of software requirements (see Models and Quality Character- as defined by the International Council on Soft- istics in the Software Quality KA). ware and Systems Engineering (INCOSE) [3]. System requirements are the requirements for 1.4. Emergent Properties the system as a whole. In a system containing software components, software requirements are Some requirements represent emergent proper- derived from system requirements. ties of software—that is, requirements that can- This KA defines “user requirements” in a not be addressed by a single component but that restricted way, as the requirements of the sys- depend on how all the software components tem’s customers or end users. System require- interoperate. The throughput requirement for a ments, by contrast, encompass user requirements, call center would, for example, depend on how requirements of other stakeholders (such as regu- the telephone system, information system, and latory authorities), and requirements without an the operators all interacted under actual operat- identifiable human source. ing conditions. Emergent properties are crucially dependent on the system architecture. 2. Requirements Process [1*, c4s4] [2*, c1–4, c6, c22, c23] 1.5. Quantifiable Requirements This section introduces the software requirements Software requirements should be stated as clearly process, orienting the remaining five topics and and as unambiguously as possible, and, where showing how the requirements process dovetails appropriate, quantitatively. It is important to with the overall software engineering process. avoid vague and unverifiable requirements that 1-4 SWEBOK® Guide V3.0

2.1. Process Models marketing people are often needed to establish what the market needs and to act as The objective of this topic is to provide an under- proxy customers. standing that the requirements process • Regulators: Many application domains, such as banking and public transport, are regu- • is not a discrete front-end activity of the soft- lated. Software in these domains must com- ware life cycle, but rather a process initiated ply with the requirements of the regulatory at the beginning of a project that continues to authorities. be refined throughout the life cycle; • Software engineers: These individuals have • identifies software requirements as configu- a legitimate interest in profiting from devel- ration items and manages them using the oping the software by, for example, reusing same software configuration management components in or from other products. If, practices as other products of the software in this scenario, a customer of a particu- life cycle processes; lar product has specific requirements that • needs to be adapted to the organization and compromise the potential for component project context. reuse, the software engineers must carefully weigh their own stake against those of the In particular, the topic is concerned with how customer. Specific requirements, particu- the activities of elicitation, analysis, specifica- larly constraints, may have major impact on tion, and validation are configured for different project cost or delivery because they either types of projects and constraints. The topic also fit well or poorly with the skill set ofthe includes activities that provide input into the engineers. Important tradeoffs among such requirements process, such as marketing and fea- requirements should be identified. sibility studies. It will not be possible to perfectly satisfy the 2.2. Process Actors requirements of every stakeholder, and it is the software engineer’s job to negotiate tradeoffs that This topic introduces the roles of the people who are both acceptable to the principal stakeholders participate in the requirements process. This pro- and within budgetary, technical, regulatory, and cess is fundamentally interdisciplinary, and the other constraints. A prerequisite for this is that all requirements specialist needs to mediate between the stakeholders be identified, the nature of their the domain of the stakeholder and that of soft- “stake” analyzed, and their requirements elicited. ware engineering. There are often many people involved besides the requirements specialist, each 2.3. Process Support and Management of whom has a stake in the software. The stakeholders will vary across projects, but will always This section introduces the project management include users/operators and customers (who need resources required and consumed by the require- not be the same). ments process. It establishes the context for the Typical examples of software stakeholders first topic (Initiation and Scope Definition) of the include (but are not restricted to) the following: Software Engineering Management KA. Its principal purpose is to make the link between the pro- • Users: This group comprises those who will cess activities identified in 2.1 and the issues of operate the software. It is often a heteroge- cost, human resources, training, and tools. neous group involving people with different roles and requirements. 2.4. Process Quality and Improvement • Customers: This group comprises those who have commissioned the software or who rep- This topic is concerned with the assessment of resent the software’s target market. the quality and improvement of the requirements • Market analysts: A mass-market product process. Its purpose is to emphasize the key role will not have a commissioning customer, so the requirements process plays in terms of the Software Requirements 1-5

cost and timeliness of a software product and of to ensure the customer’s most important business the customer’s satisfaction with it. It will help to needs are satisfied first. This minimizes the risk orient the requirements process with quality stan- of requirements specialists spending time elicit- dards and process improvement models for soft- ing requirements that are of low importance, or ware and systems. Process quality and improve- those that turn out to be no longer relevant when ment is closely related to both the Software the software is delivered. On the other hand, the Quality KA and Software Engineering Process description must be scalable and extensible to KA, comprising accept further requirements not expressed in the first formal lists and compatible with the previous • requirements process coverage by process ones as contemplated in recursive methods. improvement standards and models; • requirements process measures and 3.1. Requirements Sources benchmarking; • improvement planning and implementation; Requirements have many sources in typical soft- • security/CIA improvement/planning and ware, and it is essential that all potential sources implementation. be identified and evaluated. This topic is designed to promote awareness of the various sources of 3. Requirements Elicitation software requirements and of the frameworks for [1*, c4s5] [2*, c5, c6, c9] managing them. The main points covered are as follows: Requirements elicitation is concerned with the origins of software requirements and how the • Goals. The term “goal” (sometimes called software engineer can collect them. It is the first “business concern” or “critical success fac- stage in building an understanding of the problem tor”) refers to the overall, high-level objec- the software is required to solve. It is fundamen- tives of the software. Goals provide the moti- tally a human activity and is where the stakehold- vation for the software but are often vaguely ers are identified and relationships established formulated. Software engineers need to pay between the development team and the customer. particular attention to assessing the value It is variously termed “requirements capture,” (relative to priority) and cost of goals. A fea- “requirements discovery,” and “requirements sibility study is a relatively low-cost way of acquisition.” doing this. One of the fundamental principles of a good • Domain knowledge. The software engineer requirements elicitation process is that of effec- needs to acquire or have available knowl- tive communication between the various stake- edge about the application domain. Domain holders. This communication continues through knowledge provides the background against the entire Software Development Life Cycle which all elicited requirements knowledge (SDLC) process with different stakeholders at must be set in order to understand it. It’s different points in time. Before development a good practice to emulate an ontological begins, requirements specialists may form the approach in the knowledge domain. Rela- conduit for this communication. They must medi- tions between relevant concepts within the ate between the domain of the software users (and application domain should be identified. other stakeholders) and the technical world of the • Stakeholders (see section 2.2, Process software engineer. A set of internally consistent Actors). Much software has proved unsat- models at different levels of abstraction facilitate isfactory because it has stressed the require- communications between software users/stake- ments of one group of stakeholders at the holders and software engineers. expense of others. Hence, the delivered A critical element of requirements elicitation is software is difficult to use, or subverts the informing the project scope. This involves provid- cultural or political structures of the cus- ing a description of the software being specified tomer organization. The software engineer and its purpose and prioritizing the deliverables needs to identify, represent, and manage 1-6 SWEBOK® Guide V3.0

the “viewpoints” of many different types of has yet to be obtained from end users. The impor- stakeholders. tance of planning, verification, and validation in • Business rules. These are statements that requirements elicitation cannot be overstated. A define or constrain some aspect of the struc- number of techniques exist for requirements elici- ture or the behavior of the business itself. “A tation; the principal ones are these: student cannot register in next semester’s courses if there remain some unpaid tuition • Interviews. Interviewing stakeholders is a fees” would be an example of a business rule “traditional” means of eliciting requirements. that would be a requirement source for a uni- It is important to understand the advantages versity’s course-registration software. and limitations of interviews and how they • The operational environment. Requirements should be conducted. will be derived from the environment in • Scenarios. Scenarios provide a valuable which the software will be executed. These means for providing context to the elicita- may be, for example, timing constraints tion of user requirements. They allow the in real-time software or performance con- software engineer to provide a framework straints in a business environment. These for questions about user tasks by permitting must be sought out actively because they can “what if” and “how is this done” questions greatly affect software feasibility and cost as to be asked. The most common type of sce- well as restrict design choices. nario is the use case description. There is a • The organizational environment. Software link here to topic 4.2 (Conceptual Modeling) is often required to support a business pro- because scenario notations such as use case cess, the selection of which may be condi- diagrams are common in modeling software. tioned by the structure, culture, and internal • Prototypes. This technique is a valuable tool politics of the organization. The software for clarifying ambiguous requirements. They engineer needs to be sensitive to these since, can act in a similar way to scenarios by pro- in general, new software should not force viding users with a context within which they unplanned change on the business process. can better understand what information they need to provide. There is a wide range of 3.2. Elicitation Techniques prototyping techniques—from paper mockups of screen designs to beta-test versions of Once the requirements sources have been iden- software products—and a strong overlap of tified, the software engineer can start eliciting their separate uses for requirements elicita- requirements information from them. Note that tion and for requirements validation (see requirements are seldom elicited ready-made. section 6.2, Prototyping). Low fidelity proto- Rather, the software engineer elicits information types are often preferred to avoid stakeholder from which he or she formulates requirements. “anchoring” on minor, incidental character- This topic concentrates on techniques for getting istics of a higher quality prototype that can human stakeholders to articulate requirements- limit design flexibility in unintended ways. relevant information. It is a very difficult task and • Facilitated meetings. The purpose of these the software engineer needs to be sensitized to the meetings is to try to achieve a summative fact that (for example) users may have difficulty effect, whereby a group of people can bring describing their tasks, may leave important infor- more insight into their software require- mation unstated, or may be unwilling or unable to ments than by working individually. They cooperate. It is particularly important to understand can brainstorm and refine ideas that may be that elicitation is not a passive activity and that, difficult to bring to the surface using inter- even if cooperative and articulate stakeholders are views. Another advantage is that conflicting available, the software engineer has to work hard requirements surface early on in a way that to elicit the right information. Many business or lets the stakeholders recognize where these technical requirements are tacit or in feedback that occur. When it works well, this technique Software Requirements 1-7

may result in a richer and more consistent 4. Requirements Analysis set of requirements than might otherwise [1*, c4s1, c4s5, c10s4, c12s5] be achievable. However, meetings need to [2*, c7, c11, c12, c17] be handled carefully (hence the need for a facilitator) to prevent a situation in which This topic is concerned with the process of ana- the critical abilities of the team are eroded lyzing requirements to by group loyalty, or in which requirements reflecting the concerns of a few outspoken • detect and resolve conflicts between (and perhaps senior) people that are favored requirements; to the detriment of others. • discover the bounds of the software and how • Observation. The importance of software it must interact with its organizational and context within the organizational environ- operational environment; ment has led to the adaptation of observa- • elaborate system requirements to derive soft- tional techniques such as ethnography for ware requirements. requirements elicitation. Software engineers learn about user tasks by immersing them- The traditional view of requirements analysis selves in the environment and observing how has been that it be reduced to conceptual model- users perform their tasks by interacting with ing using one of a number of analysis methods, each other and with software tools and other such as the structured analysis method. While resources. These techniques are relatively conceptual modeling is important, we include the expensive but also instructive because they classification of requirements to help inform trad- illustrate that many user tasks and business eoffs between requirements (requirements clas- processes are too subtle and complex for sification) and the process of establishing these their actors to describe easily. tradeoffs (requirements negotiation). • User stories. This technique is commonly Care must be taken to describe requirements used in adaptive methods (see Agile Meth- precisely enough to enable the requirements to ods in the Software Engineering Models be validated, their implementation to be verified, and Methods KA) and refers to short, high- and their costs to be estimated. level descriptions of required functionality expressed in customer terms. A typical user 4.1. Requirements Classification story has the form: “As a , I want so that .” A user Requirements can be classified on a number of story is intended to contain just enough infor- dimensions. Examples include the following: mation so that the developers can produce a reasonable estimate of the effort to imple- • Whether the requirement is functional or ment it. The aim is to avoid some of the waste nonfunctional (see section 1.3, Functional that often happens in projects where detailed and Nonfunctional Requirements). requirements are gathered early but become • Whether the requirement is derived from one invalid before the work begins. Before a user or more high-level requirements or an emer- story is implemented, an appropriate accep- gent property (see section 1.4, Emergent tance procedure must be written by the cus- Properties), or is being imposed directly on tomer to determine whether the goals of the the software by a stakeholder or some other user story have been fulfilled. source. • Other techniques. A range of other techniques • Whether the requirement is on the product for supporting the elicitation of requirements or the process (see section 1.2, Product and information exist and range from analyzing Process Requirements). Requirements on the competitors’ products to applying data min- process can constrain the choice of contrac- ing techniques to using sources of domain tor, the software engineering process to be knowledge or customer request databases. adopted, or the standards to be adhered to. 1-8 SWEBOK® Guide V3.0

• The requirement priority. The higher the pri- 4.2. Conceptual Modeling ority, the more essential the requirement is for meeting the overall goals of the software. The development of models of a real-world Often classified on a fixed-point scale such problem is key to software requirements analy- as mandatory, highly desirable, desirable, sis. Their purpose is to aid in understanding the or optional, the priority often has to be bal- situation in which the problem occurs, as well as anced against the cost of development and depicting a solution. Hence, conceptual models implementation. comprise models of entities from the problem • The scope of the requirement. Scope refers domain, configured to reflect their real-world to the extent to which a requirement affects relationships and dependencies. This topic is the software and software components. closely related to the Software Engineering Mod- Some requirements, particularly certain els and Methods KA. nonfunctional ones, have a global scope in Several kinds of models can be developed. that their satisfaction cannot be allocated to These include use case diagrams, data flow mod- a discrete component. Hence, a requirement els, state models, goal-based models, user inter- with global scope may strongly affect the actions, object models, data models, and many software architecture and the design of many others. Many of these modeling notations are part components, whereas one with a narrow of the Unified Modeling Language (UML). Use scope may offer a number of design choices case diagrams, for example, are routinely used and have little impact on the satisfaction of to depict scenarios where the boundary separates other requirements. the actors (users or systems in the external envi- • Volatility/stability. Some requirements will ronment) from the internal behavior where each change during the life cycle of the soft- use case depicts a functionality of the system. ware—and even during the development The factors that influence the choice of model- process itself. It is useful if some estimate ing notation include these: of the likelihood that a requirement will change can be made. For example, in a bank- • The nature of the problem. Some types of ing application, requirements for functions software demand that certain aspects be ana- to calculate and credit interest to customers’ lyzed particularly rigorously. For example, accounts are likely to be more stable than a state and parametric models, which are part requirement to support a particular kind of of SysML [4], are likely to be more impor- tax-free account. The former reflects a fun- tant for real-time software than for informa- damental feature of the banking domain (that tion systems, while it would usually be the accounts can earn interest), while the latter opposite for object and activity models. may be rendered obsolete by a change to • The expertise of the software engineer. It is government legislation. Flagging potentially often more productive to adopt a modeling volatile requirements can help the software notation or method with which the software engineer establish a design that is more toler- engineer has experience. ant of change. • The process requirements of the customer (see section 1.2, Product and Process Other classifications may be appropriate, Requirements). Customers may impose their depending upon the organization’s normal prac- favored notation or method or prohibit any tice and the application itself. with which they are unfamiliar. This factor There is a strong overlap between requirements can conflict with the previous factor. classification and requirements attributes (see section 7.3, Requirements Attributes). Note that, in almost all cases, it is useful to start by building a model of the software context. The software context provides a connection between the intended software and its external environment. Software Requirements 1-9

This is crucial to understanding the software’s con- 4.4. Requirements Negotiation text in its operational environment and to identifying its interfaces with the environment. Another term commonly used for this subtopic This subtopic does not seek to “teach” a particu- is “conflict resolution.” This concerns resolv- lar modeling style or notation but rather provides ing problems with requirements where conflicts guidance on the purpose and intent of modeling. occur between two stakeholders requiring mutually incompatible features, between requirements 4.3. Architectural Design and Requirements and resources, or between functional and non- Allocation functional requirements, for example. In most cases, it is unwise for the software engineer to At some point, the solution architecture must make a unilateral decision, so it becomes neces- be derived. Architectural design is the point at sary to consult with the stakeholder(s) to reach a which the requirements process overlaps with consensus on an appropriate tradeoff. It is often software or systems design and illustrates how important, for contractual reasons, that such deci- impossible it is to cleanly decouple the two tasks. sions be traceable back to the customer. We have This topic is closely related to Software Structure classified this as a software requirements analy- and Architecture in the Software Design KA. In sis topic because problems emerge as the result many cases, the software engineer acts as soft- of analysis. However, a strong case can also be ware architect because the process of analyzing made for considering it a requirements validation and elaborating the requirements demands that topic (see topic 6, Requirements Validation). the architecture/design components that will be Requirements prioritization is necessary, not responsible for satisfying the requirements be only as a means to filter important requirements, identified. This is requirements allocation–the but also in order to resolve conflicts and plan for assignment to architecture components respon- staged deliveries, which means making complex sible for satisfying the requirements. decisions that require detailed domain knowledge Allocation is important to permit detailed anal- and good estimation skills. However, it is often ysis of requirements. Hence, for example, once a difficult to get real information that can act as set of requirements has been allocated to a com- a basis for such decisions. In addition, require- ponent, the individual requirements can be further ments often depend on each other, and priori- analyzed to discover further requirements on how ties are relative. In practice, software engineers the component needs to interact with other com- perform requirements prioritization frequently ponents in order to satisfy the allocated require- without knowing about all the requirements. ments. In large projects, allocation stimulates a Requirements prioritization may follow a cost- new round of analysis for each subsystem. As an value approach that involves an analysis from example, requirements for a particular braking the stakeholders defining in a scale the benefits performance for a car (braking distance, safety in or the aggregated value that the implementa- poor driving conditions, smoothness of application of the requirement brings them, versus the tion, pedal pressure required, and so on) may be penalties of not having implemented a particular allocated to the braking hardware (mechanical requirement. It also involves an analysis from and hydraulic assemblies) and an antilock braking the software engineers estimating in a scale the system (ABS). Only when a requirement for an cost of implementing each requirement, relative antilock braking system has been identified, and to other requirements. Another requirements pri- the requirements allocated to it, can the capabili- oritization approach called the analytic hierarchy ties of the ABS, the braking hardware, and emer- process involves comparing all unique pairs of gent properties (such as car weight) be used to requirements to determine which of the two is of identify the detailed ABS software requirements. higher priority, and to what extent. Architectural design is closely identified with conceptual modeling (see section 4.2, Conceptual Modeling). 1-10 SWEBOK® Guide V3.0

4.5. Formal Analysis a document that can be systematically reviewed, evaluated, and approved. For complex systems, Formal analysis concerns not only topic 4, but particularly those involving substantial nonsoft- also sections 5.3 and 6.3. This topic is also related ware components, as many as three different to Formal Methods in the Software Engineering types of documents are produced: system defini- Models and Methods Knowledge Area. tion, system requirements, and software require- Formal analysis has made an impact on some ments. For simple software products, only the application domains, particularly those of high- third of these is required. All three documents are integrity systems. The formal expression of described here, with the understanding that they requirements requires a language with formally may be combined as appropriate. A description of defined semantics. The use of a formal analysis systems engineering can be found in the Related for requirements expression has two benefits. Disciplines of Software Engineering chapter of First, it enables requirements expressed in the this Guide. language to be specified precisely and unambiguously, thus (in principle) avoiding the potential 5.1. System Definition Document for misinterpretation. Secondly, requirements can be reasoned over, permitting desired properties This document (sometimes known as the user of the specified software to be proven. Formal requirements document or concept of operations reasoning requires tool support to be practicable document) records the system requirements. It for anything other than trivial systems, and tools defines the high-level system requirements from generally fall into two types: theorem provers or the domain perspective. Its readership includes model checkers. In neither case can proof be fully representatives of the system users/customers automated, and the level of competence in formal (marketing may play these roles for market- reasoning needed in order to use the tools restricts driven software), so its content must be couched the wider application of formal analysis. in terms of the domain. The document lists the Most formal analysis is focused on relatively system requirements along with background late stages of requirements analysis. It is gener- information about the overall objectives for the ally counterproductive to apply formalization system, its target environment, and a statement of until the business goals and user requirements the constraints, assumptions, and nonfunctional have come into sharp focus through means such requirements. It may include conceptual models as those described elsewhere in section 4. How- designed to illustrate the system context, usage ever, once the requirements have stabilized and scenarios, and the principal domain entities, as have been elaborated to specify concrete proper- well as workflows. ties of the software, it may be beneficial to for- malize at least the critical requirements. This per- 5.2. System Requirements Specification mits static validation that the software specified by the requirements does indeed have the proper- Developers of systems with substantial software ties (for example, absence of deadlock) that the and nonsoftware components—a modern air- customer, users, and software engineer expect it liner, for example—often separate the descrip- to have. tion of system requirements from the description of software requirements. In this view, system 5. Requirements Specification requirements are specified, the software require- [1*, c4s2, c4s3, c12s2–5] [2*, c10] ments are derived from the system requirements, and then the requirements for the software com- For most engineering professions, the term “spec- ponents are specified. Strictly speaking, system ification” refers to the assignment of numerical requirements specification is a systems engineer- values or limits to a product’s design goals. In ing activity and falls outside the scope of this software engineering, “software requirements Guide. specification” typically refers to the production of Software Requirements 1-11

5.3. Software Requirements Specification 6. Requirements Validation [1*, c4s6] [2*, c13, c15] Software requirements specification establishes the basis for agreement between customers and The requirements documents may be subject to val- contractors or suppliers (in market-driven proj- idation and verification procedures. The require- ects, these roles may be played by the marketing ments may be validated to ensure that the software and development divisions) on what the software engineer has understood the requirements; it is product is to do as well as what it is not expected also important to verify that a requirements docu- to do. ment conforms to company standards and that it Software requirements specification permits is understandable, consistent, and complete. In a rigorous assessment of requirements before cases where documented company standards or design can begin and reduces later redesign. It terminology are inconsistent with widely accepted should also provide a realistic basis for estimat- standards, a mapping between the two should be ing product costs, risks, and schedules. agreed on and appended to the document. Organizations can also use a software require- Formal notations offer the important advantage ments specification document as the basis for of permitting the last two properties to be proven developing effective verification and validation (in a restricted sense, at least). Different stake- plans. holders, including representatives of the customer Software requirements specification provides and developer, should review the document(s). an informed basis for transferring a software prod- Requirements documents are subject to the same uct to new users or software platforms. Finally, it configuration management practices as the other can provide a basis for software enhancement. deliverables of the software life cycle processes. Software requirements are often written in When practical, the individual requirements are natural language, but, in software requirements also subject to configuration management, gener- specification, this may be supplemented by for- ally using a requirements management tool (see mal or semiformal descriptions. Selection of topic 8, Software Requirements Tools). appropriate notations permits particular require- It is normal to explicitly schedule one or more ments and aspects of the software architecture to points in the requirements process where the be described more precisely and concisely than requirements are validated. The aim is to pick up natural language. The general rule is that nota- any problems before resources are committed to tions should be used that allow the requirements addressing the requirements. Requirements vali- to be described as precisely as possible. This is dation is concerned with the process of examin- particularly crucial for safety-critical, regulatory, ing the requirements document to ensure that it and certain other types of dependable software. defines the right software (that is, the software However, the choice of notation is often con- that the users expect). strained by the training, skills, and preferences of the document’s authors and readers. 6.1. Requirements Reviews A number of quality indicators have been developed that can be used to relate the quality Perhaps the most common means of validation of software requirements specification to other is by inspection or reviews of the requirements project variables such as cost, acceptance, per- document(s). A group of reviewers is assigned formance, schedule, and reproducibility. Quality a brief to look for errors, mistaken assumptions, indicators for individual software requirements lack of clarity, and deviation from standard prac- specification statements include imperatives, tice. The composition of the group that conducts directives, weak phrases, options, and continu- the review is important (at least one represen- ances. Indicators for the entire software require- tative of the customer should be included for a ments specification document include size, read- customer-driven project, for example), and it may ability, specification, depth, and text structure. help to provide guidance on what to look for in the form of checklists. 1-12 SWEBOK® Guide V3.0

Reviews may be constituted on completion of domain, exchange data. If formal analysis nota- the system definition document, the system spec- tions are used, it is possible to use formal reason- ification document, the software requirements ing to prove specification properties. This topic is specification document, the baseline specifica- closely related to the Software Engineering Mod- tion for a new release, or at any other step in the els and Methods KA. process. 6.4. Acceptance Tests 6.2. Prototyping An essential property of a software requirement Prototyping is commonly a means for validating is that it should be possible to validate that the the software engineer’s interpretation of the soft- finished product satisfies it. Requirements that ware requirements, as well as for eliciting new cannot be validated are really just “wishes.” An requirements. As with elicitation, there is a range important task is therefore planning how to ver- of prototyping techniques and a number of points ify each requirement. In most cases, designing in the process where prototype validation may acceptance tests does this for how end-users typi- be appropriate. The advantage of prototypes is cally conduct business using the system. that they can make it easier to interpret the soft- Identifying and designing acceptance tests ware engineer’s assumptions and, where needed, may be difficult for nonfunctional requirements give useful feedback on why they are wrong. For (see section 1.3, Functional and Nonfunctional example, the dynamic behavior of a user inter- Requirements). To be validated, they must first face can be better understood through an ani- be analyzed and decomposed to the point where mated prototype than through textual description they can be expressed quantitatively. or graphical models. The volatility of a require- Additional information can be found in Accep- ment that is defined after prototyping has been tance/Qualification/Conformance Testing in the done is extremely low because there is agreement Software Testing KA. between the stakeholder and the software engineer—therefore, for safety-critical and crucial 7. Practical Considerations features prototyping would really help. There are [1*, c4s1, c4s4, c4s6, c4s7] also disadvantages, however. These include the [2*, c3, c12, c14, c16, c18–21] danger of users’ attention being distracted from the core underlying functionality by cosmetic The first level of topic decomposition pre- issues or quality problems with the prototype. For sented in this KA may seem to describe a linear this reason, some advocate prototypes that avoid sequence of activities. This is a simplified view software, such as flip-chart-based mockups. Pro- of the process. totypes may be costly to develop. However, if The requirements process spans the whole they avoid the wastage of resources caused by software life cycle. Change management and the trying to satisfy erroneous requirements, their maintenance of the requirements in a state that cost can be more easily justified. Early proto- accurately mirrors the software to be built, or that types may contain aspects of the final solution. has been built, are key to the success of the soft- Prototypes may be evolutionary as opposed to ware engineering process. throwaway. Not every organization has a culture of documenting and managing requirements. It is com- 6.3. Model Validation mon in dynamic start-up companies, driven by a strong “product vision” and limited resources, to It is typically necessary to validate the quality of view requirements documentation as unnecessary the models developed during analysis. For exam- overhead. Most often, however, as these compa- ple, in object models, it is useful to perform a nies expand, as their customer base grows, and static analysis to verify that communication paths as their product starts to evolve, they discover exist between objects that, in the stakeholders’ that they need to recover the requirements that Software Requirements 1-13

motivated product features in order to assess the proceeds. This often leads to the revision of impact of proposed changes. Hence, requirements requirements late in the life cycle. Perhaps the documentation and change management are key most crucial point in understanding software to the success of any requirements process. requirements is that a significant proportion of the requirements will change. This is sometimes 7.1. Iterative Nature of the Requirements due to errors in the analysis, but it is frequently an Process inevitable consequence of change in the “environment”—for example, the customer’s operating There is general pressure in the software indus- or business environment, regulatory processes try for ever shorter development cycles, and this imposed by the authorities, or the market into is particularly pronounced in highly competitive, which software must sell. Whatever the cause, it is market-driven sectors. Moreover, most projects important to recognize the inevitability of change are constrained in some way by their environment, and take steps to mitigate its effects. Change has and many are upgrades to, or revisions of, exist- to be managed by ensuring that proposed changes ing software where the architecture is a given. In go through a defined review and approval- pro practice, therefore, it is almost always impractical cess and by applying careful requirements trac- to implement the requirements process as a linear, ing, impact analysis, and software configuration deterministic process in which software require- management (see the Software Configuration ments are elicited from the stakeholders, base- Management KA). Hence, the requirements pro- lined, allocated, and handed over to the software cess is not merely a front-end task in software development team. It is certainly a myth that the development, but spans the whole software life requirements for large software projects are ever cycle. In a typical project, the software require- perfectly understood or perfectly specified. ments activities evolve over time from elicitation Instead, requirements typically iterate towards to change management. A combination of top- a level of quality and detail that is sufficient to down analysis and design methods and bottom- permit design and procurement decisions to be up implementation and refactoring methods that made. In some projects, this may result in the meet in the middle could provide the best of both requirements being baselined before all their worlds. However, this is difficult to achieve in properties are fully understood. This risks expen- practice, as it depends heavily upon the maturity sive rework if problems emerge late in the soft- and expertise of the software engineers. ware engineering process. However, software engineers are necessarily constrained by project 7.2. Change Management management plans and must therefore take steps to ensure that the “quality” of the requirements is Change management is central to the management as high as possible given the available resources. of requirements. This topic describes the role of They should, for example, make explicit any change management, the procedures that need to assumptions that underpin the requirements as be in place, and the analysis that should be applied well as any known problems. to proposed changes. It has strong links to the Soft- For software products that are developed iter- ware Configuration Management KA. atively, a project team may baseline only those requirements needed for the current iteration. The 7.3. Requirements Attributes requirements specialist can continue to develop requirements for future iterations, while develop- Requirements should consist not only of a speci- ers proceed with design and construction of the fication of what is required, but also of ancillary current iteration. This approach provides custom- information, which helps manage and interpret ers with business value quickly, while minimiz- the requirements. Requirements attributes must ing the cost of rework. be defined, recorded, and updated as the- soft In almost all cases, requirements understanding ware under development or maintenance evolves. continues to evolve as design and development This should include the various classification 1-14 SWEBOK® Guide V3.0

dimensions of the requirement (see section 4.1, 7.5. Measuring Requirements Requirements Classification) and the verification method or relevant acceptance test plan section. As a practical matter, it is typically useful to have It may also include additional information, such some concept of the “volume” of the require- as a summary rationale for each requirement, the ments for a particular software product. This source of each requirement, and a change history. number is useful in evaluating the “size” of a The most important requirements attribute, how- change in requirements, in estimating the cost of ever, is an identifier that allows the requirements a development or maintenance task, or simply for to be uniquely and unambiguously identified. use as the denominator in other measurements. Functional size measurement (FSM) is a tech- 7.4. Requirements Tracing nique for evaluating the size of a body of functional requirements. Requirements tracing is concerned with recover- Additional information on size measurement ing the source of requirements and predicting the and standards will be found in the Software Engi- effects of requirements. Tracing is fundamental neering Process KA. to performing impact analysis when requirements change. A requirement should be traceable back- 8. Software Requirements Tools ward to the requirements and stakeholders that motivated it (from a software requirement back Tools for dealing with software requirements fall to the system requirement(s) that it helps satisfy, broadly into two categories: tools for modeling for example). Conversely, a requirement should and tools for managing requirements. be traceable forward into the requirements and Requirements management tools typically sup- design entities that satisfy it (for example, from port a range of activities—including documenta- a system requirement into the software require- tion, tracing, and change management—and have ments that have been elaborated from it, and on had a significant impact on practice. Indeed, trac- into the code modules that implement it, or the ing and change management are really only prac- test cases related to that code and even a given ticable if supported by a tool. Since requirements section on the user manual which describes the management is fundamental to good require- actual functionality) and into the test case that ments practice, many organizations have invested verifies it. in requirements management tools, although The requirements tracing for a typical proj- many more manage their requirements in more ect will form a complex directed acyclic graph ad hoc and generally less satisfactory ways (e.g., (DAG) (see Graphs in the Computing Founda- using spreadsheets). tions KA) of requirements. Maintaining an up-to- date graph or traceability matrix is an activity that must be considered during the whole life cycle of a product. If the traceability information is not updated as changes in the requirements continue to happen, the traceability information becomes unreliable for impact analysis. Software Requirements 1-15

MATRIX OF TOPICS VS. REFERENCE MATERIAL [1*] [2*] Wiegers 2003 Sommerville 2011 1. Software Requirements Fundamentals 1.1. Definition of a Software Requirement c4 c1 1.2. Product and Process Requirements c4s1 c1, c6 1.3. Functional and Nonfunctional Requirements c4s1 c12 1.4. Emergent Properties c10s1 1.5. Quantifiable Requirements c1 1.6. System Requirements and Software Requirements c10s4 c1 2. Requirements Process 2.1. Process Models c4s4 c3 2.2. Process Actors c1, c2, c4, c6 2.3. Process Support and Management c3 2.4. Process Quality and Improvement c22, c23 3. Requirements Elicitation 3.1. Requirements Sources c4s5 c5, c6,c9 3.2. Elicitation Techniques c4s5 c6 4. Requirements Analysis 4.1. Requirements Classification c4s1 c12 4.2. Conceptual Modeling c4s5 c11 4.3. Architectural Design and Requirements Allocation c10s4 c17 4.4. Requirements Negotiation c4s5 c7 4.5. Formal Analysis c12s5 5. Requirements Specification 5.1. System Definition Document c4s2 c10 c4s2, c12s2, 5.2. System Requirements Specification c12s3, c12s4, c10 c12s5 5.3. Software Requirements Specification c4s3 c10 6. Requirements Validation 6.1. Requirements Reviews c4s6 c15 6.2. Prototyping c4s6 c13 6.3. Model Validation c4s6 c15 6.4. Acceptance Tests c4s6 c15 1-16 SWEBOK® Guide V3.0 [1*] [2*] Wiegers 2003 Sommerville 2011 7. Practical Considerations 7.1. Iterative Nature of the Requirements Process c4s4 c3, c16 7.2. Change Management c4s7 c18, c19 7.3. Requirements Attributes c4s1 c12, c14 7.4. Requirements Tracing c20 7.5. Measuring Requirements c4s6 c18 8. Software Requirements Tools c21 Software Requirements 1-17

FURTHER READINGS I. Alexander and L. Beus-Dukic, Discovering A. van Lamsweerde, Requirements Requirements [5]. Engineering: From System Goals to UML Models to Software Specifications [7]. An easily digestible and practically oriented book on software requirements, this is perhaps Serves as a good introduction to requirements the best of current textbooks on how the various engineering but its unique value is as a reference elements of software requirements fit together. It book for the KAOS goal-oriented requirements is full of practical advice on (for example) how modelling language. Explains why goal model- to identify the various system stakeholders and ling is useful and shows how it can integrate with how to evaluate alternative solutions. Its cover- mainstream modelling techniques using UML. age is exemplary and serves as a useful reference for key techniques such as use case modeling and O. Gotel and A. Finkelstein, “An Analysis of the requirements prioritization. Requirements Traceability Problem” [8].

C. Potts, K. Takahashi, and A. Antón, “Inquiry- This paper is a classic reference work on a key Based Requirements Analysis” [6]. element of requirements management. Based on empirical studies, it sets out the reasons for and This paper is an easily digested account of work the barriers to the effective tracing of require- that has proven to be very influential in the devel- ments. It is essential reading for an understanding opment of requirements handling. It describes of why requirements tracing is an essential ele- how and why the elaboration of requirements ment of an effective software process. cannot be a linear process by which the analyst simply transcribes and reformulates requirements N. Maiden and C. Ncube, “Acquiring COTS elicited from the customer. The role of scenarios Software Selection Requirements” [9]. is described in a way that helps to define their use in discovering and describing requirements. This paper is significant because it recognises explicitly that software products often integrate third-party components. It offers insights into the problems of selecting off-the-shelf software to satisfy requirements: there is usually a mismatch. This challenges some of the assumptions under- pinning much of traditional requirements handling, which tends to assume custom software. 1-18 SWEBOK® Guide V3.0

REFERENCES [1*] I. Sommerville, Software Engineering, 9th [6] C. Potts, K. Takahashi, and A.I. Antón, ed., Addison-Wesley, 2011. “Inquiry-Based Requirements Analysis,” IEEE Software, vol. 11, no. 2, Mar. 1994, [2*] K.E. Wiegers, Software Requirements, 2nd pp. 21–32. ed., Microsoft Press, 2003. [7] A. van Lamsweerde, Requirements [3] INCOSE, Systems Engineering Handbook: Engineering: From System Goals to UML A Guide for System Life Cycle Processes Models to Software Specifications, Wiley, and Activities, version 3.2.2, International 2009. Council on Systems Engineering, 2012. [8] O. Gotel and C.W. Finkelstein, “An Analysis [4] S. Friedenthal, A. Moore, and R. Steiner, A of the Requirements Traceability Problem,” Practical Guide to SysML: The Systems Proc. 1st Int’l Conf. Requirements Eng., Modeling Language, 2nd ed., Morgan IEEE, 1994. Kaufmann, 2012. [9] N.A. Maiden and C. Ncube, “Acquiring [5] I. Alexander and L. Beus-Deukic, COTS Software Selection Requirements,” Discovering Requirements: How to Specify IEEE Software, vol. 15, no. 2, Mar.–Apr. Products and Services, Wiley, 2009. 1998, pp. 46–56. CHAPTER 2

SOFTWARE DESIGN

ACRONYMS We can also examine and evaluate alternative solutions and tradeoffs. Finally, we can use the Architecture Description ADL resulting models to plan subsequent development Language activities, such as system verification and valida- CBD Component-Based Design tion, in addition to using them as inputs and as the CRC Class Responsibility Collaborator starting point of construction and testing. DFD Data Flow Diagram In a standard list of software life cycle processes, such as that in ISO/IEC/IEEE Std. 12207, ERD Entity Relationship Diagram Software Life Cycle Processes [2], software design IDL Interface Description Language consists of two activities that fit between software MVC Model View Controller requirements analysis and software construction: OO Object-Oriented • Software architectural design (sometimes PDL Program Design Language called high-level design): develops top-level structure and organization of the software and identifies the various components. INTRODUCTION • Software detailed design: specifies each component in sufficient detail to facilitate its Design is defined as both “the process of defin- construction. ing the architecture, components, interfaces, and other characteristics of a system or component” This Software Design knowledge area (KA) and “the result of [that] process” [1]. Viewed as a does not discuss every topic that includes the process, software design is the software engineer- word “design.” In Tom DeMarco’s terminology ing life cycle activity in which software require- [3], the topics discussed in this KA deal mainly ments are analyzed in order to produce a descrip- with D-design (decomposition design), the goal tion of the software’s internal structure that will of which is to map software into component serve as the basis for its construction. A software pieces. However, because of its importance in design (the result) describes the software archi- the field of software architecture, we will also tecture—that is, how software is decomposed address FP-design (family pattern design), the and organized into components—and the inter- goal of which is to establish exploitable com- faces between those components. It should also monalities in a family of software products. This describe the components at a level of detail that KA does not address I-design (invention design), enables their construction. which is usually performed during the software Software design plays an important role in requirements process with the goal of conceptu- developing software: during software design, alizing and specifying software to satisfy discov- software engineers produce various models ered needs and requirements, since this topic is that form a kind of blueprint of the solution to considered to be part of the requirements process be implemented. We can analyze and evaluate (see the Software Requirements KA). these models to determine whether or not they This Software Design KA is related specifi- will allow us to fulfill the various requirements. cally to the Software Requirements, Software

2-1 2-2 SWEBOK® Guide V3.0

Figure 2.1. Breakdown of Topics for the Software Design KA

Construction, Software Engineering Manage- understanding the limits of design. A number of ment, Software Engineering Models and Meth- other notions and concepts are also of interest in ods, Software Quality, and Computing Founda- understanding design in its general sense: goals, tions KAs. constraints, alternatives, representations, and solutions (see Problem Solving Techniques in the BREAKDOWN OF TOPICS FOR Computing Foundations KA). SOFTWARE DESIGN 1.2. Context of Software Design The breakdown of topics for the Software Design [4*, c3] KA is shown in Figure 2.1. Software design is an important part of the soft- 1. Software Design Fundamentals ware development process. To understand the role of software design, we must see how it fits The concepts, notions, and terminology intro- in the software development life cycle. Thus, it duced here form an underlying basis for under- is important to understand the major characteris- standing the role and scope of software design. tics of software requirements analysis, software design, software construction, software testing, 1.1. General Design Concepts and software maintenance. [4*, c1] 1.3. Software Design Process In the general sense, design can be viewed as a [4*, c2] form of problem solving. For example, the concept of a wicked problem—a problem with no Software design is generally considered a two- definitive solution—is interesting in terms of step process: Software Design 2-3

• Architectural design (also referred to as high- software is divided into a number of smaller level design and top-level design) describes named components having well-defined how software is organized into components. interfaces that describe component interac- • Detailed design describes the desired behav- tions. Usually the goal is to place different ior of these components. functionalities and responsibilities in different components. The output of these two processes is a set of • Encapsulation and information hiding means models and artifacts that record the major deci- grouping and packaging the internal details sions that have been taken, along with an explana- of an abstraction and making those details tion of the rationale for each nontrivial decision. inaccessible to external entities. By recording the rationale, long-term maintain- • Separation of interface and implementation. ability of the software product is enhanced. Separating interface and implementation involves defining a component by specify- 1.4. Software Design Principles ing a public interface (known to the clients) [4*] [5*, c6, c7, c21] [6*, c1, c8, c9] that is separate from the details of how the component is realized (see encapsulation and A principle is “a comprehensive and fundamen- information hiding above). tal law, doctrine, or assumption” [7]. Software • Sufficiency, completeness, and primitiveness. design principles are key notions that provide Achieving sufficiency and completeness the basis for many different software design means ensuring that a software component approaches and concepts. Software design princi- captures all the important characteristics of ples include abstraction; coupling and cohesion; an abstraction and nothing more. Primitive- decomposition and modularization; encapsula- ness means the design should be based on tion/information hiding; separation of interface patterns that are easy to implement. and implementation; sufficiency, completeness, • Separation of concerns. A concern is an and primitiveness; and separation of concerns. “area of interest with respect to a software design” [8]. A design concern is an area of • Abstraction is “a view of an object that design that is relevant to one or more of its focuses on the information relevant to a stakeholders. Each architecture view frames particular purpose and ignores the remain- one or more concerns. Separating concerns der of the information” [1] (see Abstraction by views allows interested stakeholders to in the Computing Foundations KA). In the focus on a few things at a time and offers a context of software design, two key abstrac- means of managing complexity [9]. tion mechanisms are parameterization and specification. Abstraction by parameteriza- 2. Key Issues in Software Design tion abstracts from the details of data representations by representing the data as named A number of key issues must be dealt with when parameters. Abstraction by specification designing software. Some are quality concerns leads to three major kinds of abstraction: that all software must address—for example, procedural abstraction, data abstraction, and performance, security, reliability, usability, etc. control (iteration) abstraction. Another important issue is how to decompose, • Coupling and Cohesion. Coupling is defined organize, and package software components. as “a measure of the interdependence among This is so fundamental that all design approaches modules in a computer program,” whereas address it in one way or another (see section 1.4, cohesion is defined as “a measure of the Software Design Principles, and topic 7, Soft- strength of association of the elements within ware Design Strategies and Methods). In contrast, a module” [1]. other issues “deal with some aspect of software’s • Decomposition and modularization. Decom- behavior that is not in the application domain, posing and modularizing means that large but which addresses some of the supporting 2-4 SWEBOK® Guide V3.0

domains” [10]. Such issues, which often crosscut 2.6. Interaction and Presentation the system’s functionality, have been referred to [5*, c16] as aspects, which “tend not to be units of software’s functional decomposition, but rather to be This design issue is concerned with how to struc- properties that affect the performance or seman- ture and organize interactions with users as well tics of the components in systemic ways” [11]. as the presentation of information (for example, A number of these key, crosscutting issues are separation of presentation and business logic discussed in the following sections (presented in using the Model-View-Controller approach). alphabetical order). Note that this topic does not specify user interface details, which is the task of user interface design 2.1. Concurrency (see topic 4, User Interface Design). [5*, c18] 2.7. Security Design for concurrency is concerned with decom- [5*, c12, c18] [13*, c4] posing software into processes, tasks, and threads and dealing with related issues of efficiency, Design for security is concerned with how to pre- atomicity, synchronization, and scheduling. vent unauthorized disclosure, creation, change, deletion, or denial of access to information and 2.2. Control and Handling of Events other resources. It is also concerned with how to [5*, c21] tolerate security-related attacks or violations by limiting damage, continuing service, speeding This design issue is concerned with how to repair and recovery, and failing and recovering organize data and control flow as well as how securely. Access control is a fundamental con- to handle reactive and temporal events through cept of security, and one should also ensure the various mechanisms such as implicit invocation proper use of cryptology. and call-backs. 3. Software Structure and Architecture 2.3. Data Persistence [12*, c9] In its strict sense, a software architecture is “the set of structures needed to reason about This design issue is concerned with how to han- the system, which comprise software elements, dle long-lived data. relations among them, and properties of both” [14*]. During the mid-1990s, however, soft- 2.4. Distribution of Components ware architecture started to emerge as a broader [5*, c18] discipline that involved the study of software structures and architectures in a more generic This design issue is concerned with how to dis- way. This gave rise to a number of interesting tribute the software across the hardware (includ- concepts about software design at different lev- ing computer hardware and network hardware), els of abstraction. Some of these concepts can how the components communicate, and how be useful during the architectural design (for middleware can be used to deal with heteroge- example, architectural styles) as well as during neous software. the detailed design (for example, design patterns). These design concepts can also be used 2.5. Error and Exception Handling and Fault to design families of programs (also known as Tolerance product lines). Interestingly, most of these con- [5*, c18] cepts can be seen as attempts to describe, and thus reuse, design knowledge. This design issue is concerned with how to prevent, tolerate, and process errors and deal with exceptional conditions. Software Design 2-5

3.1. Architectural Structures and Viewpoints patterns describing the high-level organization [14*, c1] of software, other design patterns can be used to describe details at a lower level. These lower Different high-level facets of a software design level design patterns include the following: can be described and documented. These facets are often called views: “A view represents a partial • Creational patterns (for example, builder, aspect of a software architecture that shows spe- factory, prototype, singleton) cific properties of a software system” [14*]. Views • Structural patterns (for example, adapter, pertain to distinct issues associated with software bridge, composite, decorator, façade, fly- design—for example, the logical view (satisfying weight, proxy) the functional requirements) vs. the process view • Behavioral patterns (for example, command, (concurrency issues) vs. the physical view (distri- interpreter, iterator, mediator, memento, bution issues) vs. the development view (how the observer, state, strategy, template, visitor). design is broken down into implementation units with explicit representation of the dependencies 3.4. Architecture Design Decisions among the units). Various authors use different [5*, c6] terminologies—like behavioral vs. functional vs. structural vs. data modeling views. In summary, a Architectural design is a creative process. Dur- software design is a multifaceted artifact produced ing the design process, software designers have by the design process and generally composed of to make a number of fundamental decisions that relatively independent and orthogonal views. profoundly affect the software and the development process. It is useful to think of the archi- 3.2. Architectural Styles tectural design process from a decision-making [14*, c1, c2, c3, c4, c5] perspective rather than from an activity perspective. Often, the impact on quality attributes and An architectural style is “a specialization of ele- tradeoffs among competing quality attributes are ment and relation types, together with a set of the basis for design decisions. constraints on how they can be used” [14*]. An architectural style can thus be seen as providing 3.5. Families of Programs and Frameworks the software’s high-level organization. Various [5*, c6, c7, c16] authors have identified a number of major architectural styles: One approach to providing for reuse of software designs and components is to design families of • General structures (for example, layers, pipes programs, also known as software product lines. and filters, blackboard) This can be done by identifying the commonalities • Distributed systems (for example, client- among members of such families and by designing server, three-tiers, broker) reusable and customizable components to account • Interactive systems (for example, Model-View- for the variability among family members. Controller, Presentation-Abstraction-Control) In object-oriented (OO) programming, a key • Adaptable systems (for example, microker- related notion is that of a framework: a partially nel, reflection) completed software system that can be extended • Others (for example, batch, interpreters, pro- by appropriately instantiating specific extensions cess control, rule-based). (such as plug-ins).

3.3. Design Patterns 4. User Interface Design [15*, c3, c4, c5] User interface design is an essential part of the Succinctly described, a pattern is “a common software design process. User interface design solution to a common problem in a given context” should ensure that interaction between the human [16]. While architectural styles can be viewed as and the machine provides for effective operation 2-6 SWEBOK® Guide V3.0

and control of the machine. For software to and presentation for the software, the background achieve its full potential, the user interface should and experience of the software users, and the be designed to match the skills, experience, and available devices. expectations of its anticipated users. 4.3. The Design of User Interaction Modalities 4.1. General User Interface Design Principles [5*, c29-web] [17*, c2] [5*, c29-web] [17*, c2]1 User interaction involves issuing commands and • Learnability. The software should be easy to providing associated data to the software. User learn so that the user can rapidly start work- interaction styles can be classified into the - fol ing with the software. lowing primary styles: • User familiarity. The interface should use terms and concepts drawn from the experi- • Question-answer. The interaction is essen- ences of the people who will use the software. tially restricted to a single question-answer • Consistency. The interface should be consis- exchange between the user and the software. tent so that comparable operations are acti- The user issues a question to the software, vated in the same way. and the software returns the answer to the • Minimal surprise. The behavior of software question. should not surprise users. • Direct manipulation. Users interact with • Recoverability. The interface should provide objects on the computer screen. Direct mechanisms allowing users to recover from manipulation often includes a pointing errors. device (such as a mouse, trackball, or a fin- • User guidance. The interface should give ger on touch screens) that manipulates an meaningful feedback when errors occur and object and invokes actions that specify what provide context-related help to users. is to be done with that object. • User diversity. The interface should pro- • Menu selection. The user selects a command vide appropriate interaction mechanisms from a menu list of commands. for diverse types of users and for users with • Form fill-in. The user fills in the fields of a different capabilities (blind, poor eyesight, form. Sometimes fields include menus, in deaf, colorblind, etc.). which case the form has action buttons for the user to initiate action. 4.2. User Interface Design Issues • Command language. The user issues a com- [5*, c29-web] [17*, c2] mand and provides related parameters to direct the software what to do. User interface design should solve two key issues: • Natural language. The user issues a command in natural language. That is, the natural • How should the user interact with the language is a front end to a command lan- software? guage and is parsed and translated into soft- • How should information from the software ware commands. be presented to the user? 4.4. The Design of Information Presentation User interface design must integrate user [5*, c29-web] [17*, c2] interaction and information presentation. User interface design should consider a compromise Information presentation may be textual or graphi- between the most appropriate styles of interaction cal in nature. A good design keeps the information presentation separate from the information itself. The MVC (Model-View-Controller) approach is 1 Chapter 29 is a web-based chapter available an effective way to keep information presentation at http://ifs.host.cs.st-andrews.ac.uk/Books/SE9/ separating from the information being presented. WebChapters/. Software Design 2-7

Software engineers also consider software 4.6. Localization and Internationalization response time and feedback in the design of infor- [17*, c8, c9] mation presentation. Response time is generally measured from the point at which a user executes User interface design often needs to consider inter- a certain control action until the software responds nationalization and localization, which are means with a response. An indication of progress is desir- of adapting software to the different languages, able while the software is preparing the response. regional differences, and the technical require- Feedback can be provided by restating the user’s ments of a target market. Internationalization is the input while processing is being completed. process of designing a software application so that Abstract visualizations can be used when large it can be adapted to various languages and regions amounts of information are to be presented. without major engineering changes. Localization According to the style of information presenta- is the process of adapting internationalized soft- tion, designers can also use color to enhance the ware for a specific region or language by adding interface. There are several important guidelines: locale-specific components and translating the text. Localization and internationalization should • Limit the number of colors used. consider factors such as symbols, numbers, cur- • Use color change to show the change of soft- rency, time, and measurement units. ware status. • Use color-coding to support the user’s task. 4.7. Metaphors and Conceptual Models • Use color-coding in a thoughtful and consis- [17*, c5] tent way. • Use colors to facilitate access for people User interface designers can use metaphors and with color blindness or color deficiency conceptual models to set up mappings between the (e.g., use the change of color saturation and software and some reference system known to the color brightness, try to avoid blue and red users in the real world, which can help the users to combinations). more readily learn and use the interface. For exam- • Don’t depend on color alone to convey ple, the operation “delete file” can be made into a important information to users with different metaphor using the icon of a trash can. capabilities (blindness, poor eyesight, color- When designing a user interface, software engi- blindness, etc.). neers should be careful to not use more than one metaphor for each concept. Metaphors also pres- 4.5. User Interface Design Process ent potential problems with respect to internation- [5*, c29-web] [17*, c2] alization, since not all metaphors are meaningful or are applied in the same way within all cultures. User interface design is an iterative process; interface prototypes are often used to determine 5. Software Design Quality Analysis and the features, organization, and look of the soft- Evaluation ware user interface. This process includes three core activities: This section includes a number of quality analysis and evaluation topics that are specifically • User analysis. In this phase, the designer ana- related to software design. (See also the Software lyzes the users’ tasks, the working environ- Quality KA.) ment, other software, and how users interact with other people. 5.1. Quality Attributes • Software prototyping. Developing prototype [4*, c4] software help users to guide the evolution of the interface. Various attributes contribute to the quality of • Interface evaluation. Designers can observe a software design, including various “-ilities” users’ experiences with the evolving interface. (maintainability, portability, testability, usability) 2-8 SWEBOK® Guide V3.0

and “-nesses” (correctness, robustness). There is 5.3. Measures an interesting distinction between quality attri- [4*, c4] [5*, c24] butes discernible at runtime (for example, performance, security, availability, functionality, Measures can be used to assess or to quanti- usability), those not discernible at runtime (for tatively estimate various aspects of a software example, modifiability, portability, reusability, design; for example, size, structure, or quality. testability), and those related to the architecture’s Most measures that have been proposed depend intrinsic qualities (for example, conceptual integ- on the approach used for producing the design. rity, correctness, completeness). (See also the These measures are classified in two broad Software Quality KA.) categories:

5.2. Quality Analysis and Evaluation Techniques • Function-based (structured) design mea- [4*, c4] [5*, c24] sures: measures obtained by analyzing functional decomposition; generally represented Various tools and techniques can help in analyz- using a structure chart (sometimes called a ing and evaluating software design quality. hierarchical diagram) on which various measures can be computed. • Software design reviews: informal and for- • Object-oriented design measures: the design malized techniques to determine the quality structure is typically represented as a class of design artifacts (for example, architecture diagram, on which various measures can be reviews, design reviews, and inspections; computed. Measures on the properties of the scenario-based techniques; requirements internal content of each class can also be tracing). Software design reviews can also computed. evaluate security. Aids for installation, operation, and usage (for example, manuals and 6. Software Design Notations help files) can be reviewed. • Static analysis: formal or semiformal static Many notations exist to represent software design (nonexecutable) analysis that can be used artifacts. Some are used to describe the structural to evaluate a design (for example, fault- organization of a design, others to represent soft- tree analysis or automated cross-checking). ware behavior. Certain notations are used mostly Design vulnerability analysis (for example, during architectural design and others mainly static analysis for security weaknesses) can during detailed design, although some nota- be performed if security is a concern. Formal tions can be used for both purposes. In addition, design analysis uses mathematical models some notations are used mostly in the context of that allow designers to predicate the behavior specific design methods (see topic 7, Software and validate the performance of the software Design Strategies and Methods). Please note that instead of having to rely entirely on testing. software design is often accomplished using mul- Formal design analysis can be used to detect tiple notations. Here, they are categorized into residual specification and design errors (per- notations for describing the structural (static) haps caused by imprecision, ambiguity, and view vs. the behavioral (dynamic) view. sometimes other kinds of mistakes). (See also the Software Engineering Models and 6.1. Structural Descriptions (Static View) Methods KA.) [4*, c7] [5*, c6, c7] [6*, c4, c5, c6, c7] • Simulation and prototyping: dynamic tech- [12*, c7] [14*, c7] niques to evaluate a design (for example, performance simulation or feasibility The following notations, mostly but not always prototypes). graphical, describe and represent the structural aspects of a software design—that is, they are Software Design 2-9

used to describe the major components and how • Activity diagrams: used to show control flow they are interconnected (static view): from activity to activity. Can be used to represent concurrent activities. • Architecture description languages (ADLs): • Communication diagrams: used to show textual, often formal, languages used to the interactions that occur among a group describe software architecture in terms of of objects; emphasis is on the objects, their components and connectors. links, and the messages they exchange on • Class and object diagrams: used to repre- those links. sent a set of classes (and objects) and their • Data flow diagrams (DFDs): used to show interrelationships. data flow among elements. A data flow dia- • Component diagrams: used to represent a gram provides “a description based on model- set of components (“physical and replace- ing the flow of information around a network able part[s] of a system that [conform] to of operational elements, with each element and [provide] the realization of a set of inter- making use of or modifying the information faces” [18]) and their interrelationships. flowing into that element” [4*]. Data flows • Class responsibility collaborator cards (and therefore data flow diagrams) can be (CRCs): used to denote the names of compo- used for security analysis, as they offer iden- nents (class), their responsibilities, and their tification of possible paths for attack and dis- collaborating components’ names. closure of confidential information. • Deployment diagrams: used to represent a • Decision tables and diagrams: used to rep- set of (physical) nodes and their interrela- resent complex combinations of conditions tionships, and, thus, to model the physical and actions. aspects of software. • Flowcharts: used to represent the flow of • Entity-relationship diagrams (ERDs): used control and the associated actions to be to represent conceptual models of data stored performed. in information repositories. • Sequence diagrams: used to show the inter- • Interface description languages (IDLs): actions among a group of objects, with programming-like languages used to define emphasis on the time ordering of messages the interfaces (names and types of exported passed between objects. operations) of software components. • State transition and state chart diagrams: • Structure charts: used to describe the calling used to show the control flow from state to structure of programs (which modules call, state and how the behavior of a component and are called by, which other modules). changes based on its current state in a state machine. 6.2. Behavioral Descriptions (Dynamic View) • Formal specification languages: textual lan- [4*, c7, c13] [5*, c6, c7] [6*, c4, c5, c6, c7] guages that use basic notions from math- [14*, c8] ematics (for example, logic, set, sequence) to rigorously and abstractly define software The following notations and languages, some component interfaces and behavior, often in graphical and some textual, are used to describe terms of pre- and postconditions. (See also the dynamic behavior of software systems and the Software Engineering Models and Meth- components. Many of these notations are use- ods KA.) ful mostly, but not exclusively, during detailed • Pseudo code and program design languages design. Moreover, behavioral descriptions can (PDLs): structured programming-like lan- include a rationale for design decision such as guages used to describe, generally at the how a design will meet security requirements. detailed design stage, the behavior of a procedure or method. 2-10 SWEBOK® Guide V3.0

7. Software Design Strategies and Methods design of the mid-1980s (noun = object; verb = method; adjective = attribute), where inheri- There exist various general strategies to help tance and polymorphism play a key role, to the guide the design process. In contrast with general field of component-based design, where metain- strategies, methods are more specific in that they formation can be defined and accessed (through generally provide a set of notations to be used reflection, for example). Although OO design’s with the method, a description of the process to roots stem from the concept of data abstraction, be used when following the method, and a set of responsibility-driven design has been proposed guidelines for using the method. Such methods as an alternative approach to OO design. are useful as a common framework for teams of software engineers. (See also the Software Engi- 7.4. Data Structure-Centered Design neering Models and Methods KA). [4*, c14, c15]

7.1. General Strategies Data structure-centered design starts from the data [4*, c8, c9, c10] [12*, c7] structures a program manipulates rather than from the function it performs. The software engineer Some often-cited examples of general strategies first describes the input and output data structures useful in the design process include the divide- and then develops the program’s control structure and-conquer and stepwise refinement strategies, based on these data structure diagrams. Various top-down vs. bottom-up strategies, and strategies heuristics have been proposed to deal with special making use of heuristics, use of patterns and pat- cases—for example, when there is a mismatch tern languages, and use of an iterative and incre- between the input and output structures. mental approach. 7.5. Component-Based Design (CBD) 7.2. Function-Oriented (Structured) Design [4*, c17] [4*, c13] A software component is an independent unit, This is one of the classical methods of software having well-defined interfaces and dependen- design, where decomposition centers on identify- cies that can be composed and deployed inde- ing the major software functions and then elab- pendently. Component-based design addresses orating and refining them in a hierarchical top- issues related to providing, developing, and down manner. Structured design is generally used integrating such components in order to improve after structured analysis, thus producing (among reuse. Reused and off-the-shelf software com- other things) data flow diagrams and associated ponents should meet the same security require- process descriptions. Researchers have proposed ments as new software. Trust management is various strategies (for example, transformation a design concern; components treated as hav- analysis, transaction analysis) and heuristics (for ing a certain degree of trustworthiness should example, fan-in/fan-out, scope of effect vs. scope not depend on less trustworthy components or of control) to transform a DFD into a software services. architecture generally represented as a structure chart. 7.6. Other Methods [5*, c19, c21] 7.3. Object-Oriented Design [4*, c16] Other interesting approaches also exist (see the Software Engineering Models and Methods Numerous software design methods based KA). Iterative and adaptive methods imple- on objects have been proposed. The field has ment software increments and reduce emphasis evolved from the early object-oriented (OO) on rigorous software requirement and design. Software Design 2-11

Aspect-oriented design is a method by which 8. Software Design Tools software is constructed using aspects to imple- [14*, c10, Appendix A] ment the crosscutting concerns and extensions that are identified during the software require- Software design tools can be used to support the ments process. Service-oriented architecture is creation of the software design artifacts during a way to build distributed software using web the software development process. They can sup- services executed on distributed computers. Soft- port part or whole of the following activities: ware systems are often constructed by using services from different providers because standard • to translate the requirements model into a protocols (such as HTTP, HTTPS, SOAP) have design representation; been designed to support service communication • to provide support for representing func- and service information exchange. tional components and their interface(s); • to implement heuristics refinement and partitioning; • to provide guidelines for quality assessment. 2-12 SWEBOK® Guide V3.0

MATRIX OF TOPICS VS. REFERENCE MATERIAL [4*] [6*] [5*] [14*] [17*] [15*] [13*] [12*] Allen 2008 Nielsen 1993 Budgen 2003Budgen Page-Jones 1999 Brookshear 2008 Sommerville 2011 Gamma et al. 1994 Gamma et al. 1994 Clements et al. 2010 Clements et al. 2010 1. Software Design Fundamentals 1.1. General Design c1 Concepts 1.2. The Context of c3 Software Design 1.3. The Software c2 Design Process 1.4. Software Design c6, c7, c1, c8, c1 Principles c21 c9 2. Key Issues in Software Design 2.1. Concurrency c18 2.2. Control and c21 Handling of Events 2.3. Data Persistence c9 2.4. Distribution of c18 Components 2.5. Error and Exception Handling c18 and Fault Tolerance 2.6. Interaction and c16 Presentation c12, 2.7. Security c4 c18 3. Software Structure and Architecture 3.1. Architectural Structures and c1 Viewpoints c1, c2, 3.2. Architectural c3, c4, Styles c5 c3, c4, 3.3. Design Patterns c5 Software Design 2-13 [4*] [6*] [5*] [14*] [17*] [15*] [13*] [12*] Allen 2008 Nielsen 1993 Budgen 2003Budgen Page-Jones 1999 Brookshear 2008 Sommerville 2011 Gamma et al. 1994 Gamma et al. 1994 Clements et al. 2010 Clements et al. 2010

3.4. Architecture c6 Design Decisions 3.5. Families of c6, c7, Programs and c16 Frameworks 4. User Interface Design 4.1. General User c29- Interface Design c2 web Principle 4.2. User Interface c29- Design Issues web 4.3. The Design of c29- User Interaction web Modalities 4.4. The Design c29- of Information web Presentation 4.5. User Interface c29- Design Process web 4.6. Localization and c8, c9 Internationalization 4.7. Metaphors and c5 Conceptual Models 5. Software Design Quality Analysis and Evaluation 5.1. Quality c4 Attributes 5.2. Quality Analysis and c4 c24 Evaluation Techniques 5.3. Measures c4 c24 2-14 SWEBOK® Guide V3.0 [4*] [6*] [5*] [14*] [17*] [15*] [13*] [12*] Allen 2008 Nielsen 1993 Budgen 2003Budgen Page-Jones 1999 Brookshear 2008 Sommerville 2011 Gamma et al. 1994 Gamma et al. 1994 Clements et al. 2010 Clements et al. 2010 6. Software Design Notations 6.1. Structural c4, c5, Descriptions (Static c7 c6, c7 c7 c7 c6, c7 View) 6.2. Behavioral c7, c13, c4, c5, Descriptions c6, c7 c8 c18 c6, c7 (Dynamic View) 7. Software Design Strategies and Methods 7.1. General c8, c9, c7 Strategies c10 7.2. Function- Oriented c13 (Structured) Design 7.3. Object-Oriented c16 Design 7.4. Data Structure- c14, Centered Design c15 7.5. Component- c17 Based Design (CBD) c19, 7.6. Other Methods c21 8. Software Design c10, Tools App. A Software Design 2-15

FURTHER READINGS REFERENCES

Roger Pressman, Software Engineering: A [1] ISO/IEC/IEEE 24765:2010 Systems and Practitioner’s Approach (Seventh Edition) Software Engineering—Vocabulary, ISO/ [19]. IEC/IEEE, 2010.

For roughly three decades, Roger Pressman’s [2] IEEE Std. 12207-2008 (a.k.a. ISO/IEC Software Engineering: A Practitioner’s Approach 12207:2008) Standard for Systems and has been one of the world’s leading textbooks in Software Engineering—Software Life Cycle software engineering. Notably, this complemen- Processes, IEEE, 2008. tary textbook to [5*] comprehensively presents software design—including design concepts, [3] T. DeMarco, “The Paradox of Software architectural design, component-level design, Architecture and Design,” Stevens Prize user interface design, pattern-based design, and Lecture, 1999. web application design. [4*] D. Budgen, Software Design, 2nd ed., “The 4+1 View Model of Architecture” [20]. Addison-Wesley, 2003.

The seminal paper “The 4+1 View Model” orga- [5*] I. Sommerville, Software Engineering, 9th nizes a description of a software architecture ed., Addison-Wesley, 2011. using five concurrent views. The four views of the model are the logical view, the development [6*] M. Page-Jones, Fundamentals of Object- view, the process view, and the physical view. Oriented Design in UML, 1st ed., Addison- In addition, selected use cases or scenarios are Wesley, 1999. utilized to illustrate the architecture. Hence, the model contains 4+1 views. The views are used to [7] Merriam-Webster’s Collegiate Dictionary, describe the software as envisioned by different 11th ed., 2003. stakeholders—such as end-users, developers, and project managers. [8] IEEE Std. 1069-2009 Standard for Information Technology—Systems Len Bass, Paul Clements, and Rick Kazman, Design—Software Design Descriptions, Software Architecture in Practice [21]. IEEE, 2009.

This book introduces the concepts and best prac- [9] ISO/IEC 42010:2011 Systems and Software tices of software architecture, meaning how soft- Engineering—Recommended Practice for ware is structured and how the software’s compo- Architectural Description of Software- nents interact. Drawing on their own experience, Intensive Systems, ISO/IEC, 2011. the authors cover the essential technical topics for designing, specifying, and validating software [10] J. Bosch, Design and Use of Software architectures. They also emphasize the impor- Architectures: Adopting and Evolving a tance of the business context in which large soft- Product-Line Approach, ACM Press, 2000. ware is designed. Their aim is to present software architecture in a real-world setting, reflecting [11] G. Kiczales et al., “Aspect-Oriented both the opportunities and constraints that orga- Programming,” Proc. 11th European Conf. nizations encounter. This is one of the best books Object-Oriented Programming (ECOOP currently available on software architecture. 97), Springer, 1997. 2-16 SWEBOK® Guide V3.0

[12*] J.G. Brookshear, Computer Science: An [17*] J. Nielsen, Usability Engineering, Morgan Overview, 10th ed., Addison-Wesley, 2008. Kaufmann, 1993.

[13*] J.H. Allen et al., Software Security [18] G. Booch, J. Rumbaugh, and I. Jacobson, Engineering: A Guide for Project The Unified Modeling Language User Managers, Addison-Wesley, 2008. Guide, Addison-Wesley, 1999.

[14*] P. Clements et al., Documenting Software [19] R.S. Pressman, Software Engineering: A Architectures: Views and Beyond, 2nd ed., Practitioner’s Approach, 7th ed., McGraw- Pearson Education, 2010. Hill, 2010.

[15*] E. Gamma et al., Design Patterns: [20] P.B. Kruchten, “The 4+1 View Model of Elements of Reusable Object-Oriented Architecture,” IEEE Software, vol. 12, no. Software, 1st ed., Addison-Wesley 6, 1995, pp. 42–55. Professional, 1994. [21] L. Bass, P. Clements, and R. Kazman, [16] I. Jacobson, G. Booch, and J. Rumbaugh, Software Architecture in Practice, 3rd ed., The Unified Software Development Addison-Wesley Professional, 2013. Process, Addison-Wesley Professional, 1999. CHAPTER 3

SOFTWARE CONSTRUCTION

ACRONYMS Thus, the Software Construction KA is closely linked to the Software Testing KA as well. Application Programming API Software construction typically produces the Interface highest number of configuration items that need COTS Commercial Off-the-Shelf to be managed in a software project (source files, GUI Graphical User Interface documentation, test cases, and so on). Thus, the Integrated Development Software Construction KA is also closely linked IDE Environment to the Software Configuration Management KA. While software quality is important in all the OMG Object Management Group KAs, code is the ultimate deliverable of a soft- Portable Operating System POSIX ware project, and thus the Software Quality KA is Interface closely linked to the Software Construction KA. TDD Test-Driven Development Since software construction requires knowledge UML Unified Modeling Language of algorithms and of coding practices, it is closely related to the Computing Foundations KA, which is concerned with the computer science founda- INTRODUCTION tions that support the design and construction of software products. It is also related to project man- The term software construction refers to the agement, insofar as the management of construc- detailed creation of working software through a tion can present considerable challenges. combination of coding, verification, unit testing, integration testing, and debugging. BREAKDOWN OF TOPICS FOR The Software Construction knowledge area SOFTWARE CONSTRUCTION (KA) is linked to all the other KAs, but it is most strongly linked to Software Design and Software Figure 3.1 gives a graphical representation of the Testing because the software construction process top-level decomposition of the breakdown for the involves significant software design and testing. Software Construction KA. The process uses the design output and provides an input to testing (“design” and “testing” in this case 1. Software Construction Fundamentals referring to the activities, not the KAs). Boundar- ies between design, construction, and testing (if Software construction fundamentals include any) will vary depending on the software life cycle processes that are used in a project. • minimizing complexity Although some detailed design may be per- • anticipating change formed prior to construction, much design work • constructing for verification is performed during the construction activity. • reuse Thus, the Software Construction KA is closely • standards in construction. linked to the Software Design KA. Throughout construction, software engineers The first four concepts apply to design as well both unit test and integration test their work. as to construction. The following sections define

3-1 3-2 SWEBOK® Guide V3.0

Figure 3.1. Breakdown of Topics for the Software Construction KA Software Construction 3-3

these concepts and describe how they apply to independent testing and operational activities. construction. Specific techniques that support constructing for verification include following coding standards to 1.1. Minimizing Complexity support code reviews and unit testing, organizing [1*] code to support automated testing, and restrict- ing the use of complex or hard-to-understand lan- Most people are limited in their ability to hold guage structures, among others. complex structures and information in their working memories, especially over long peri- 1.4. Reuse ods of time. This proves to be a major factor [2*] influencing how people convey intent -to com puters and leads to one of the strongest drives Reuse refers to using existing assets in solving in software construction: minimizing complex- different problems. In software construction, typ- ity. The need to reduce complexity applies to ical assets that are reused include libraries, mod- essentially every aspect of software construction ules, components, source code, and commercial and is particularly critical to testing of software off-the-shelf (COTS) assets. Reuse is best prac- constructions. ticed systematically, according to a well-defined, In software construction, reduced complexity repeatable process. Systematic reuse can enable is achieved through emphasizing code creation significant software productivity, quality, and that is simple and readable rather than clever. It cost improvements. is accomplished through making use of standards Reuse has two closely related facets: “construc- (see section 1.5, Standards in Construction), tion for reuse” and “construction with reuse.” The modular design (see section 3.1, Construction former means to create reusable software assets, Design), and numerous other specific techniques while the latter means to reuse software assets in (see section 3.3, Coding). It is also supported by the construction of a new solution. Reuse often construction-focused quality techniques (see sec- transcends the boundary of projects, which means tion 3.7, Construction Quality). reused assets can be constructed in other projects or organizations. 1.2. Anticipating Change [1*] 1.5. Standards in Construction [1*] Most software will change over time, and the anticipation of change drives many aspects of Applying external or internal development stan- software construction; changes in the environ- dards during construction helps achieve a proj- ments in which software operates also affect soft- ect’s objectives for efficiency, quality, and cost. ware in diverse ways. Specifically, the choices of allowable program- Anticipating change helps software engineers ming language subsets and usage standards are build extensible software, which means they can important aids in achieving higher security. enhance a software product without disrupting Standards that directly affect construction the underlying structure. issues include Anticipating change is supported by many specific techniques (see section 3.3, Coding). • communication methods (for example, standards for document formats and contents) 1.3. Constructing for Verification • programming languages (for example, lan- [1*] guage standards for languages like Java and C++) Constructing for verification means building • coding standards (for example, standards for software in such a way that faults can be read- naming conventions, layout, and indentation) ily found by the software engineers writing the • platforms (for example, interface standards software as well as by the testers and users during for operating system calls) 3-4 SWEBOK® Guide V3.0

• tools (for example, diagrammatic standards the Software Management and Software Process for notations like UML (Unified Modeling KAs). Language)). Consequently, what is considered to be “construction” depends to some degree on the life Use of external standards. Construction cycle model used. In general, software con- depends on the use of external standards for construction is mostly coding and debugging, but struction languages, construction tools, technical it also involves construction planning, detailed interfaces, and interactions between the Software design, unit testing, integration testing, and other Construction KA and other KAs. Standards come activities. from numerous sources, including hardware and software interface specifications (such as the 2.2. Construction Planning Object Management Group (OMG)) and interna- [1*] tional organizations (such as the IEEE or ISO). Use of internal standards. Standards may also The choice of construction method is a key aspect be created on an organizational basis at the cor- of the construction-planning activity. The choice porate level or for use on specific projects. These of construction method affects the extent to standards support coordination of group activi- which construction prerequisites are performed, ties, minimizing complexity, anticipating change, the order in which they are performed, and the and constructing for verification. degree to which they should be completed before construction work begins. 2. Managing Construction The approach to construction affects the project team’s ability to reduce complexity, anticipate 2.1. Construction in Life Cycle Models change, and construct for verification. Each of [1*] these objectives may also be addressed at the process, requirements, and design levels—but they Numerous models have been created to develop will be influenced by the choice of construction software; some emphasize construction more method. than others. Construction planning also defines the order Some models are more linear from the con- in which components are created and integrated, struction point of view—such as the waterfall and the integration strategy (for example, phased or staged-delivery life cycle models. These models incremental integration), the software quality treat construction as an activity that occurs only management processes, the allocation of task after significant prerequisite work has been com- assignments to specific software engineers, and pleted—including detailed requirements work, other tasks, according to the chosen method. extensive design work, and detailed planning. The more linear approaches tend to emphasize 2.3. Construction Measurement the activities that precede construction (require- [1*] ments and design) and to create more distinct sep- arations between activities. In these models, the Numerous construction activities and artifacts can main emphasis of construction may be coding. be measured—including code developed, code Other models are more iterative—such as modified, code reused, code destroyed, code com- evolutionary prototyping and agile develop- plexity, code inspection statistics, fault-fix and ment. These approaches tend to treat construc- fault-find rates, effort, and scheduling. These mea- tion as an activity that occurs concurrently with surements can be useful for purposes of managing other software development activities (including construction, ensuring quality during construction, requirements, design, and planning) or that over- and improving the construction process, among laps them. These approaches tend to mix design, other uses (see the Software Engineering Process coding, and testing activities, and they often treat KA for more on measurement). the combination of activities as construction (see Software Construction 3-5

3. Practical Considerations installations. The text-based configuration files used in both the Windows and Unix operating Construction is an activity in which the software systems are examples of this, and the menu-style engineer has to deal with sometimes chaotic and selection lists of some program generators consti- changing real-world constraints, and he or she tute another example of a configuration language. must do so precisely. Due to the influence of real- Toolkit languages are used to build applica- world constraints, construction is more driven by tions out of elements in toolkits (integrated sets practical considerations than some other KAs, of application-specific reusable parts); they are and software engineering is perhaps most craft- more complex than configuration languages. like in the construction activities. Toolkit languages may be explicitly defined as application programming languages, or the appli- 3.1. Construction Design cations may simply be implied by a toolkit’s set [1*] of interfaces. Scripting languages are commonly used kinds Some projects allocate considerable design activ- of application programming languages. In some ity to construction, while others allocate design scripting languages, scripts are called batch files to a phase explicitly focused on design. Regard- or macros. less of the exact allocation, some detailed design Programming languages are the most flexible work will occur at the construction level, and that type of construction languages. They also contain design work tends to be dictated by constraints the least amount of information about specific imposed by the real-world problem that is being application areas and development processes— addressed by the software. therefore, they require the most training and skill Just as construction workers building a physi- to use effectively. The choice of programming lan- cal structure must make small-scale modifica- guage can have a large effect on the likelihood of tions to account for unanticipated gaps in the vulnerabilities being introduced during coding— builder’s plans, software construction workers for example, uncritical usage of C and C++ are must make modifications on a smaller or larger questionable choices from a security viewpoint. scale to flesh out details of the software design There are three general kinds of notation used during construction. for programming languages, namely The details of the design activity at the construction level are essentially the same as described in • linguistic (e.g., C/C++, Java) the Software Design KA, but they are applied on • formal (e.g., Event-B) a smaller scale of algorithms, data structures, and • visual (e.g., MatLab). interfaces. Linguistic notations are distinguished in par- 3.2. Construction Languages ticular by the use of textual strings to represent [1*] complex software constructions. The combina- Construction languages include all forms of tion of textual strings into patterns may have a communication by which a human can specify an sentence-like syntax. Properly used, each such executable problem solution to a problem. Con- string should have a strong semantic connotation struction languages and their implementations providing an immediate intuitive understanding (for example, compilers) can affect software of what will happen when the software construc- quality attributes of performance, reliability, portion is executed. tability, and so forth. They can be serious con- Formal notations rely less on intuitive, every- tributors to security vulnerabilities. day meanings of words and text strings and more The simplest type of construction language on definitions backed up by precise, unambigu- is a configuration language, in which software ous, and formal (or mathematical) definitions. engineers choose from a limited set of pre- Formal construction notations and formal meth- defined options to create new or custom software ods are at the semantic base of most forms of 3-6 SWEBOK® Guide V3.0

system programming notations, where accuracy, 3.4. Construction Testing time behavior, and testability are more important [1*] than ease of mapping into natural language. For- mal constructions also use precisely defined ways Construction involves two forms of testing, of combining symbols that avoid the ambiguity which are often performed by the software engi- of many natural language constructions. neer who wrote the code: Visual notations rely much less on the textual notations of linguistic and formal construction • Unit testing and instead rely on direct visual interpretation • Integration testing. and placement of visual entities that represent the underlying software. Visual construction tends to The purpose of construction testing is to reduce be somewhat limited by the difficulty of making the gap between the time when faults are inserted “complex” statements using only the arrange- into the code and the time when those faults are ment of icons on a display. However, these icons detected, thereby reducing the cost incurred to can be powerful tools in cases where the primary fix them. In some instances, test cases are writ- programming task is simply to build and “adjust” ten after code has been written. In other instances, a visual interface to a program, the detailed test cases may be created before code is written. behavior of which has an underlying definition. Construction testing typically involves a subset of the various types of testing, which 3.3. Coding are described in the Software Testing KA. For [1*] instance, construction testing does not typically include system testing, alpha testing, beta testing, The following considerations apply to the soft- stress testing, configuration testing, usability test- ware construction coding activity: ing, or other more specialized kinds of testing. Two standards have been published on the topic • Techniques for creating understandable of construction testing: IEEE Standard 829-1998, source code, including naming conventions IEEE Standard for Software Test Documentation, and source code layout; and IEEE Standard 1008-1987, IEEE Standard • Use of classes, enumerated types, variables, for Software Unit Testing. named constants, and other similar entities; (See sections 2.1.1., Unit Testing, and 2.1.2., • Use of control structures; Integration Testing, in the Software Testing KA • Handling of error conditions—both antici- for more specialized reference material.) pated and exceptional (input of bad data, for example); 3.5. Construction for Reuse • Prevention of code-level security breaches [2*] (buffer overflows or array index bounds, for example); Construction for reuse creates software that has • Resource usage via use of exclusion mecha- the potential to be reused in the future for the nisms and discipline in accessing serially present project or other projects taking a broad- reusable resources (including threads and based, multisystem perspective. Construction for database locks); reuse is usually based on variability analysis and • Source code organization (into state- design. To avoid the problem of code clones, it ments, routines, classes, packages, or other is desired to encapsulate reusable code fragments structures); into well-structured libraries or components. • Code documentation; The tasks related to software construction for • Code tuning, reuse during coding and testing are as follows: Software Construction 3-7

• Variability implementation with mecha- • unit testing and integration testing (see sec- nisms such as parameterization, conditional tion 3.4, Construction Testing) compilation, design patterns, and so forth. • test-first development (see section 2.2 in the • Variability encapsulation to make the soft- Software Testing KA) ware assets easy to configure and customize. • use of assertions and defensive programming • Testing the variability provided by the reus- • debugging able software assets. • inspections • Description and publication of reusable soft- • technical reviews, including security-ori- ware assets. ented reviews (see section 2.3.2 in the Soft- ware Quality KA) 3.6. Construction with Reuse • static analysis (see section 2.3 of the Soft- [2*] ware Quality KA)

Construction with reuse means to create new The specific technique or techniques selected software with the reuse of existing software depend on the nature of the software being con- assets. The most popular method of reuse is to structed as well as on the skillset of the software reuse code from the libraries provided by the lan- engineers performing the construction activi- guage, platform, tools being used, or an organiza- ties. Programmers should know good practices tional repository. Asides from these, the applica- and common vulnerabilities—for example, from tions developed today widely make use of many widely recognized lists about common vulner- open-source libraries. Reused and off-the-shelf abilities. Automated static analysis of code for software often have the same—or better—quality security weaknesses is available for several com- requirements as newly developed software (for mon programming languages and can be used in example, security level). security-critical projects. The tasks related to software construction with Construction quality activities are differenti- reuse during coding and testing are as follows: ated from other quality activities by their focus. Construction quality activities focus on code and • The selection of the reusable units, data- artifacts that are closely related to code—such bases, test procedures, or test data. as detailed design—as opposed to other artifacts • The evaluation of code or test reusability. that are less directly connected to the code, such • The integration of reusable software assets as requirements, high-level designs, and plans. into the current software. • The reporting of reuse information on new 3.8. Integration code, test procedures, or test data. [1*]

3.7. Construction Quality A key activity during construction is the integra- [1*] tion of individually constructed routines, classes, components, and subsystems into a single sys- In addition to faults resulting from requirements tem. In addition, a particular software system and design, faults introduced during construction may need to be integrated with other software or can result in serious quality problems—for exam- hardware systems. ple, security vulnerabilities. This includes not Concerns related to construction integration only faults in security functionality but also faults include planning the sequence in which compo- elsewhere that allow bypassing of this functional- nents will be integrated, identifying what hard- ity and other security weaknesses or violations. ware is needed, creating scaffolding to support Numerous techniques exist to ensure the qual- interim versions of the software, determining ity of code as it is constructed. The primary tech- the degree of testing and quality work performed niques used for construction quality include on components before they are integrated, and 3-8 SWEBOK® Guide V3.0

determining points in the project at which interim 4.2. Object-Oriented Runtime Issues versions of the software are tested. [1*] Programs can be integrated by means of either the phased or the incremental approach. Phased Object-oriented languages support a series of integration, also called “big bang” integration, runtime mechanisms including polymorphism entails delaying the integration of component and reflection. These runtime mechanisms software parts until all parts intended for release increase the flexibility and adaptability of object- in a version are complete. Incremental integration oriented programs. Polymorphism is the ability is thought to offer many advantages over the tra- of a language to support general operations with- ditional phased integration—for example, easier out knowing until runtime what kind of concrete error location, improved progress monitoring, objects the software will include. Because the earlier product delivery, and improved customer program does not know the exact types of the relations. In incremental integration, the develop- objects in advance, the exact behaviour is deter- ers write and test a program in small pieces and mined at runtime (called dynamic binding). then combine the pieces one at a time. Additional Reflection is the ability of a program to observe test infrastructure, such as stubs, drivers, and and modify its own structure and behavior at run- mock objects, are usually needed to enable incre- time. Reflection allows inspection of classes, mental integration. By building and integrating interfaces, fields, and methods at runtime - with one unit at a time (for example, a class or compo- out knowing their names at compile time. It also nent), the construction process can provide early allows instantiation at runtime of new objects and feedback to developers and customers. Other invocation of methods using parameterized class advantages of incremental integration include and method names. easier error location, improved progress monitoring, more fully tested units, and so forth. 4.3. Parameterization and Generics [4*] 4. Construction Technologies Parameterized types, also known as generics 4.1. API Design and Use (Ada, Eiffel) and templates (C++), enable the [3*] definition of a type or class without specifying all the other types it uses. The unspecified types are An application programming interface (API) is the supplied as parameters at the point of use. Param- set of signatures that are exported and available to eterized types provide a third way (in addition to the users of a library or a framework to write their class inheritance and object composition) to com- applications. Besides signatures, an API should pose behaviors in object-oriented software. always include statements about the program’s effects and/or behaviors (i.e., its semantics). 4.4. Assertions, Design by Contract, and Defensive API design should try to make the API easy Programming to learn and memorize, lead to readable code, be [1*] hard to misuse, be easy to extend, be complete, and maintain backward compatibility. As the An assertion is an executable predicate that’s APIs usually outlast their implementations for placed in a program—usually a routine or macro— a widely used library or framework, it is desired that allows runtime checks of the program. Asser- that the API be straightforward and kept stable to tions are especially useful in high-reliability pro- facilitate the development and maintenance of the grams. They enable programmers to more quickly client applications. flush out mismatched interface assumptions, errors API use involves the processes of select- that creep in when code is modified, and so on. ing, learning, testing, integrating, and possibly Assertions are normally compiled into the code at extending APIs provided by a library or frame- development time and are later compiled out of the work (see section 3.6, Construction with Reuse). code so that they don’t degrade the performance. Software Construction 3-9

Design by contract is a development approach or containing their effects if recovery is not pos- in which preconditions and postconditions are sible. The most common fault tolerance strategies included for each routine. When preconditions include backing up and retrying, using auxiliary and postconditions are used, each routine or code, using voting algorithms, and replacing an class is said to form a contract with the rest of erroneous value with a phony value that will have the program. Furthermore, a contract provides a a benign effect. precise specification of the semantics of a routine, and thus helps the understanding of its behavior. 4.6. Executable Models Design by contract is thought to improve the [5*] quality of software construction. Defensive programming means to protect a Executable models abstract away the details of routine from being broken by invalid inputs. specific programming languages and decisions Common ways to handle invalid inputs include about the organization of the software. Different checking the values of all the input parameters from traditional software models, a specification and deciding how to handle bad inputs. Asser- built in an executable modeling language like tions are often used in defensive programming to xUML (executable UML) can be deployed in check input values. various software environments without change. An executable-model compiler (transformer) can 4.5. Error Handling, Exception Handling, and turn an executable model into an implementation Fault Tolerance using a set of decisions about the target hardware [1*] and software environment. Thus, constructing executable models can be regarded as a way of The way that errors are handled affects software’s constructing executable software. ability to meet requirements related to correct- Executable models are one foundation support- ness, robustness, and other nonfunctional attri- ing the Model-Driven Architecture (MDA) initia- butes. Assertions are sometimes used to check tive of the Object Management Group (OMG). An for errors. Other error handling techniques—such executable model is a way to completely specify as returning a neutral value, substituting the next a Platform Independent Model (PIM); a PIM is piece of valid data, logging a warning message, a model of a solution to a problem that does not returning an error code, or shutting down the soft- rely on any implementation technologies. Then ware—are also used. a Platform Specific Model (PSM), which is a Exceptions are used to detect and process model that contains the details of the implemen- errors or exceptional events. The basic structure tation, can be produced by weaving together the of an exception is that a routine uses throw to PIM and the platform on which it relies. throw a detected exception and an exception handling block will catch the exception in a try-catch 4.7. State-Based and Table-Driven Construction block. The try-catch block may process the erro- Techniques neous condition in the routine or it may return [1*] control to the calling routine. Exception handling policies should be carefully designed follow- State-based programming, or automata-based ing common principles such as including in the programming, is a programming technology exception message all information that led to the using finite state machines to describe program exception, avoiding empty catch blocks, knowing behaviours. The transition graphs of a state the exceptions the library code throws, perhaps machine are used in all stages of software devel- building a centralized exception reporter, and opment (specification, implementation, debug- standardizing the program’s use of exceptions. ging, and documentation). The main idea is to Fault tolerance is a collection of techniques construct computer programs the same way the that increase software reliability by detecting automation of technological processes is done. errors and then recovering from them if possible State-based programming is usually combined 3-10 SWEBOK® Guide V3.0

with object-oriented programming, forming a programmer-defined variables that populate the new composite approach called state-based, tree. After building the parse tree, the program object-oriented programming. uses it as input to the computational processes. A table-driven method is a schema that uses tables to look up information rather than using 4.10. Concurrency Primitives logic statements (such as if and case). Used in [7*] appropriate circumstances, table-driven code is simpler than complicated logic and easier to A synchronization primitive is a programming modify. When using table-driven methods, the abstraction provided by a programming language programmer addresses two issues: what informa- or the operating system that facilitates concur- tion to store in the table or tables, and how to effi- rency and synchronization. Well-known concur- ciently access information in the table. rency primitives include semaphores, monitors, and mutexes. 4.8. Runtime Configuration and A semaphore is a protected variable or abstract Internationalization data type that provides a simple but useful abstrac- [1*] tion for controlling access to a common resource by multiple processes or threads in a concurrent To achieve more flexibility, a program is often programming environment. constructed to support late binding time of its vari- A monitor is an abstract data type that presents ables. Runtime configuration is a technique that a set of programmer-defined operations that are binds variable values and program settings when executed with mutual exclusion. A monitor con- the program is running, usually by updating and tains the declaration of shared variables and pro- reading configuration files in a just-in-time mode. cedures or functions that operate on those vari- Internationalization is the technical activ- ables. The monitor construct ensures that only ity of preparing a program, usually interactive one process at a time is active within the monitor. software, to support multiple locales. The corre- A mutex (mutual exclusion) is a synchroniza- sponding activity, localization, is the activity of tion primitive that grants exclusive access to a modifying a program to support a specific local shared resource by only one process or thread at language. Interactive software may contain doz- a time. ens or hundreds of prompts, status displays, help messages, error messages, and so on. The design 4.11. Middleware and construction processes should accommodate [3*] [6*] string and character-set issues including which character set is to be used, what kinds of strings Middleware is a broad classification for soft- are used, how to maintain the strings without ware that provides services above the operating changing the code, and translating the strings into system layer yet below the application program different languages with minimal impact on the layer. Middleware can provide runtime contain- processing code and the user interface. ers for software components to provide message passing, persistence, and a transparent location 4.9. Grammar-Based Input Processing across a network. Middleware can be viewed as [1*] [6*] a connector between the components that use the middleware. Modern message-oriented middle- Grammar-based input processing involves syntax ware usually provides an Enterprise Service Bus analysis, or parsing, of the input token stream. It (ESB), which supports service-oriented interac- involves the creation of a data structure (called a tion and communication between multiple soft- parse tree or syntax tree) representing the input ware applications. data. The inorder traversal of the parse tree usually gives the expression just parsed. The parser checks the symbol table for the presence of Software Construction 3-11

4.12. Construction Methods for Distributed algorithm selection—influences an execution Software speed and size. Performance analysis is the inves- [7*] tigation of a program’s behavior using information gathered as the program executes, with the A distributed system is a collection of physically goal of identifying possible hot spots in the pro- separate, possibly heterogeneous computer sys- gram to be improved. tems that are networked to provide the users with Code tuning, which improves performance at access to the various resources that the system the code level, is the practice of modifying correct maintains. Construction of distributed software is code in ways that make it run more efficiently. distinguished from traditional software construc- Code tuning usually involves only small-scale tion by issues such as parallelism, communica- changes that affect a single class, a single routine, tion, and fault tolerance. or, more commonly, a few lines of code. A rich Distributed programming typically falls into one set of code tuning techniques is available, includ- of several basic architectural categories: client- ing those for tuning logic expressions, loops, data server, 3-tier architecture, n-tier architecture, dis- transformations, expressions, and routines. Using tributed objects, loose coupling, or tight coupling a low-level language is another common tech- (see section 14.3 of the Computing Foundations nique for improving some hot spots in a program. KA and section 3.2 of the Software Design KA). 4.15. Platform Standards 4.13. Constructing Heterogeneous Systems [6*] [7*] [6*] Platform standards enable programmers to Heterogeneous systems consist of a variety of develop portable applications that can be exe- specialized computational units of different types, cuted in compatible environments without such as Digital Signal Processors (DSPs), micro- changes. Platform standards usually involve a controllers, and peripheral processors. These set of standard services and APIs that compat- computational units are independently controlled ible platform implementations must implement. and communicate with one another. Embedded Typical examples of platform standards are Java systems are typically heterogeneous systems. 2 Platform Enterprise Edition (J2EE) and the The design of heterogeneous systems may POSIX standard for operating systems (Portable require the combination of several specification Operating System Interface), which represents languages in order to design different parts of a set of standards implemented primarily for the system—in other words, hardware/software UNIX-based operating systems. codesign. The key issues include multilanguage validation, cosimulation, and interfacing. 4.16. Test-First Programming During the hardware/software codesign, soft- [1*] ware development and virtual hardware development proceed concurrently through stepwise Test-first programming (also known as Test- decomposition. The hardware part is usually Driven Development—TDD) is a popular devel- simulated in field programmable gate arrays opment style in which test cases are written prior (FPGAs) or application-specific integrated -cir to writing any code. Test-first programming can cuits (ASICs). The software part is translated into usually detect defects earlier and correct them a low-level programming language. more easily than traditional programming styles. Furthermore, writing test cases first forces pro- 4.14. Performance Analysis and Tuning grammers to think about requirements and design [1*] before coding, thus exposing requirements and design problems sooner. Code efficiency—determined by architecture, detailed design decisions, and data-structure and 3-12 SWEBOK® Guide V3.0

5. Software Construction Tools 5.3. Unit Testing Tools [1*] [2*] 5.1. Development Environments Unit testing verifies the functioning of software [1*] modules in isolation from other software elements that are separately testable (for example, classes, A development environment, or integrated devel- routines, components). Unit testing is often auto- opment environment (IDE), provides compre- mated. Developers can use unit testing tools hensive facilities to programmers for software and frameworks to extend and create automated construction by integrating a set of development testing environment. With unit testing tools and tools. The choices of development environments frameworks, the developer can code criteria into can affect the efficiency and quality of software the test to verify the unit’s correctness under vari- construction. ous data sets. Each individual test is implemented In additional to basic code editing functions, as an object, and a test runner runs all of the tests. modern IDEs often offer other features like com- During the test execution, those failed test cases pilation and error detection from within the edi- will be automatically flagged and reported. tor, integration with source code control, build/ test/debugging tools, compressed or outline 5.4. Profiling, Performance Analysis, and views of programs, automated code transforms, Slicing Tools and support for refactoring. [1*]

5.2. GUI Builders Performance analysis tools are usually used to [1*] support code tuning. The most common performance analysis tools are profiling tools. An A GUI (Graphical User Interface) builder is a execution profiling tool monitors the code while software development tool that enables the devel- it runs and records how many times each state- oper to create and maintain GUIs in a WYSI- ment is executed or how much time the program WYG (what you see is what you get) mode. A spends on each statement or execution path. Pro- GUI builder usually includes a visual editor filing the code while it is running gives insight for the developer to design forms and windows into how the program works, where the hot spots and manage the layout of the widgets by drag- are, and where the developers should focus the ging, dropping, and parameter setting. Some GUI code tuning efforts. builders can automatically generate the source Program slicing involves computation of the code corresponding to the visual GUI design. set of program statements (i.e., the program slice) Because current GUI applications usually fol- that may affect the values of specified variables low the event-driven style (in which the flow of at some point of interest, which is referred to as the program is determined by events and event a slicing criterion. Program slicing can be used handling), GUI builder tools usually provide for locating the source of errors, program under- code generation assistants, which automate the standing, and optimization analysis. Program most repetitive tasks required for event handling. slicing tools compute program slices for various The supporting code connects widgets with the programming languages using static or dynamic outgoing and incoming events that trigger the analysis methods. functions providing the application logic. Some modern IDEs provide integrated GUI builders or GUI builder plug-ins. There are also many standalone GUI builders. Software Construction 3-13

MATRIX OF TOPICS VS. REFERENCE MATERIAL [1*] [4*] [6*] [2*] [3*] [5*] [7*] McConnell 2004 Sommerville 2011 Gamma et al. 1994 Clements et al. 2010 Clements et al. 2010 Null and Lobur 2006 Silberschatz et al. 2008 Silberschatz et al. 2008 Mellor and Balcer 2002 Mellor and Balcer 2002 1. Software Construction Fundamentals c2, c3, c7-c9, 1.1. Minimizing c24, c27, Complexity c28, c31, c32, c34 c3–c5, 1.2. Anticipating c24, c31, Change c32, c34 c8, 1.3. Constructing for c20– Verification c23, c31, c34 1.4. Reuse c16 1.5. Standards in c4 Construction 2. Managing Construction 2.1. Construction in c2, c3, Life Cycle Models c27, c29 c3, c4, 2.2. Construction c21, Planning c27–c29 2.3. Construction c25, c28 Measurement 3. Practical Considerations 3.1. Construction c3, c5, Design c24 3.2. Construction c4 Languages c5–c19, 3.3. Coding c25–c26 3-14 SWEBOK® Guide V3.0 [1*] [4*] [6*] [2*] [3*] [5*] [7*] McConnell 2004 Sommerville 2011 Gamma et al. 1994 Clements et al. 2010 Clements et al. 2010 Null and Lobur 2006 Silberschatz et al. 2008 Silberschatz et al. 2008 Mellor and Balcer 2002 Mellor and Balcer 2002 3.4. Construction c22, c23 Testing 3.5. Construction for c16 Reuse 3.6. Construction c16 with Reuse 3.7. Construction c8, Quality c20–c25 3.8. Integration c29 4. Construction Technologies 4.1. API Design and c7 Use 4.2. Object-Oriented c6, c7 Runtime Issues 4.3. Parameterization c1 and Generics 4.4. Assertions, Design by Contract, c8, c9 and Defensive Programming 4.5. Error Handling, Exception Handling, c3, c8 and Fault Tolerance 4.6. Executable c1 Models 4.7. State-Based and Table-Driven c18 Construction Techniques 4.8. Runtime Configuration and c3, c10 Internationalization 4.9. Grammar-Based c5 c8 Input Processing Software Construction 3-15 [1*] [4*] [6*] [2*] [3*] [5*] [7*] McConnell 2004 Sommerville 2011 Gamma et al. 1994 Clements et al. 2010 Clements et al. 2010 Null and Lobur 2006 Silberschatz et al. 2008 Silberschatz et al. 2008 Mellor and Balcer 2002 Mellor and Balcer 2002 4.10. Concurrency c6 Primitives 4.11. Middleware c1 c8 4.12. Construction Methods for c2 Distributed Software 4.13. Constructing Heterogeneous c9 Systems 4.14. Performance c25, c26 Analysis and Tuning 4.15. Platform c10 c1 Standards 4.16. Test-First c22 Programming 5. Construction Tools 5.1. Development c30 Environments 5.2. GUI Builders c30 5.3. Unit Testing c22 c8 Tools 5.4. Profiling, Performance c25, c26 Analysis, and Slicing Tools 3-16 SWEBOK® Guide V3.0

FURTHER READINGS REFERENCES

IEEE Std. 1517-2010 Standard for Information [1*] S. McConnell, Code Complete, 2nd ed., Technology—System and Software Life Microsoft Press, 2004. Cycle Processes—Reuse Processes, IEEE, 2010 [8]. [2*] I. Sommerville, Software Engineering, 9th ed., Addison-Wesley, 2011. This standard specifies the processes, activities, and tasks to be applied during each phase of the [3*] P. Clements et al., Documenting Software software life cycle to enable a software product Architectures: Views and Beyond, 2nd ed., to be constructed from reusable assets. It covers Pearson Education, 2010. the concept of reuse-based development and the processes of construction for reuse and construc- [4*] E. Gamma et al., Design Patterns: Elements tion with reuse. of Reusable Object-Oriented Software, 1st ed., Addison-Wesley Professional, 1994. IEEE Std. 12207-2008 (a.k.a. ISO/IEC 12207:2008) Standard for Systems and [5*] S.J. Mellor and M.J. Balcer, Executable Software Engineering—Software Life Cycle UML: A Foundation for Model-Driven Processes, IEEE, 2008 [9]. Architecture, 1st ed., Addison-Wesley, 2002. This standard defines a series of software development processes, including software construc- [6*] L. Null and J. Lobur, The Essentials of tion process, software integration process, and Computer Organization and Architecture, software reuse process. 2nd ed., Jones and Bartlett Publishers, 2006.

[7*] A. Silberschatz, P.B. Galvin, and G. Gagne, Operating System Concepts, 8th ed., Wiley, 2008.

[8] IEEE Std. 1517-2010 Standard for Information Technology—System and Software Life Cycle Processes—Reuse Processes, IEEE, 2010.

[9] IEEE Std. 12207-2008 (a.k.a. ISO/IEC 12207:2008) Standard for Systems and Software Engineering—Software Life Cycle Processes, IEEE, 2008. CHAPTER 4

SOFTWARE TESTING

ACRONYMS execute. This is why, in practice, a complete set of tests can generally be considered infi- API Application Program Interface nite, and testing is conducted on a subset of TDD Test-Driven Development all possible tests, which is determined by risk Testing and Test Control Notation and prioritization criteria. Testing always TTCN3 Version 3 implies a tradeoff between limited resources XP Extreme Programming and schedules on the one hand and inherently unlimited test requirements on the other. • Selected: The many proposed test tech- INTRODUCTION niques differ essentially in how the test set is selected, and software engineers must be Software testing consists of the dynamic verifica- aware that different selection criteria may tion that a program provides expected behaviors yield vastly different degrees of effective- on a finite set of test cases, suitably selected from ness. How to identify the most suitable the usually infinite execution domain. selection criterion under given conditions is In the above definition, italicized words - cor a complex problem; in practice, risk analysis respond to key issues in describing the Software techniques and software engineering exper- Testing knowledge area (KA): tise are applied. • Expected: It must be possible, although not • Dynamic: This term means that testing always easy, to decide whether the observed always implies executing the program on outcomes of program testing are acceptable selected inputs. To be precise, the input or not; otherwise, the testing effort is use- value alone is not always sufficient to spec- less. The observed behavior may be checked ify a test, since a complex, nondeterministic against user needs (commonly referred to system might react to the same input with as testing for validation), against a speci- different behaviors, depending on the system fication (testing for verification), or, per- state. In this KA, however, the term “input” haps, against the anticipated behavior from will be maintained, with the implied conven- implicit requirements or expectations (see tion that its meaning also includes a speci- Acceptance Tests in the Software Require- fied input state in those cases for which it ments KA). is important. Static techniques are different from and complementary to dynamic testing. In recent years, the view of software testing Static techniques are covered in the Software has matured into a constructive one. Testing is Quality KA. It is worth noting that terminol- no longer seen as an activity that starts only after ogy is not uniform among different commu- the coding phase is complete with the limited nities and some use the term “testing” also in purpose of detecting failures. Software testing reference to static techniques. is, or should be, pervasive throughout the entire • Finite: Even in simple programs, so many test development and maintenance life cycle. Indeed, cases are theoretically possible that exhaus- planning for software testing should start with the tive testing could require months or years to early stages of the software requirements process,

4-1 4-2 SWEBOK® Guide V3.0

Figure 4.1. Breakdown of Topics for the Software Testing KA and test plans and procedures should be system- and quality attributes of the software and also atically and continuously developed—and possi- for identifying faults in those cases where error bly refined—as software development proceeds. prevention has not been effective. It is perhaps These test planning and test designing activities obvious but worth recognizing that software can provide useful input for software designers and still contain faults, even after completion of an help to highlight potential weaknesses, such as extensive testing activity. Software failures expe- design oversights/contradictions, or omissions/ rienced after delivery are addressed by corrective ambiguities in the documentation. maintenance. Software maintenance topics are For many organizations, the approach to soft- covered in the Software Maintenance KA. ware quality is one of prevention: it is obviously In the Software Quality KA (see Software Qual- much better to prevent problems than to correct ity Management Techniques), software quality them. Testing can be seen, then, as a means for management techniques are notably categorized providing information about the functionality into static techniques (no code execution) and Software Testing 4-3

dynamic techniques (code execution). Both cat- 1. Software Testing Fundamentals egories are useful. This KA focuses on dynamic techniques. 1.1. Testing-Related Terminology Software testing is also related to software construction (see Construction Testing in the 1.1.1. Definitions of Testing and Related Software Construction KA). In particular, unit Terminology and integration testing are intimately related to [1*, c1, c2] [2*, c8] software construction, if not part of it. Definitions of testing and testing-related - termi BREAKDOWN OF TOPICS FOR nology are provided in the cited references and SOFTWARE TESTING summarized as follows.

The breakdown of topics for the Software Test- 1.1.2. Faults vs. Failures ing KA is shown in Figure 4.1. A more detailed [1*, c1s5] [2*, c11] breakdown is provided in the Matrix of Topics vs. Reference Material at the end of this KA. Many terms are used in the software engineering The first topic describes Software Testing Fun- literature to describe a malfunction: notably fault, damentals. It covers the basic definitions in the failure, and error, among others. This terminol- field of software testing, the basic terminology ogy is precisely defined in [3, c2]. It is essential and key issues, and software testing’s relation- to clearly distinguish between the cause of a mal- ship with other activities. function (for which the term fault will be used The second topic, Test Levels, consists of two here) and an undesired effect observed in the sys- (orthogonal) subtopics: the first subtopic lists the tem’s delivered service (which will be called a levels in which the testing of large software is failure). Indeed there may well be faults in the traditionally subdivided, and the second subtopic software that never manifest themselves as fail- considers testing for specific conditions or prop- ures (see Theoretical and Practical Limitations erties and is referred to as Objectives of Testing. of Testing in section 1.2, Key Issues). Thus test- Not all types of testing apply to every software ing can reveal failures, but it is the faults that can product, nor has every possible type been listed. and must be removed [3]. The more generic term The test target and test objective together defect can be used to refer to either a fault or a determine how the test set is identified, both with failure, when the distinction is not important [3]. regard to its consistency—how much testing is However, it should be recognized that the cause enough for achieving the stated objective—and of a failure cannot always be unequivocally iden- to its composition—which test cases should tified. No theoretical criteria exist to definitively be selected for achieving the stated objective determine, in general, the fault that caused an (although usually “for achieving the stated objec- observed failure. It might be said that it was the tive” remains implicit and only the first part of the fault that had to be modified to remove the failure, two italicized questions above is posed). Criteria but other modifications might have worked just for addressing the first question are referred to as as well. To avoid ambiguity, one could refer to test adequacy criteria, while those addressing the failure-causing inputs instead of faults—that is, second question are the test selection criteria. those sets of inputs that cause a failure to appear. Several Test Techniques have been developed in the past few decades, and new ones are still 1.2. Key Issues being proposed. Generally accepted techniques are covered in the third topic. 1.2.1. Test Selection Criteria / Test Adequacy Test-Related Measures are dealt with in the Criteria (Stopping Rules) fourth topic, while the issues relative to Test Pro- [1*, c1s14, c6s6, c12s7] cess are covered in the fifth. Finally, Software Testing Tools are presented in topic six. A test selection criterion is a means of selecting test cases or determining that a set of test cases 4-4 SWEBOK® Guide V3.0

is sufficient for a specified purpose. Test- ade in this regard is the Dijkstra aphorism that “pro- quacy criteria can be used to decide when suf- gram testing can be used to show the presence of ficient testing will be, or has been accomplished bugs, but never to show their absence” [5]. The [4] (see Termination in section 5.1, Practical obvious reason for this is that complete testing is Considerations). not feasible in realistic software. Because of this, testing must be driven based on risk [6, part 1] 1.2.2. Testing Effectiveness / Objectives for and can be seen as a risk management strategy. Testing [1*, c11s4, c13s11] 1.2.6. The Problem of Infeasible Paths [1*, c4s7] Testing effectiveness is determined by analyzing a set of program executions. Selection of tests to Infeasible paths are control flow paths that cannot be executed can be guided by different objectives: be exercised by any input data. They are a signifi- it is only in light of the objective pursued that the cant problem in path-based testing, particularly effectiveness of the test set can be evaluated. in automated derivation of test inputs to exercise control flow paths. 1.2.3. Testing for Defect Discovery [1*, c1s14] 1.2.7. Testability [1*, c17s2] In testing for defect discovery, a successful test is one that causes the system to fail. This is quite The term “software testability” has two related different from testing to demonstrate that the but different meanings: on the one hand, it refers software meets its specifications or other desired to the ease with which a given test coverage properties, in which case testing is successful if criterion can be satisfied; on the other hand, it no failures are observed under realistic test cases is defined as the likelihood, possibly measured and test environments. statistically, that a set of test cases will expose a failure if the software is faulty. Both meanings 1.2.4. The Oracle Problem are important. [1*, c1s9, c9s7] 1.3. Relationship of Testing to Other Activities An oracle is any human or mechanical agent that decides whether a program behaved correctly Software testing is related to, but different from, in a given test and accordingly results in a ver- static software quality management techniques, dict of “pass” or “fail.” There exist many differ- proofs of correctness, debugging, and program ent kinds of oracles; for example, unambiguous construction. However, it is informative to con- requirements specifications, behavioral models, sider testing from the point of view of software and code annotations. Automation of mechanized quality analysts and of certifiers. oracles can be difficult and expensive. • Testing vs. Static Software Quality Man- 1.2.5. Theoretical and Practical Limitations of agement Techniques (see Software Quality Testing Management Techniques in the Software [1*, c2s7] Quality KA [1*, c12]). • Testing vs. Correctness Proofs and Formal Testing theory warns against ascribing an unjusti- Verification (see the Software Engineering fied level of confidence to a series of successful Models and Methods KA [1*, c17s2]). tests. Unfortunately, most established results of • Testing vs. Debugging (see Construction testing theory are negative ones, in that they state Testing in the Software Construction KA what testing can never achieve as opposed to what and Debugging Tools and Techniques in the is actually achieved. The most famous quotation Computing Foundations KA [1*, c3s6]). Software Testing 4-5

• Testing vs. Program Construction (see Con- functional threads. Integration testing is often an struction Testing in the Software Construc- ongoing activity at each stage of development tion KA [1*, c3s2]). during which software engineers abstract away lower-level perspectives and concentrate on the 2. Test Levels perspectives of the level at which they are integrating. For other than small, simple software, Software testing is usually performed at differ- incremental integration testing strategies are usu- ent levels throughout the development and main- ally preferred to putting all of the components tenance processes. Levels can be distinguished together at once—which is often called “big based on the object of testing, which is called bang” testing. the target, or on the purpose, which is called the objective (of the test level). 2.1.3. System Testing [1*, c8] [2*, c8] 2.1. The Target of the Test [1*, c1s13] [2*, c8s1] System testing is concerned with testing the behavior of an entire system. Effective unit and The target of the test can vary: a single module, a integration testing will have identified many of group of such modules (related by purpose, use, the software defects. System testing is usually behavior, or structure), or an entire system. Three considered appropriate for assessing the non- test stages can be distinguished: unit, integra- functional system requirements—such as secu- tion, and system. These three test stages do not rity, speed, accuracy, and reliability (see Func- imply any process model, nor is any one of them tional and Non-Functional Requirements in the assumed to be more important than the other two. Software Requirements KA and Software Qual- ity Requirements in the Software Quality KA). 2.1.1. Unit Testing External interfaces to other applications, utilities, [1*, c3] [2*, c8] hardware devices, or the operating environments are also usually evaluated at this level. Unit testing verifies the functioning in isolation of software elements that are separately testable. 2.2. Objectives of Testing Depending on the context, these could be the [1*, c1s7] individual subprograms or a larger component made of highly cohesive units. Typically, unit Testing is conducted in view of specific objec- testing occurs with access to the code being tested tives, which are stated more or less explicitly and with the support of debugging tools. The pro- and with varying degrees of precision. Stating grammers who wrote the code typically, but not the objectives of testing in precise, quantitative always, conduct unit testing. terms supports measurement and control of the test process. 2.1.2. Integration Testing Testing can be aimed at verifying different prop- [1*, c7] [2*, c8] erties. Test cases can be designed to check that the functional specifications are correctly imple- Integration testing is the process of verifying the mented, which is variously referred to in the lit- interactions among software components. Clas- erature as conformance testing, correctness test- sical integration testing strategies, such as top- ing, or functional testing. However, several other down and bottom-up, are often used with hierar- nonfunctional properties may be tested as well— chically structured software. including performance, reliability, and usabil- Modern, systematic integration strategies are ity, among many others (see Models and Quality typically architecture-driven, which involves Characteristics in the Software Quality KA). incrementally integrating the software com- Other important objectives for testing include ponents or subsystems based on identified but are not limited to reliability measurement, 4-6 SWEBOK® Guide V3.0

identification of security vulnerabilities, usability 2.2.4. Reliability Achievement and Evaluation evaluation, and software acceptance, for which [1*, c15] [2*, c15s2] different approaches would be taken. Note that, in general, the test objectives vary with the test Testing improves reliability by identifying and target; different purposes are addressed at differ- correcting faults. In addition, statistical measures ent levels of testing. of reliability can be derived by randomly generat- The subtopics listed below are those most ing test cases according to the operational profile of often cited in the literature. Note that some kinds the software (see Operational Profile in section 3.5, of testing are more appropriate for custom-made Usage-Based Techniques). The latter approach is software packages—installation testing, for called operational testing. Using reliability growth example—and others for consumer products, like models, both objectives can be pursued together beta testing. [3] (see Life Test, Reliability Evaluation in section 4.1, Evaluation of the Program under Test). 2.2.1. Acceptance / Qualification Testing [1*, c1s7] [2*, c8s4] 2.2.5. Regression Testing [1*, c8s11, c13s3] Acceptance / qualification testing determines whether a system satisfies its acceptance criteria, According to [7], regression testing is the “selec- usually by checking desired system behaviors tive retesting of a system or component to verify against the customer’s requirements. The cus- that modifications have not caused unintended tomer or a customer’s representative thus speci- effects and that the system or component still fies or directly undertakes activities to check complies with its specified requirements.” In that their requirements have been met, or in the practice, the approach is to show that software case of a consumer product, that the organization still passes previously passed tests in a test suite has satisfied the stated requirements for the tar- (in fact, it is also sometimes referred to as nonre- get market. This testing activity may or may not gression testing). For incremental development, involve the developers of the system. the purpose of regression testing is to show that software behavior is unchanged by incremen- 2.2.2. Installation Testing tal changes to the software, except insofar as it [1*, c12s2] should. In some cases, a tradeoff must be made between the assurance given by regression testing Often, after completion of system and acceptance every time a change is made and the resources testing, the software is verified upon installation required to perform the regression tests, which in the target environment. Installation testing can can be quite time consuming due to the large be viewed as system testing conducted in the number of tests that may be executed. Regression operational environment of hardware configura- testing involves selecting, minimizing, and/or tions and other operational constraints. Installa- prioritizing a subset of the test cases in an exist- tion procedures may also be verified. ing test suite [8]. Regression testing can be conducted at each of the test levels described in sec- 2.2.3. Alpha and Beta Testing tion 2.1, The Target of the Test, and may apply to [1*, c13s7, c16s6] [2*, c8s4] functional and nonfunctional testing.

Before software is released, it is sometimes given 2.2.6. Performance Testing to a small, selected group of potential users for [1*, c8s6] trial use (alpha testing) and/or to a larger set of representative users (beta testing). These users Performance testing verifies that the software report problems with the product. Alpha and beta meets the specified performance requirements testing are often uncontrolled and are not always and assesses performance characteristics—for referred to in a test plan. instance, capacity and response time. Software Testing 4-7

2.2.7. Security Testing 2.2.12. Configuration Testing [1*, c8s3] [2*, c11s4] [1*, c8s5]

Security testing is focused on the verification that In cases where software is built to serve different the software is protected from external attacks. In users, configuration testing verifies the software particular, security testing verifies the confiden- under different specified configurations. tiality, integrity, and availability of the systems and its data. Usually, security testing includes 2.2.13. Usability and Human Computer Inter- verification against misuse and abuse of the soft- action Testing ware or system (negative testing). [10*, c6]

2.2.8. Stress Testing The main task of usability and human computer [1*, c8s8] interaction testing is to evaluate how easy it is for end users to learn and to use the software. In Stress testing exercises software at the maximum general, it may involve testing the software func- design load, as well as beyond it, with the goal tions that supports user tasks, documentation that of determining the behavioral limits, and to test aids users, and the ability of the system to recover defense mechanisms in critical systems. from user errors (see User Interface Design in the Software Design KA). 2.2.9. Back-to-Back Testing [7] 3. Test Techniques

IEEE/ISO/IEC Standard 24765 defines back-to- One of the aims of testing is to detect as many back testing as “testing in which two or more failures as possible. Many techniques have been variants of a program are executed with the same developed to do this [6, part 4]. These techniques inputs, the outputs are compared, and errors are attempt to “break” a program by being as sys- analyzed in case of discrepancies.” tematic as possible in identifying inputs that will produce representative program behaviors; for 2.2.10. Recovery Testing instance, by considering subclasses of the input [1*, c14s2] domain, scenarios, states, and data flows. The classification of testing techniques- pre Recovery testing is aimed at verifying software sented here is based on how tests are generated: restart capabilities after a system crash or other from the software engineer’s intuition and expe- “disaster.” rience, the specifications, the code structure, the real or imagined faults to be discovered, predicted 2.2.11. Interface Testing usage, models, or the nature of the application. [2*, c8s1.3] [9*, c4s4.5] One category deals with the combined use of two or more techniques. Interface defects are common in complex sys- Sometimes these techniques are classified as tems. Interface testing aims at verifying whether white-box (also called glass-box), if the tests are the components interface correctly to provide the based on information about how the software has correct exchange of data and control informa- been designed or coded, or as black-box if the test tion. Usually the test cases are generated from cases rely only on the input/output behavior of the interface specification. A specific objective of the software. The following list includes those interface testing is to simulate the use of APIs by testing techniques that are commonly used, but end-user applications. This involves the genera- some practitioners rely on some of the techniques tion of parameters of the API calls, the setting of more than others. external environment conditions, and the definition of internal data that affect the API. 4-8 SWEBOK® Guide V3.0

3.1. Based on the Software Engineer’s Intuition instead of considering all possible combinations. and Experience Pairwise testing belongs to combinatorial testing, which in general also includes higher-level com- 3.1.1. Ad Hoc binations than pairs: these techniques are referred to as t-wise, whereby every possible combination Perhaps the most widely practiced technique is of t input variables is considered. ad hoc testing: tests are derived relying on the software engineer’s skill, intuition, and experi- 3.2.3. Boundary-Value Analysis ence with similar programs. Ad hoc testing can [1*, c9s5] be useful for identifying tests cases that not easily generated by more formalized techniques. Test cases are chosen on or near the boundaries of the input domain of variables, with the underly- 3.1.2. Exploratory Testing ing rationale that many faults tend to concentrate near the extreme values of inputs. An extension of Exploratory testing is defined as simultaneous this technique is robustness testing, wherein test learning, test design, and test execution [6, part cases are also chosen outside the input domain of 1]; that is, the tests are not defined in advance variables to test program robustness in processing in an established test plan, but are dynamically unexpected or erroneous inputs. designed, executed, and modified. The effectiveness of exploratory testing relies on the software 3.2.4. Random Testing engineer’s knowledge, which can be derived [1*, c9s7] from various sources: observed product behavior during testing, familiarity with the application, Tests are generated purely at random (not to be the platform, the failure process, the type of pos- confused with statistical testing from the opera- sible faults and failures, the risk associated with a tional profile, as described in Operational Profile particular product, and so on. in section 3.5). This form of testing falls under the heading of input domain testing since the input 3.2. Input Domain-Based Techniques domain must be known in order to be able to pick random points within it. Random testing provides 3.2.1. Equivalence Partitioning a relatively simple approach for test automation; [1*, c9s4] recently, enhanced forms of random testing have been proposed in which the random input sam- Equivalence partitioning involves partitioning the pling is directed by other input selection criteria input domain into a collection of subsets (or equiv- [11]. Fuzz testing or fuzzing is a special form of alent classes) based on a specified criterion or rela- random testing aimed at breaking the software; it tion. This criterion or relation may be different is most often used for security testing. computational results, a relation based on control flow or data flow, or a distinction made between 3.3. Code-Based Techniques valid inputs that are accepted and processed by the system and invalid inputs, such as out of range val- 3.3.1. Control Flow-Based Criteria ues, that are not accepted and should generate an [1*, c4] error message or initiate error processing. A representative set of tests (sometimes only one) is usu- Control flow-based coverage criteria are aimed ally taken from each equivalency class. at covering all the statements, blocks of statements, or specified combinations of statements 3.2.2. Pairwise Testing in a program. The strongest of the control flow- [1*, c9s3] based criteria is path testing, which aims to execute all entry-to-exit control flow paths in a Test cases are derived by combining interesting program’s control flow graph. Since exhaustive values for every pair of a set of input variables path testing is generally not feasible because of Software Testing 4-9

loops, other less stringent criteria focus on cov- 3.4.1. Error Guessing erage of paths that limit loop iterations such as [1*, c9s8] statement coverage, branch coverage, and condition/decision testing. The adequacy of such In error guessing, test cases are specifically tests is measured in percentages; for example, designed by software engineers who try to antici- when all branches have been executed at least pate the most plausible faults in a given program. once by the tests, 100% branch coverage has A good source of information is the history of been achieved. faults discovered in earlier projects, as well as the software engineer’s expertise. 3.3.2. Data Flow-Based Criteria [1*, c5] 3.4.2. Mutation Testing [1*, c3s5] In data flow-based testing, the control flow graph is annotated with information about how the A mutant is a slightly modified version of the program variables are defined, used, and killed program under test, differing from it by a small (undefined). The strongest criterion, all -defini syntactic change. Every test case exercises both tion-use paths, requires that, for each variable, the original program and all generated mutants: every control flow path segment from a - defini if a test case is successful in identifying the dif- tion of that variable to a use of that definition is ference between the program and a mutant, the executed. In order to reduce the number of paths latter is said to be “killed.” Originally conceived required, weaker strategies such as all-definitions as a technique to evaluate test sets (see section and all-uses are employed. 4.2. Evaluation of the Tests Performed), mutation testing is also a testing criterion in itself: 3.3.3. Reference Models for Code-Based either tests are randomly generated until enough Testing mutants have been killed, or tests are specifically [1*, c4] designed to kill surviving mutants. In the latter case, mutation testing can also be categorized as Although not a technique in itself, the control a code-based technique. The underlying assump- structure of a program can be graphically rep- tion of mutation testing, the coupling effect, resented using a flow graph to visualize code- is that by looking for simple syntactic faults, based testing techniques. A flow graph is a more complex but real faults will be found. For directed graph, the nodes and arcs of which cor- the technique to be effective, a large number of respond to program elements (see Graphs and mutants must be automatically generated and Trees in the Mathematical Foundations KA). executed in a systematic way [12]. For instance, nodes may represent statements or uninterrupted sequences of statements, and arcs 3.5. Usage-Based Techniques may represent the transfer of control between nodes. 3.5.1. Operational Profile [1*, c15s5] 3.4. Fault-Based Techniques [1*, c1s14] In testing for reliability evaluation (also called operational testing), the test environment repro- With different degrees of formalization, fault- duces the operational environment of the soft- based testing techniques devise test cases spe- ware, or the operational profile, as closely as cifically aimed at revealing categories of likely possible. The goal is to infer from the observed or predefined faults. To better focus the test case test results the future reliability of the software generation or selection, a fault model can be when in actual use. To do this, inputs are assigned introduced that classifies the different types of probabilities, or profiles, according to their fre- faults. quency of occurrence in actual operation. Opera- tional profiles can be used during system testing 4-10 SWEBOK® Guide V3.0

to guide derivation of test cases that will assess (roughly, outputs). Test cases are systematically the achievement of reliability objectives and derived by considering every possible combina- exercise relative usage and criticality of different tion of conditions and their corresponding resul- functions similar to what will be encountered in tant actions. A related technique is cause-effect the operational environment [3]. graphing [1*, c13s6].

3.5.2. User Observation Heuristics 3.6.2. Finite-State Machines [10*, c5, c7] [1*, c10]

Usability principles can provide guidelines for dis- By modeling a program as a finite state machine, covering problems in the design of the user inter- tests can be selected in order to cover the states face [10*, c1s4] (see User Interface Design in the and transitions. Software Design KA). Specialized heuristics, also called usability inspection methods, are applied 3.6.3. Formal Specifications for the systematic observation of system usage [1*, c10s11] [2*, c15] under controlled conditions in order to determine how well people can use the system and its Stating the specifications in a formal language interfaces. Usability heuristics include cognitive (see Formal Methods in the Software Engineer- walkthroughs, claims analysis, field observations, ing Models and Methods KA) permits automatic thinking aloud, and even indirect approaches such derivation of functional test cases, and, at the as user questionnaires and interviews. same time, provides an oracle for checking test results. 3.6. Model-Based Testing Techniques TTCN3 (Testing and Test Control Notation version 3) is a language developed for writing test A model in this context is an abstract (formal) cases. The notation was conceived for the specific representation of the software under test or of needs of testing telecommunication systems, so it its software requirements (see Modeling in the is particularly suitable for testing complex com- Software Engineering Models and Methods KA). munication protocols. Model-based testing is used to validate requirements, check their consistency, and generate test 3.6.4. Workflow Models cases focused on the behavioral aspects of the [2*, c8s3.2, c19s3.1] software. The key components of model-based testing are [13]: the notation used to represent the Workflow models specify a sequence of - activi model of the software or its requirements; work- ties performed by humans and/or software appli- flow models or similar models; the test strategy cations, usually represented through graphical or algorithm used for test case generation; the notations. Each sequence of actions constitutes supporting infrastructure for the test execution; one workflow (also called a scenario). Both typi- and the evaluation of test results compared to cal and alternate workflows should be tested [6, expected results. Due to the complexity of the part 4]. A special focus on the roles in a work- techniques, model-based testing approaches flow specification is targeted in business process are often used in conjunction with test automa- testing. tion harnesses. Model-based testing techniques include the following. 3.7. Techniques Based on the Nature of the Application 3.6.1. Decision Tables [1*, c9s6] The above techniques apply to all kinds of software. Additional techniques for test derivation Decision tables represent logical relationships and execution are based on the nature of the soft- between conditions (roughly, inputs) and actions ware being tested; for example, Software Testing 4-11

• object-oriented software at every decision point. To avoid such misun- • component-based software derstandings, a clear distinction should be made • web-based software between test-related measures that provide an • concurrent programs evaluation of the program under test, based on • protocol-based software the observed test outputs, and the measures that • real-time systems evaluate the thoroughness of the test set. (See • safety-critical systems Software Engineering Measurement in the Soft- • service-oriented software ware Engineering Management KA for informa- • open-source software tion on measurement programs. See Software • embedded software Process and Product Measurement in the Soft- ware Engineering Process KA for information on 3.8. Selecting and Combining Techniques measures.) Measurement is usually considered fundamen- 3.8.1. Combining Functional and Structural tal to quality analysis. Measurement may also be [1*, c9] used to optimize the planning and execution of the tests. Test management can use several differ- Model-based and code-based test techniques ent process measures to monitor progress. (See are often contrasted as functional vs. structural section 5.1, Practical Considerations, for a dis- testing. These two approaches to test selection cussion of measures of the testing process useful are not to be seen as alternatives but rather as for management purposes.) complements; in fact, they use different sources of information and have been shown to high- 4.1. Evaluation of the Program Under Test light different kinds of problems. They could be used in combination, depending on budgetary 4.1.1. Program Measurements That Aid in considerations. Planning and Designing Tests [9*, c11] 3.8.2. Deterministic vs. Random [1*, c9s6] Measures based on software size (for example, source lines of code or functional size; see Mea- Test cases can be selected in a deterministic way, suring Requirements in the Software Require- according to one of many techniques, or ran- ments KA) or on program structure can be used domly drawn from some distribution of inputs, to guide testing. Structural measures also include such as is usually done in reliability testing. Sev- measurements that determine the frequency with eral analytical and empirical comparisons have which modules call one another. been conducted to analyze the conditions that make one approach more effective than the other. 4.1.2. Fault Types, Classification, and Statistics 4. Test-Related Measures [9*, c4]

Sometimes testing techniques are confused with The testing literature is rich in classifications and testing objectives. Testing techniques can be taxonomies of faults. To make testing more effec- viewed as aids that help to ensure the achieve- tive, it is important to know which types of faults ment of test objectives [6, part 4]. For instance, may be found in the software under test and the branch coverage is a popular testing technique. relative frequency with which these faults have Achieving a specified branch coverage measure occurred in the past. This information can be use- (e.g., 95% branch coverage) should not be the ful in making quality predictions as well as in objective of testing per se: it is a way of improv- process improvement (see Defect Characteriza- ing the chances of finding failures by attempting tion in the Software Quality KA). to systematically exercise every program branch 4-12 SWEBOK® Guide V3.0

4.1.3. Fault Density 4.2.2. Fault Seeding [1*, c13s4] [9*, c4] [1*, c2s5] [9*, c6]

A program under test can be evaluated by counting In fault seeding, some faults are artificially intro- discovered faults as the ratio between the number duced into a program before testing. When the of faults found and the size of the program. tests are executed, some of these seeded faults will be revealed as well as, possibly, some faults that 4.1.4. Life Test, Reliability Evaluation were already there. In theory, depending on which [1*, c15] [9*, c3] and how many of the artificial faults are discovered, testing effectiveness can be evaluated and the A statistical estimate of software reliability, remaining number of genuine faults can be esti- which can be obtained by observing reliabil- mated. In practice, statisticians question the dis- ity achieved, can be used to evaluate a software tribution and representativeness of seeded faults product and decide whether or not testing can be relative to genuine faults and the small sample size stopped (see section 2.2, Reliability Achievement on which any extrapolations are based. Some also and Evaluation). argue that this technique should be used with great care since inserting faults into software involves 4.1.5. Reliability Growth Models the obvious risk of leaving them there. [1*, c15] [9*, c8] 4.2.3. Mutation Score Reliability growth models provide a prediction of [1*, c3s5] reliability based on failures. They assume, in general, that when the faults that caused the observed In mutation testing (see Mutation Testing in sec- failures have been fixed (although some models tion 3.4, Fault-Based Techniques), the ratio of also accept imperfect fixes), the estimated -prod killed mutants to the total number of generated uct’s reliability exhibits, on average, an increasing mutants can be a measure of the effectiveness of trend. There are many published reliability growth the executed test set. models. Notably, these models are divided into failure-count and time-between-failure models. 4.2.4. Comparison and Relative Effectiveness of Different Techniques 4.2. Evaluation of the Tests Performed Several studies have been conducted to com- 4.2.1. Coverage / Thoroughness Measures pare the relative effectiveness of different testing [9*, c11] techniques. It is important to be precise as to the property against which the techniques are being Several test adequacy criteria require that the test assessed; what, for instance, is the exact meaning cases systematically exercise a set of elements given to the term “effectiveness”? Possible inter- identified in the program or in the specifications pretations include the number of tests needed to (see topic 3, Test Techniques). To evaluate the find the first failure, the ratio of the number of thoroughness of the executed tests, software engi- faults found through testing to all the faults found neers can monitor the elements covered so that during and after testing, and how much reliabil- they can dynamically measure the ratio between ity was improved. Analytical and empirical com- covered elements and the total number. For exam- parisons between different techniques have been ple, it is possible to measure the percentage of conducted according to each of the notions of branches covered in the program flow graph or the effectiveness specified above. percentage of functional requirements exercised among those listed in the specifications document. 5. Test Process Code-based adequacy criteria require appropriate instrumentation of the program under test. Testing concepts, strategies, techniques, and measures need to be integrated into a defined and Software Testing 4-13

controlled process. The test process supports test- the test item. Test documentation should be pro- ing activities and provides guidance to testers and duced and continually updated to the same level testing teams, from test planning to test output of quality as other types of documentation in evaluation, in such a way as to provide assurance software engineering. Test documentation should that the test objectives will be met in a cost-effec- also be under the control of software configura- tive way. tion management (see the Software Configuration Management KA). Moreover, test documentation 5.1. Practical Considerations includes work products that can provide material for user manuals and user training. 5.1.1. Attitudes / Egoless Programming [1*c16] [9*, c15] 5.1.5. Test-Driven Development [1*, c1s16] An important element of successful testing is a collaborative attitude towards testing and quality Test-driven development (TDD) originated as one assurance activities. Managers have a key role in of the core XP (extreme programming) practices fostering a generally favorable reception towards and consists of writing unit tests prior to writing failure discovery and correction during software the code to be tested (see Agile Methods in the development and maintenance; for instance, by Software Engineering Models and Method KA). overcoming the mindset of individual code own- In this way, TDD develops the test cases as a sur- ership among programmers and by promoting a rogate for a software requirements specification collaborative environment with team responsibil- document rather than as an independent check ity for anomalies in the code. that the software has correctly implemented the requirements. Rather than a testing strategy, TDD 5.1.2. Test Guides is a practice that requires software developers to [1*, c12s1] [9*, c15s1] define and maintain unit tests; it thus can also have a positive impact on elaborating user needs The testing phases can be guided by various and software requirements specifications. aims—for example, risk-based testing uses the product risks to prioritize and focus the test strat- 5.1.6. Internal vs. Independent Test Team egy, and scenario-based testing defines test cases [1*, c16] based on specified software scenarios. Formalizing the testing process may also involve 5.1.3. Test Process Management formalizing the organization of the testing team. [1*, c12] [9*, c15] The testing team can be composed of internal members (that is, on the project team, involved or Test activities conducted at different levels (see not in software construction), of external members topic 2, Test Levels) must be organized—together (in the hope of bringing an unbiased, independent with people, tools, policies, and measures—into a perspective), or of both internal and external mem- well-defined process that is an integral part of the bers. Considerations of cost, schedule, maturity life cycle. levels of the involved organizations, and criticality of the application can guide the decision. 5.1.4. Test Documentation and Work Products [1*, c8s12] [9*, c4s5] 5.1.7. Cost/Effort Estimation and Test Process Measures Documentation is an integral part of the formaliza- [1*, c18s3] [9*, c5s7] tion of the test process [6, part 3]. Test documents may include, among others, the test plan, test Several measures related to the resources spent design specification, test procedure specification, on testing, as well as to the relative fault-finding test case specification, test log, and test incident effectiveness of the various test phases, are used report. The software under test is documented as by managers to control and improve the testing 4-14 SWEBOK® Guide V3.0

process. These test measures may cover such 5.2. Test Activities aspects as number of test cases specified, number of test cases executed, number of test cases As shown in the following description, successful passed, and number of test cases failed, among management of test activities strongly depends others. on the software configuration management pro- Evaluation of test phase reports can be com- cess (see the Software Configuration Manage- bined with root-cause analysis to evaluate test- ment KA). process effectiveness in finding faults as early as possible. Such an evaluation can be associated 5.2.1. Planning with the analysis of risks. Moreover, the resources [1*, c12s1, c12s8] that are worth spending on testing should be commensurate with the use/criticality of the applica- Like all other aspects of project management, tion: different techniques have different costs and testing activities must be planned. Key aspects yield different levels of confidence in product of test planning include coordination of person- reliability. nel, availability of test facilities and equipment, creation and maintenance of all test-related docu- 5.1.8. Termination mentation, and planning for possible undesir- [9*, c10s4] able outcomes. If more than one baseline of the software is being maintained, then a major plan- A decision must be made as to how much test- ning consideration is the time and effort needed ing is enough and when a test stage can be termi- to ensure that the test environment is set to the nated. Thoroughness measures, such as achieved proper configuration. code coverage or functional coverage, as well as estimates of fault density or of operational reli- 5.2.2. Test-Case Generation ability, provide useful support but are not suffi- [1*, c12s1, c12s3] cient in themselves. The decision also involves considerations about the costs and risks incurred Generation of test cases is based on the level of by possible remaining failures, as opposed to testing to be performed and the particular testing the costs incurred by continuing to test (see Test techniques. Test cases should be under the con- Selection Criteria / Test Adequacy Criteria in trol of software configuration management and section 1.2, Key Issues). include the expected results for each test.

5.1.9. Test Reuse and Test Patterns 5.2.3. Test Environment Development [9*, c2s5] [1*, c12s6]

To carry out testing or maintenance in an orga- The environment used for testing should be com- nized and cost-effective way, the means used to patible with the other adopted software engi- test each part of the software should be reused neering tools. It should facilitate development systematically. A repository of test materials and control of test cases, as well as logging and should be under the control of software con- recovery of expected results, scripts, and other figuration management so that changes to soft- testing materials. ware requirements or design can be reflected in changes to the tests conducted. 5.2.4. Execution The test solutions adopted for testing some [1*, c12s7] application types under certain circumstances, with the motivations behind the decisions taken, Execution of tests should embody a basic prin- form a test pattern that can itself be documented ciple of scientific experimentation: everything for later reuse in similar projects. done during testing should be performed and documented clearly enough that another person Software Testing 4-15

could replicate the results. Hence, testing should the software. Defect tracking information is used be performed in accordance with documented to determine what aspects of software testing procedures using a clearly defined version of the and other processes need improvement and how software under test. effective previous approaches have been.

5.2.5. Test Results Evaluation 6. Software Testing Tools [9*, c15] 6.1. Testing Tool Support The results of testing should be evaluated to [1*, c12s11] [9*, c5] determine whether or not the testing has been successful. In most cases, “successful” means Testing requires many labor-intensive tasks, run- that the software performed as expected and did ning numerous program executions, and handling not have any major unexpected outcomes. Not a great amount of information. Appropriate tools all unexpected outcomes are necessarily faults can alleviate the burden of clerical, tedious opera- but are sometime determined to be simply noise. tions and make them less error-prone. Sophisti- Before a fault can be removed, an analysis and cated tools can support test design and test case debugging effort is needed to isolate, identify, generation, making it more effective. and describe it. When test results are particularly important, a formal review board may be con- 6.1.1. Selecting Tools vened to evaluate them. [1*, c12s11]

5.2.6. Problem Reporting / Test Log Guidance to managers and testers on how to select [1*, c13s9] testing tools that will be most useful to their organization and processes is a very important topic, Testing activities can be entered into a testing as tool selection greatly affects testing efficiency log to identify when a test was conducted, who and effectiveness. Tool selection depends on performed the test, what software configuration diverse evidence, such as development choices, was used, and other relevant identification infor- evaluation objectives, execution facilities, and so mation. Unexpected or incorrect test results can on. In general, there may not be a unique tool that be recorded in a problem reporting system, the will satisfy particular needs, so a suite of tools data for which forms the basis for later debug- could be an appropriate choice. ging and fixing the problems that were observed as failures during testing. Also, anomalies not 6.2. Categories of Tools classified as faults could be documented in case they later turn out to be more serious than first We categorize the available tools according to thought. Test reports are also inputs to the change their functionality: management request process (see Software Con- figuration Control in the Software Configuration • Test harnesses (drivers, stubs) [1*, c3s9] Management KA). provide a controlled environment in which tests can be launched and the test outputs can 5.2.7. Defect Tracking be logged. In order to execute parts of a pro- [9*, c9] gram, drivers and stubs are provided to simulate calling and called modules, respectively. Defects can be tracked and analyzed to determine • Test generators [1*, c12s11] provide assis- when they were introduced into the software, tance in the generation test cases. The gen- why they were created (for example, poorly eration can be random, path-based, model- defined requirements, incorrect variable declara- based, or a mix thereof. tion, memory leak, programming syntax error), • Capture/replay tools [1*, c12s11] auto- and when they could have been first observed in matically reexecute, or replay, previously 4-16 SWEBOK® Guide V3.0

executed tests which have recorded inputs • Tracers [1*, c1s7] record the history of a and outputs (e.g., screens). program’s execution paths. • Oracle/file comparators/assertion checking • Regression testing tools [1*, c12s16] support tools [1*, c9s7] assist in deciding whether a the reexecution of a test suite after a section test outcome is successful or not. of software has been modified. They can also • Coverage analyzers and instrumenters [1*, help to select a test subset according to the c4] work together. Coverage analyzers assess change made. which and how many entities of the program • Reliability evaluation tools [9*, c8] support flow graph have been exercised amongst all test results analysis and graphical visualiza- those required by the selected test coverage tion in order to assess reliability-related mea- criterion. The analysis can be done thanks to sures according to selected models. program instrumenters that insert recording probes into the code. Software Testing 4-17

MATRIX OF TOPICS VS. REFERENCE MATERIAL [1*] [2*] [9*] [10*] Kan 2003 Nielsen 1993 Sommerville 2011 Naik and Tripathy 2008Naik and Tripathy

1. Software Testing Fundamentals 1.1. Testing-Related Terminology 1.1.1. Definitions of Testing and c1,c2 c8 Related Terminology 1.1.2. Faults vs. Failures c1s5 c11 1.2. Key Issues 1.2.1. Test Selection Criteria / c1s14, c6s6, Test Adequacy Criteria c12s7 (Stopping Rules) 1.2.2. Testing Effectiveness / c13s11, c11s4 Objectives for Testing 1.2.3. Testing for Defect c1s14 Identification c1s9, 1.2.4. The Oracle Problem c9s7 1.2.5. Theoretical and Practical c2s7 Limitations of Testing 1.2.6. The Problem of Infeasible c4s7 Paths 1.2.7. Testability c17s2 1.3. Relationship of Testing to Other Activities 1.3.1. Testing vs. Static Software Quality Management c12 Techniques 1.3.2. Testing vs. Correctness c17s2 Proofs and Formal Verification 1.3.3. Testing vs. Debugging c3s6 1.3.4. Testing vs. Programming c3s2 2. Test Levels 2.1. The Target of the Test c1s13 c8s1 2.1.1. Unit Testing c3 c8 2.1.2. Integration Testing c7 c8 2.1.3. System Testing c8 c8 4-18 SWEBOK® Guide V3.0 [1*] [2*] [9*] [10*] Kan 2003 Nielsen 1993 Sommerville 2011 Naik and Tripathy 2008Naik and Tripathy

2.2. Objectives of Testing c1s7 2.2.1. Acceptance / Qualification c1s7 c8s4 2.2.2. Installation Testing c12s2 c13s7, 2.2.3. Alpha and Beta Testing c8s4 c16s6 2.2.4. Reliability Achievement c15 c15s2 and Evaluation c8s11, 2.2.5. Regression Testing c13s3 2.2.6. Performance Testing c8s6 2.2.7. Security Testing c8s3 c11s4 2.2.8. Stress Testing c8s8 2.2.9. Back-to-Back Testing 2.2.10. Recovery Testing c14s2 2.2.11. Interface Testing c8s1.3 c4s4.5 2.2.12. Configuration Testing c8s5 2.2.13. Usability and Human c6 Computer Interaction Testing 3. Test Techniques 3.1. Based on the Software Engineer’s Intuition and Experience 3.1.1. Ad Hoc 3.1.2. Exploratory Testing 3.2. Input Domain-Based Techniques 3.2.1. Equivalence Partitioning c9s4 3.2.2. Pairwise Testing c9s3 3.2.3. Boundary-Value Analysis c9s5 3.2.4. Random Testing c9s7 3.3. Code-Based Techniques 3.3.1. Control Flow-Based c4 Criteria Software Testing 4-19 [1*] [2*] [9*] [10*] Kan 2003 Nielsen 1993 Sommerville 2011 Naik and Tripathy 2008Naik and Tripathy

3.3.2. Data Flow-Based Criteria c5 3.3.3. Reference Models for c4 Code-Based Testing 3.4. Fault-Based Techniques c1s14 3.4.1. Error Guessing c9s8 3.4.2. Mutation Testing c3s5 3.5. Usage-Based Techniques 3.5.1. Operational Profile c15s5 3.5.2. User Observation c5, c7 Heuristics 3.6. Model-Based Testing Techniques 3.6.1. Decision Table c9s6 3.6.2. Finite-State Machines c10 3.6.3. Testing from Formal c10s11 c15 Specifications 3.7. Techniques Based on the Nature of the Application 3.8. Selecting and Combining Techniques 3.8.1. Functional and Structural c9 3.8.2. Deterministic vs. Random c9s6 4. Test-Related Measures 4.1. Evaluation of the Program Under Test 4.1.1. Program Measurements That Aid in Planning and c11 Designing Testing 4.1.2. Fault Types, Classification, c4 and Statistics 4.1.3. Fault Density c13s4 c4 4.1.4. Life Test, Reliability c15 c3 Evaluation 4.1.5. Reliability Growth Models c15 c8 4-20 SWEBOK® Guide V3.0 [1*] [2*] [9*] [10*] Kan 2003 Nielsen 1993 Sommerville 2011 Naik and Tripathy 2008Naik and Tripathy

4.2. Evaluation of the Tests Performed 4.2.1. Coverage / Thoroughness c11 Measures 4.2.2. Fault Seeding c2s5 c6 4.2.3. Mutation Score c3s5 4.2.4. Comparison and Relative Effectiveness of Different Techniques 5. Test Process 5.1. Practical Considerations 5.1.1. Attitudes / Egoless c16 c15 Programming 5.1.2. Test Guides c12s1 c15s1 5.1.3. Test Process Management c12 c15 5.1.4. Test Documentation and c8s12 c4s5 Work Products 5.1.5. Test-Driven Development c1s16 5.1.6. Internal vs. Independent c16 Test Team 5.1.7. Cost/Effort Estimation and c18s3 c5s7 Other Process Measures 5.1.8. Termination c10s4 5.1.9. Test Reuse and Patterns c2s5 5.2. Test Activities c12s1 5.2.1. Planning c12s8 c12s1 5.2.2. Test-Case Generation c12s3 5.2.3. Test Environment c12s6 Development 5.2.4. Execution c12s7 5.2.5. Test Results Evaluation c15 Software Testing 4-21 [1*] [2*] [9*] [10*] Kan 2003 Nielsen 1993 Sommerville 2011 Naik and Tripathy 2008Naik and Tripathy

5.2.6. Problem Reporting / Test c13s9 Log 5.2.7. Defect Tracking c9 6. Software Testing Tools 6.1. Testing Tool Support c12s11 c5 6.1.1. Selecting Tools c12s11 c1s7, c3s9, c4, c9s7, 6.2. Categories of Tools c8 c12s11, c12s16 4-22 SWEBOK® Guide V3.0

REFERENCES [1*] S. Naik and P. Tripathy, Software Testing [8] S. Yoo and M. Harman, “Regression Testing and Quality Assurance: Theory and Minimization, Selection and Prioritization: Practice, Wiley-Spektrum, 2008. A Survey,” Software Testing Verification and Reliability, vol. 22, no. 2, Mar. 2012, [2*] I. Sommerville, Software Engineering, 9th pp. 67–120. ed., Addison-Wesley, 2011. [9*] S.H. Kan, Metrics and Models in Software [3] M.R. Lyu, ed., Handbook of Software Quality Engineering, 2nd ed., Addison- Reliability Engineering, McGraw-Hill and Wesley, 2002. IEEE Computer Society Press, 1996. [10*] J. Nielsen, Usability Engineering, Morgan [4] H. Zhu, P.A.V. Hall, and J.H.R. May, Kaufmann, 1993. “Software Unit Test Coverage and Adequacy,” ACM Computing Surveys, vol. [11] T.Y. Chen et al., “Adaptive Random Testing: 29, no. 4, Dec. 1997, pp. 366–427. The ART of Test Case Diversity,” Journal of Systems and Software, vol. 83, no. 1, Jan. [5] E.W. Dijkstra, “Notes on Structured 2010, pp. 60–66. Programming,” T.H.-Report 70-WSE-03, Technological University, Eindhoven, 1970; [12] Y. Jia and M. Harman, “An Analysis http://www.cs.utexas.edu/users/EWD/ and Survey of the Development of ewd02xx/EWD249.PDF. Mutation Testing,” IEEE Trans. Software Engineering, vol. 37, no. 5, Sep.–Oct. 2011, [6] ISO/IEC/IEEE P29119-1/DIS Draft Standard pp. 649–678. for Software and Systems Engineering— Software Testing—Part 1: Concepts and [13] M. Utting and B. Legeard, Practical Definitions, ISO/IEC/IEEE, 2012. Model-Based Testing: A Tools Approach, Morgan Kaufmann, 2007. [7] ISO/IEC/IEEE 24765:2010 Systems and Software Engineering—Vocabulary, ISO/ IEC/IEEE, 2010. CHAPTER 5

SOFTWARE MAINTENANCE

ACRONYMS during the postdelivery stage. Predelivery activities include planning for postdelivery operations, MR Modification Request maintainability, and logistics determination for PR Problem Report transition activities [1*, c6s9]. Postdelivery activities include software modification, training, Software Configuration SCM and operating or interfacing to a help desk. Management The Software Maintenance knowledge area SLA Service-Level Agreement (KA) is related to all other aspects of software SQA Software Quality Assurance engineering. Therefore, this KA description is V&V Verification and Validation linked to all other software engineering KAs of the Guide.

INTRODUCTION BREAKDOWN OF TOPICS FOR SOFTWARE MAINTENANCE Software development efforts result in the delivery of a software product that satisfies user The breakdown of topics for the Software Main- requirements. Accordingly, the software product tenance KA is shown in Figure 5.1. must change or evolve. Once in operation, defects are uncovered, operating environments change, 1. Software Maintenance Fundamentals and new user requirements surface. The maintenance phase of the life cycle begins following a This first section introduces the concepts and warranty period or postimplementation support terminology that form an underlying basis to delivery, but maintenance activities occur much understanding the role and scope of software earlier. maintenance. The topics provide definitions and Software maintenance is an integral part of a emphasize why there is a need for maintenance. software life cycle. However, it has not received Categories of software maintenance are critical to the same degree of attention that the other phases understanding its underlying meaning. have. Historically, software development has had a much higher profile than software maintenance 1.1. Definitions and Terminology in most organizations. This is now changing, as [1*, c3] [2*, c1s2, c2s2] organizations strive to squeeze the most out of their software development investment by keep- The purpose of software maintenance is defined ing software operating as long as possible. The in the international standard for software mainte- open source paradigm has brought further atten- nance: ISO/IEC/IEEE 14764 [1*].1 In the context tion to the issue of maintaining software artifacts of software engineering, software maintenance is developed by others. essentially one of the many technical processes. In this Guide, software maintenance is defined as the totality of activities required to provide 1 For the purpose of conciseness and ease of read- cost-effective support to software. Activities are ing, this standard is referred to simply as IEEE 14764 performed during the predelivery stage as well as in the subsequent text of this KA.

5-1 5-2 SWEBOK® Guide V3.0

Figure 5.1. Breakdown of Topics for the Software Maintenance KA

The objective of software maintenance is to modified, testing is conducted, and a new version modify existing software while preserving its of the software product is released. Also, train- integrity. The international standard also states ing and daily support are provided to users. The the importance of having some maintenance term maintainer is defined as an organization that activities prior to the final delivery of software performs maintenance activities. In this KA, the (predelivery activities). Notably, IEEE 14764 term will sometimes refer to individuals who per- emphasizes the importance of the predelivery form those activities, contrasting them with the aspects of maintenance—planning, for example. developers. IEEE 14764 identifies the primary activities of 1.2. Nature of Maintenance software maintenance as process implementation, [2*, c1s3] problem and modification analysis, modification implementation, maintenance review/acceptance, Software maintenance sustains the software prod- migration, and retirement. These activities are uct throughout its life cycle (from development discussed in section 3.2, Maintenance Activities. to operations). Modification requests are logged Maintainers can learn from the develop- and tracked, the impact of proposed changes is ers’ knowledge of the software. Contact with determined, code and other software artifacts are the developers and early involvement by the Software Maintenance 5-3

maintainer helps reduce the overall maintenance perception of software maintenance is that it effort. In some instances, the initial developer merely fixes faults. However, studies and sur- cannot be reached or has moved on to other tasks, veys over the years have indicated that the major- which creates an additional challenge for main- ity, over 80 percent, of software maintenance is tainers. Maintenance must take software artifacts used for noncorrective actions [2*, figure 4.1]. from development (for example, code or docu- Grouping enhancements and corrections together mentation) and support them immediately, then in management reports contributes to some mis- progressively evolve/maintain them over a soft- conceptions regarding the high cost of correc- ware life cycle. tions. Understanding the categories of software maintenance helps to understand the structure of 1.3. Need for Maintenance software maintenance costs. Also, understanding [2*, c1s5] the factors that influence the maintainability of software can help to contain costs. Some environ- Maintenance is needed to ensure that the software mental factors and their relationship to software continues to satisfy user requirements. Mainte- maintenance costs include the following: nance is applicable to software that is developed using any software life cycle model (for example, • Operating environment refers to hardware spiral or linear). Software products change due and software. to corrective and noncorrective software actions. • Organizational environment refers to poli- Maintenance must be performed in order to cies, competition, process, product, and personnel. • correct faults; • improve the design; 1.5. Evolution of Software • implement enhancements; [2*, c3s5] • interface with other software; • adapt programs so that different hardware, Software maintenance in terms of evolution was software, system features, and telecommuni- first addressed in the late 1960s. Over a period of cations facilities can be used; twenty years, research led to the formulation of • migrate legacy software; and eight “Laws of Evolution.” Key findings include a • retire software. proposal that maintenance is evolutionary development and that maintenance decisions are aided Five key characteristics comprise the maintain- by understanding what happens to software over er’s activities: time. Some state that maintenance is continued development, except that there is an extra input • maintaining control over the software’s day- (or constraint)–in other words, existing large soft- to-day functions; ware is never complete and continues to evolve; • maintaining control over software as it evolves, it grows more complex unless some modification; action is taken to reduce this complexity. • perfecting existing functions; • identifying security threats and fixing secu- 1.6. Categories of Maintenance rity vulnerabilities; and [1*, c3, c6s2] [2*, c3s3.1] • preventing software performance from degrading to unacceptable levels. Three categories (types) of maintenance have been defined: corrective, adaptive, and perfec- 1.4. Majority of Maintenance Costs tive [2*, c4s3]. IEEE 14764 includes a fourth [2*, c4s3, c5s5.2] category–preventative.

Maintenance consumes a major share of the finan- • Corrective maintenance: reactive modifi- cial resources in a software life cycle. A common cation (or repairs) of a software product 5-4 SWEBOK® Guide V3.0

performed after delivery to correct discov- next release while sending out emergency patches ered problems. Included in this category for the current release, also creates a challenge. is emergency maintenance, which is an The following section presents some of the tech- unscheduled modification performed to tem- nical and management issues related to software porarily keep a software product operational maintenance. They have been grouped under the pending corrective maintenance. following topic headings: • Adaptive maintenance: modification of a software product performed after delivery to • technical issues, keep a software product usable in a changed • management issues, or changing environment. For example, • cost estimation, and the operating system might be upgraded • measurement. and some changes to the software may be necessary. 2.1. Technical Issues • Perfective maintenance: modification of a software product after delivery to provide 2.1.1. Limited Understanding enhancements for users, improvement of [2*, c6] program documentation, and recoding to improve software performance, maintain- Limited understanding refers to how quickly a ability, or other software attributes. software engineer can understand where to make • Preventive maintenance: modification of a a change or correction in software that he or she software product after delivery to detect and did not develop. Research indicates that about half correct latent faults in the software product of the total maintenance effort is devoted to under- before they become operational faults. standing the software to be modified. Thus, the topic of software comprehension is of great inter- IEEE 14764 classifies adaptive and perfective est to software engineers. Comprehension is more maintenance as maintenance enhancements. It difficult in text-oriented representation—in source also groups together the corrective and preven- code, for example—where it is often difficult to tive maintenance categories into a correction cat- trace the evolution of software through its releases/ egory, as shown in Table 5.1. versions if changes are not documented and if the developers are not available to explain it, which is Table 5.1. Software Maintenance Categories often the case. Thus, software engineers may initially have a limited understanding of the software; Correction Enhancement much has to be done to remedy this. Proactive Preventive Perfective 2.1.2. Testing Reactive Corrective Adaptive [1*, c6s2.2.2] [2*, c9]

2. Key Issues in Software Maintenance The cost of repeating full testing on a major piece of software is significant in terms of time A number of key issues must be dealt with to and money. In order to ensure that the requested ensure the effective maintenance of software. problem reports are valid, the maintainer should Software maintenance provides unique techni- replicate or verify problems by running the cal and management challenges for software appropriate tests. Regression testing (the selec- engineers—for example, trying to find a fault in tive retesting of software or a component to ver- software containing a large number of lines of ify that the modifications have not caused unin- code that another software engineer developed. tended effects) is an important testing concept in Similarly, competing with software developers maintenance. Additionally, finding time to test is for resources is a constant battle. Planning for a often difficult. Coordinating tests when different future release, which often includes coding the members of the maintenance team are working Software Maintenance 5-5

on different problems at the same time remains a 2.1.4. Maintainability challenge. When software performs critical func- [1*, c6s8] [2*, c12s5.5] tions, it may be difficult to bring it offline to test. Tests cannot be executed in the most meaning- IEEE 14764 [1*, c3s4] defines maintainability ful place–the production system. The Software as the capability of the software product to be Testing KA provides additional information and modified. Modifications may include corrections, references on this matter in its subtopic on regres- improvements, or adaptation of the software to sion testing. changes in environment as well as changes in requirements and functional specifications. 2.1.3. Impact Analysis As a primary software quality characteristic, [1*, c5s2.5] [2*, c13s3] maintainability should be specified, reviewed, and controlled during software development activi- Impact analysis describes how to conduct, cost- ties in order to reduce maintenance costs. When effectively, a complete analysis of the impact of done successfully, the software’s maintainability a change in existing software. Maintainers must will improve. Maintainability is often difficult to possess an intimate knowledge of the software’s achieve because the subcharacteristics are often structure and content. They use that knowledge not an important focus during the process of soft- to perform impact analysis, which identifies all ware development. The developers are, typically, systems and software products affected by a soft- more preoccupied with many other activities and ware change request and develops an estimate of frequently prone to disregard the maintainer’s the resources needed to accomplish the change. requirements. This in turn can, and often does, Additionally, the risk of making the change is result in a lack of software documentation and test determined. The change request, sometimes called environments, which is a leading cause of difficul- a modification request (MR) and often called a ties in program comprehension and subsequent problem report (PR), must first be analyzed and impact analysis. The presence of systematic and translated into software terms. Impact analysis is mature processes, techniques, and tools helps to performed after a change request enters the soft- enhance the maintainability of software. ware configuration management process. IEEE 14764 states the impact analysis tasks: 2.2. Management Issues

• analyze MRs/PRs; 2.2.1. Alignment with Organizational • replicate or verify the problem; Objectives • develop options for implementing the [2*, c4] modification; • document the MR/PR, the results, and the Organizational objectives describe how to demon- execution options; strate the return on investment of software main- • obtain approval for the selected modification tenance activities. Initial software development is option. usually project-based, with a defined time scale and budget. The main emphasis is to deliver a product The severity of a problem is often used to that meets user needs on time and within budget. decide how and when it will be fixed. The soft- In contrast, software maintenance often has the ware engineer then identifies the affected com- objective of extending the life of software for as ponents. Several potential solutions are provided, long as possible. In addition, it may be driven by followed by a recommendation as to the best the need to meet user demand for software updates course of action. and enhancements. In both cases, the return on Software designed with maintainability in mind investment is much less clear, so that the view at greatly facilitates impact analysis. More informa- the senior management level is often that of a major tion can be found in the Software Configuration activity consuming significant resources with no Management KA. clear quantifiable benefit for the organization. 5-6 SWEBOK® Guide V3.0

2.2.2. Staffing assignment of the maintenance responsibility to a [2*, c4s5, c10s4] single group or person, regardless of the organization’s structure. Staffing refers to how to attract and keep software maintenance staff. Maintenance is not often 2.2.5. Outsourcing viewed as glamorous work. As a result, software [3*] maintenance personnel are frequently viewed as “second-class citizens,” and morale therefore Outsourcing and offshoring software mainte- suffers. nance has become a major industry. Organiza- tions are outsourcing entire portfolios of soft- 2.2.3. Process ware, including software maintenance. More [1*, c5] [2*, c5] often, the outsourcing option is selected for less mission-critical software, as organizations are The software life cycle process is a set of activities, unwilling to lose control of the software used in methods, practices, and transformations that peo- their core business. One of the major challenges ple use to develop and maintain software and its for outsourcers is to determine the scope of the associated products. At the process level, software maintenance services required, the terms of a ser- maintenance activities share much in common vice-level agreement, and the contractual details. with software development (for example, software Outsourcers will need to invest in a maintenance configuration management is a crucial activity in infrastructure, and the help desk at the remote site both). Maintenance also requires several activities should be staffed with native-language speakers. that are not found in software development (see Outsourcing requires a significant initial invest- section 3.2 on unique activities for details). These ment and the setup of a maintenance process that activities present challenges to management. will require automation.

2.2.4. Organizational Aspects of Maintenance 2.3. Maintenance Cost Estimation [1*, c7s2.3] [2*, c10] Software engineers must understand the different Organizational aspects describe how to iden- categories of software maintenance, discussed tify which organization and/or function will be above, in order to address the question of estimat- responsible for the maintenance of software. The ing the cost of software maintenance. For plan- team that develops the software is not necessar- ning purposes, cost estimation is an important ily assigned to maintain the software once it is aspect of planning for software maintenance. operational. In deciding where the software maintenance 2.3.1. Cost Estimation function will be located, software engineering [2*, c7s2.4] organizations may, for example, stay with the original developer or go to a permanent main- Section 2.1.3 describes how impact analysis iden- tenance-specific team (or maintainer). Having a tifies all systems and software products affected permanent maintenance team has many benefits: by a software change request and develops an estimate of the resources needed to accomplish • allows for specialization; that change. • creates communication channels; Maintenance cost estimates are affected • promotes an egoless, collegiate atmosphere; by many technical and nontechnical factors. • reduces dependency on individuals; IEEE 14764 states that “the two most popular • allows for periodic audit checks. approaches to estimating resources for software maintenance are the use of parametric models Since there are many pros and cons to each and the use of experience” [1*, c7s4.1]. A combi- option, the decision should be made on a case-by- nation of these two can also be used. case basis. What is important is the delegation or Software Maintenance 5-7

2.3.2. Parametric Models quality model suggests measures that are specific [2*, c12s5.6] for software maintenance. Measures for subcharacteristics of maintainability include the follow- Parametric cost modeling (mathematical models) ing [4*, p. 60]: has been applied to software maintenance. Of significance is that historical data from past main- • Analyzability: measures of the maintainer’s tenance are needed in order to use and calibrate effort or resources expended in trying either the mathematical models. Cost driver attributes to diagnose deficiencies or causes of failure affect the estimates. or to identify parts to be modified. • Changeability: measures of the maintainer’s 2.3.3. Experience effort associated with implementing a speci- [2*, c12s5.5] fied modification. • Stability: measures of the unexpected behav- Experience, in the form of expert judgment, ior of software, including that encountered is often used to estimate maintenance effort. during testing. Clearly, the best approach to maintenance esti- • Testability: measures of the maintainer’s and mation is to combine historical data and experi- users’ effort in trying to test the modified ence. The cost to conduct a modification (in terms software. of number of people and amount of time) is then • Other measures that maintainers use include derived. Maintenance estimation historical data • size of the software, should be provided as a result of a measurement • complexity of the software , program. • understandability, and • maintainability. 2.4. Software Maintenance Measurement [1*, c6s5] [2*, c12] Providing software maintenance effort, by categories, for different applications provides Entities related to software maintenance, whose business information to users and their organiza- attributes can be subjected to measurement, tions. It can also enable the comparison of soft- include process, resource, and product [2*, ware maintenance profiles internally within an c12s3.1]. organization. There are several software measures that can be derived from the attributes of the software, 3. Maintenance Process the maintenance process, and personnel, including size, complexity, quality, understandability, In addition to standard software engineering pro- maintainability, and effort. Complexity measures cesses and activities described in IEEE 14764, of software can also be obtained using available there are a number of activities that are unique to commercial tools. These measures constitute a maintainers. good starting point for the maintainer’s measurement program. Discussion of software process 3.1. Maintenance Processes and product measurement is also presented in the [1*, c5] [2*, c5] [5, s5.5] Software Engineering Process KA. The topic of a software measurement program is described in Maintenance processes provide needed activities the Software Engineering Management KA. and detailed inputs/outputs to those activities as described in IEEE 14764. The maintenance pro- 2.4.1. Specific Measures cess activities of IEEE 14764 are shown in Figure [2*, c12] 5.2. Software maintenance activities include

The maintainer must determine which measures • process implementation, are appropriate for a specific organization based • problem and modification analysis, on that organization’s own context. The software • modification implementation, 5-8 SWEBOK® Guide V3.0

• maintenance review/acceptance, activities and tasks are the responsibility of the • migration, and maintainer. As already noted, many maintenance • software retirement. activities are similar to those of software development. Maintainers perform analysis, design, coding, testing, and documentation. They must track requirements in their activities—just as is done in development—and update documentation as baselines change. IEEE 14764 recommends that when a maintainer uses a development process, it must be tailored to meet specific needs [1*, c5s3.2.2]. However, for software maintenance, some activities involve processes unique to software maintenance.

3.2.1. Unique Activities [1*, c3s10, c6s9, c7s2, c7s3] [2*, c6, c7]

There are a number of processes, activities, and practices that are unique to software maintenance:

• Program understanding: activities needed to obtain a general knowledge of what a software product does and how the parts work together. Figure 5.2. Software Maintenance Process • Transition: a controlled and coordinated sequence of activities during which software Other maintenance process models include: is transferred progressively from the developer to the maintainer. • quick fix, • Modification request acceptance/rejection: • spiral, modifications requesting work beyond a cer- • Osborne’s, tain size/effort/complexity may be rejected • iterative enhancement, and by maintainers and rerouted to a developer. • reuse-oriented. • Maintenance help desk: an end-user and maintenance coordinated support function Recently, agile methodologies, which promote that triggers the assessment, prioritization, light processes, have been also adapted to main- and costing of modification requests. tenance. This requirement emerges from the ever- • Impact analysis: a technique to identify areas increasing demand for fast turnaround of main- impacted by a potential change; tenance services. Improvement to the software • Maintenance Service-Level Agreements maintenance process is supported by specialized (SLAs) and maintenance licenses and con- software maintenance capability maturity models tracts: contractual agreements that describe (see [6] and [7], which are briefly annotated in the the services and quality objectives. Further Readings section). 3.2.2. Supporting Activities 3.2. Maintenance Activities [1*, c4s1, c5, c6s7] [2*, c9] [1*, c5, c6s8.2, c7s3.3] Maintainers may also perform support activities, The maintenance process contains the activities such as documentation, software configuration and tasks necessary to modify an existing soft- management, verification and validation, problem ware product while preserving its integrity. These resolution, software quality assurance, reviews, Software Maintenance 5-9

and audits. Another important support activity • identification of the software maintenance consists of training the maintainers and users. organization, and • estimate of software maintenance costs. 3.2.3. Maintenance Planning Activities [1*, c7s3] The next step is to develop a corresponding software maintenance plan. This plan should be An important activity for software maintenance is prepared during software development and should planning, and maintainers must address the issues specify how users will request software modifica- associated with a number of planning perspec- tions or report problems. Software maintenance tives, including planning is addressed in IEEE 14764. It provides guidelines for a maintenance plan. Finally, at • business planning (organizational level), the highest level, the maintenance organization • maintenance planning (transition level), will have to conduct business planning activities • release/version planning (software level), and (budgetary, financial, and human resources) just • individual software change request planning like all the other divisions of the organization. (request level). Management is discussed in the chapter Related Disciplines of Software Engineering. At the individual request level, planning is carried out during the impact analysis (see sec- 3.2.4. Software Configuration Management tion 2.1.3, Impact Analysis). The release/version [1*, c5s1.2.3] [2*, c11] planning activity requires that the maintainer: IEEE 14764 describes software configuration • collect the dates of availability of individual management as a critical element of the mainte- requests, nance process. Software configuration manage- • agree with users on the content of subsequent ment procedures should provide for the verifica- releases/versions, tion, validation, and audit of each step required • identify potential conflicts and develop to identify, authorize, implement, and release the alternatives, software product. • assess the risk of a given release and develop It is not sufficient to simply track modifica- a back-out plan in case problems should tion requests or problem reports. The software arise, and product and any changes made to it must be con- • inform all the stakeholders. trolled. This control is established by implementing and enforcing an approved software configu- Whereas software development projects can ration management (SCM) process. The Software typically last from some months to a few years, Configuration Management KA provides details the maintenance phase usually lasts for many of SCM and discusses the process by which soft- years. Making estimates of resources is a key ele- ware change requests are submitted, evaluated, ment of maintenance planning. Software main- and approved. SCM for software maintenance is tenance planning should begin with the decision different from SCM for software development in to develop a new software product and should the number of small changes that must be con- consider quality objectives. A concept document trolled on operational software. The SCM pro- should be developed, followed by a maintenance cess is implemented by developing and following plan. The maintenance concept for each software a software configuration management plan and product needs to be documented in the plan [1*, operating procedures. Maintainers participate in c7s2] and should address the Configuration Control Boards to determine the content of the next release/version. • scope of the software maintenance, • adaptation of the software maintenance process, 5-10 SWEBOK® Guide V3.0

3.2.5. Software Quality 4.3. Reverse Engineering [1*, c6s5, c6s7, c6s8] [2*, c12s5.3] [1*, c6s2] [2*, c7, c14s5]

It is not sufficient to simply hope that increased Reverse engineering is the process of analyzing quality will result from the maintenance of soft- software to identify the software’s components ware. Maintainers should have a software qual- and their inter-relationships and to create repre- ity program. It must be planned and processes sentations of the software in another form or at must be implemented to support the maintenance higher levels of abstraction. Reverse engineer- process. The activities and techniques for Soft- ing is passive; it does not change the software ware Quality Assurance (SQA), V&V, reviews, or result in new software. Reverse engineer- and audits must be selected in concert with all ing efforts produce call graphs and control flow the other processes to achieve the desired level graphs from source code. One type of reverse of quality. It is also recommended that the main- engineering is redocumentation. Another type is tainer adapt the software development processes, design recovery. Finally, data reverse engineer- techniques and deliverables (for instance, testing ing, where logical schemas are recovered from documentation), and test results. More details can physical databases, has grown in importance over be found in the Software Quality KA. the last few years. Tools are key for reverse engineering and related tasks such as redocumenta- 4. Techniques for Maintenance tion and design recovery.

This topic introduces some of the generally 4.4. Migration accepted techniques used in software maintenance. [1*, c5s5]

4.1. Program Comprehension During software’s life, it may have to be modi- [2*, c6, c14s5] fied to run in different environments. In order to migrate it to a new environment, the maintainer Programmers spend considerable time reading and needs to determine the actions needed to accom- understanding programs in order to implement plish the migration, and then develop and docu- changes. Code browsers are key tools for program ment the steps required to effect the migration in comprehension and are used to organize and pres- a migration plan that covers migration require- ent source code. Clear and concise documentation ments, migration tools, conversion of product can also aid in program comprehension. and data, execution, verification, and support. Migrating software can also entail a number of 4.2. Reengineering additional activities such as [2*, c7] • notification of intent: a statement of why Reengineering is defined as the examination and the old environment is no longer to be sup- alteration of software to reconstitute it in a new ported, followed by a description of the new form, and includes the subsequent implementa- environment and its date of availability; tion of the new form. It is often not undertaken to • parallel operations: make available the improve maintainability but to replace aging leg- old and new environments so that the user acy software. Refactoring is a reengineering tech- experiences a smooth transition to the new nique that aims at reorganizing a program without environment; changing its behavior. It seeks to improve a pro- • notification of completion: when the sched- gram structure and its maintainability. Refactor- uled migration is completed, a notification is ing techniques can be used during minor changes. sent to all concerned; Software Maintenance 5-11

• postoperation review: an assessment of par- • program slicers, which select only parts of a allel operation and the impact of changing to program affected by a change; the new environment; • static analyzers, which allow general view- • data archival: storing the old software data. ing and summaries of a program content; • dynamic analyzers, which allow the main- 4.5. Retirement tainer to trace the execution path of a [1*, c5s6] program; • data flow analyzers, which allow the main- Once software has reached the end of its use- tainer to track all possible data flows of a ful life, it must be retired. An analysis should program; be performed to assist in making the retirement • cross-referencers, which generate indices of decision. This analysis should be included in the program components; and retirement plan, which covers retirement require- • dependency analyzers, which help maintain- ments, impact, replacement, schedule, and effort. ers analyze and understand the interrelation- Accessibility of archive copies of data may also ships between components of a program. be included. Retiring software entails a number of activities similar to migration. Reverse engineering tools assist the process by working backwards from an existing product to 5. Software Maintenance Tools create artifacts such as specification and design [1*, c6s4] [2*, c14] descriptions, which can then be transformed to generate a new product from an old one. Main- This topic encompasses tools that are particularly tainers also use software test, software configura- important in software maintenance where exist- tion management, software documentation, and ing software is being modified. Examples regard- software measurement tools. ing program comprehension include 5-12 SWEBOK® Guide V3.0

MATRIX OF TOPICS VS. REFERENCE MATERIAL [1*] [2*] [3*] Sneed 2008 Grubb and Takang 2003Grubb and Takang IEEE/ISO/IEC 2006 14764

1. Software Maintenance Fundamentals 1.1. Definitions and Terminology c3 c1s2, c2s2 1.2. Nature of Maintenance c1s3 1.3. Need for Maintenance c1s5 1.4. Majority of Maintenance Costs c4s3, c5s5.2 1.5. Evolution of Software c3s5 1.6. Categories of Maintenance c3, c6s2 c3s3.1, c4s3 2. Key Issues in Software Maintenance 2.1. Technical Issues 2.1.1. Limited Understanding c6 2.1.2. Testing c6s2.2.2 c9 2.1.3. Impact Analysis c5s2.5 c13s3 2.1.4. Maintainability c6s8, c3s4 c12s5.5 2.2. Management Issues 2.2.1. Alignment with c4 Organizational objectives 2.2.2. Staffing c4s5, c10s4 2.2.3. Process c5 c5 2.2.4. Organizational Aspects of c7s.2.3 c10 Maintenance 2.2.5. Outsourcing/Offshoring all 2.3. Maintenance Cost Estimation 2.3.1. Cost Estimation c7s4.1 c7s2.4 Software Maintenance 5-13 [1*] [2*] [3*] Sneed 2008 Grubb and Takang 2003Grubb and Takang IEEE/ISO/IEC 2006 14764

2.3.2. Parametric Models c12s5.6 2.3.3. Experience c12s5.5 2.4. Software Maintenance c6s5 c12, c12s3.1 Measurement 2.4.1. Specific Measures c12 3. Maintenance Process 3.1. Maintenance Processes c5 c5 c5, c5s3.2.2, 3.2. Maintenance Activities c6s8.2, c7s3.3 c3s10, c6s9, c7s2, 3.2.1. Unique Activities c6,c7 c7s3 3.2.2. Supporting Activities c4s1, c5, c6s7 c9 3.2.3. Maintenance Planning c7s2, c7s.3 Activities 3.2.4. Software Configuration c5s1.2.3 c11 Management 3.2.5. Software Quality c6s5, c6s7, c6s8 c12s5.3 4. Techniques for Maintenance 4.1. Program Comprehension c6,c14s5 4.2. Reengineering c7 4.3. Reverse Engineering c6s2 c7, c14s5 4.4. Migration c5s5 4.5. Retirement c5s6 5. Software Maintenance Tools c6s4 c14 5-14 SWEBOK® Guide V3.0

FURTHER READINGS REFERENCES

A. April and A. Abran, Software Maintenance [1*] IEEE Std. 14764-2006 (a.k.a. ISO/IEC Management: Evaluation and Continuous 14764:2006) Standard for Software Improvement [6]. Engineering—Software Life Cycle Processes—Maintenance, IEEE, 2006. This book explores the domain of small software maintenance processes (S3M). It provides road- [2*] P. Grubb and A.A. Takang, Software maps for improving software maintenance pro- Maintenance: Concepts and Practice, 2nd cesses in organizations. It describes a software ed., World Scientific Publishing, 2003. maintenance specific maturity model organized by levels which allow for benchmarking and con- [3*] H.M. Sneed, “Offering Software tinuous improvement. Goals for each key prac- Maintenance as an Offshore Service,” Proc. tice area are provided, and the process model pre- IEEE Int’l Conf. Software Maintenance sented is fully aligned with the architecture and (ICSM 08), IEEE, 2008, pp. 1–5. framework of international standards ISO12207, ISO14764 and ISO15504 and popular maturity [4*] J.W. Moore, The Road Map to Software models like ITIL, CoBIT, CMMI and CM3. Engineering: A Standards-Based Guide, Wiley-IEEE Computer Society Press, 2006. M. Kajko-Mattsson, “Towards a Business Maintenance Model,” IEEE Int’l Conf. [5] ISO/IEC/IEEE 24765:2010 Systems and Software Maintenance [7]. Software Engineering—Vocabulary, ISO/ IEC/IEEE, 2010. This paper presents an overview of the Correc- tive Maintenance Maturity Model (CM3). In [6] A. April and A. Abran, Software contrast to other process models, CM3 is a spe- Maintenance Management: Evaluation cialized model, entirely dedicated to corrective and Continuous Improvement, Wiley-IEEE maintenance of software. It views maintenance in Computer Society Press, 2008. terms of the activities to be performed and their order, in terms of the information used by these [7] M. Kajko-Mattsson, “Towards a Business activities, goals, rules and motivations for their Maintenance Model,” Proc. Int’l Conf. execution, and organizational levels and roles Software Maintenance, IEEE, 2001, pp. involved at various stages of a typical corrective 500–509. maintenance process. CHAPTER 6

SOFTWARE CONFIGURATION MANAGEMENT

ACRONYMS to serve a particular purpose. Configuration management (CM), then, is the discipline of identify- CCB Configuration Control Board ing the configuration of a system at distinct points CM Configuration Management in time for the purpose of systematically control- FCA Functional Configuration Audit ling changes to the configuration and maintaining the integrity and traceability of the configuration PCA Physical Configuration Audit throughout the system life cycle. It is formally Software Configuration Control defined as SCCB Board A discipline applying technical and admin- SCI Software Configuration Item istrative direction and surveillance to: iden- Software Configuration SCM tify and document the functional and physi- Management cal characteristics of a configuration item, Software Configuration control changes to those characteristics, SCMP Management Plan record and report change processing and SCR Software Change Request implementation status, and verify compliance with specified requirements. [1] Software Configuration Status SCSA Accounting Software configuration management (SCM) SDD Software Design Document is a supporting-software life cycle process that Software Engineering Institute’s benefits project management, development and SEI/ Capability Maturity Model maintenance activities, quality assurance activi- CMMI Integration ties, as well as the customers and users of the end SQA Software Quality Assurance product. The concepts of configuration management Software Requirement SRS apply to all items to be controlled, although there Specification are some differences in implementation between hardware CM and software CM. SCM is closely related to the software qual- INTRODUCTION ity assurance (SQA) activity. As defined in the Software Quality knowledge area (KA), SQA A system can be defined as the combination of processes provide assurance that the software interacting elements organized to achieve one or products and processes in the project life cycle more stated purposes [1]. The configuration of a conform to their specified requirements by plan- system is the functional and physical characteris- ning, enacting, and performing a set of activities tics of hardware or software as set forth in techni- to provide adequate confidence that quality is cal documentation or achieved in a product [1]; it being built into the software. SCM activities help can also be thought of as a collection of specific in accomplishing these SQA goals. In some proj- versions of hardware, firmware, or software items ect contexts, specific SQA requirements prescribe combined according to specific build procedures certain SCM activities.

6-1 6-2 SWEBOK® Guide V3.0

Figure 6.1. Breakdown of Topics for the Software Configuration Management KA

The SCM activities are management and plan- development and change implementation activi- ning of the SCM process, software configuration ties. A successful SCM implementation requires identification, software configuration control, careful planning and management. This, in turn, software configuration status accounting, soft- requires an understanding of the organizational ware configuration auditing, and software release context for, and the constraints placed on, the management and delivery. design and implementation of the SCM process. The Software Configuration Management KA is related to all the other KAs, since the object 1.1. Organizational Context for SCM of configuration management is the artifact pro- [2*, c6, ann. D] [3*, introduction] [4*, c29] duced and used throughout the software engineering process. To plan an SCM process for a project, it is necessary to understand the organizational context and BREAKDOWN OF TOPICS FOR the relationships among organizational elements. SOFTWARE CONFIGURATION SCM interacts with several other activities or MANAGEMENT organizational elements. The organizational elements responsible for the The breakdown of topics for the Software Config- software engineering supporting processes may be uration Management KA is shown in Figure 6.1. structured in various ways. Although the responsibility for performing certain SCM tasks might be 1. Management of the SCM Process assigned to other parts of the organization (such as the development organization), the overall respon- SCM controls the evolution and integrity of a sibility for SCM often rests with a distinct organi- product by identifying its elements; managing and zational element or designated individual. controlling change; and verifying, recording, and Software is frequently developed as part of a reporting on configuration information. From the larger system containing hardware and firmware software engineer’s perspective, SCM facilitates elements. In this case, SCM activities take place Software Configuration Management 6-3

in parallel with hardware and firmware CM activ- engineering issued by the various standards orga- ities and must be consistent with system-level nizations (see Appendix B on standards). CM. Note that firmware contains hardware and software; therefore, both hardware and software 1.3. Planning for SCM CM concepts are applicable. [2*, c6, ann. D, ann. E] [3*, c23] [4*, c29] SCM might interface with an organization’s quality assurance activity on issues such as The planning of an SCM process for a given records management and nonconforming items. project should be consistent with the organi- Regarding the former, some items under SCM zational context, applicable constraints, com- control might also be project records subject to monly accepted guidance, and the nature of the provisions of the organization’s quality assurance project (for example, size, safety criticality, and program. Managing nonconforming items is usu- security). The major activities covered are soft- ally the responsibility of the quality assurance ware configuration identification, software- con activity; however, SCM might assist with track- figuration control, software configuration status ing and reporting on software configuration items accounting, software configuration auditing, and falling into this category. software release management and delivery. In Perhaps the closest relationship is with the addition, issues such as organization and respon- software development and maintenance orga- sibilities, resources and schedules, tool selection nizations. It is within this context that many of and implementation, vendor and subcontractor the software configuration control tasks are con- control, and interface control are typically conducted. Frequently, the same tools support devel- sidered. The results of the planning activity are opment, maintenance, and SCM purposes. recorded in an SCM Plan (SCMP), which is typically subject to SQA review and audit. 1.2. Constraints and Guidance for the SCM Branching and merging strategies should be Process carefully planned and communicated, since they [2*, c6, ann. D, ann. E] [3*, c2, c5] impact many SCM activities. From an SCM stand- [5*, c19s2.2] point, a branch is defined as a set of evolving source file versions [1]. Merging consists in combining Constraints affecting, and guidance for, the SCM different changes to the same file [1]. This typi- process come from a number of sources. Poli- cally occurs when more than one person changes a cies and procedures set forth at corporate or other configuration item. There are many branching and organizational levels might influence or prescribe merging strategies in common use (see the Further the design and implementation of the SCM pro- Readings section for additional discussion). cess for a given project. In addition, the contract The software development life cycle model between the acquirer and the supplier might con- (see Software Life Cycle Models in the Software tain provisions affecting the SCM process. For Engineering Process KA) also impacts SCM example, certain configuration audits might be activities, and SCM planning should take this required, or it might be specified that certain items into account. For instance, continuous integration be placed under CM. When software products to is a common practice in many software develop- be developed have the potential to affect public ment approaches. It is typically characterized by safety, external regulatory bodies may impose frequent build-test-deploy cycles. SCM activities constraints. Finally, the particular software life must be planned accordingly. cycle process chosen for a software project and the level of formalism selected to implement the 1.3.1. SCM Organization and Responsibilities software affect the design and implementation of [2*, ann. Ds5, ann. Ds6] [3*, c10-11] the SCM process. [4*, introduction, c29] Guidance for designing and implementing an SCM process can also be obtained from “best To prevent confusion about who will perform practice,” as reflected in the standards on software given SCM activities or tasks, organizational 6-4 SWEBOK® Guide V3.0

roles to be involved in the SCM process need • Future: what is the plan for the tools’ use in to be clearly identified. Specific responsibilities the future? for given SCM activities or tasks also need to be • Change: how adaptable are the tools? assigned to organizational entities, either by title • Branching and merging: are the tools’ capa- or by organizational element. The overall author- bilities compatible with the planned branch- ity and reporting channels for SCM should also be ing and merging strategies? identified, although this might be accomplished • Integration: do the various SCM tools inte- at the project management or quality assurance grate among themselves? With other tools in planning stage. use in the organization? • Migration: can the repository maintained by 1.3.2. SCM Resources and Schedules the version control tool be ported to another [2*, ann. Ds8] [3*, c23] version control tool while maintaining complete history of the configuration items it Planning for SCM identifies the staff and tools contains? involved in carrying out SCM activities and tasks. It addresses scheduling questions by establishing SCM typically requires a set of tools, as necessary sequences of SCM tasks and identify- opposed to a single tool. Such tool sets are some- ing their relationships to the project schedules times referred to as workbenches. In such a con- and milestones established at the project manage- text, another important consideration in plan- ment planning stage. Any training requirements ning for tool selection is determining if the SCM necessary for implementing the plans and train- workbench will be open (in other words, tools ing new staff members are also specified. from different suppliers will be used in different activities of the SCM process) or integrated 1.3.3. Tool Selection and Implementation (where elements of the workbench are designed [3*, c26s2, c26s6] [4*, c29s5] to work together). The size of the organization and the type of As for any area of software engineering, the projects involved may also impact tool selection selection and implementation of SCM tools (see topic 7, Software Configuration Manage- should be carefully planned. The following ques- ment Tools). tions should be considered: 1.3.4. Vendor/Subcontractor Control • Organization: what motivates tool acquisi- [2*, c13] [3*, c13s9, c14s2] tion from an organizational perspective? • Tools: can we use commercial tools or A software project might acquire or make use of develop them ourselves? purchased software products, such as compilers • Environment: what are the constraints or other tools. SCM planning considers if and imposed by the organization and its techni- how these items will be taken under configura- cal context? tion control (for example, integrated into the proj- • Legacy: how will projects use (or not) the ect libraries) and how changes or updates will be new tools? evaluated and managed. • Financing: who will pay for the tools’ Similar considerations apply to subcontracted acquisition, maintenance, training, and software. When using subcontracted software, customization? both the SCM requirements to be imposed on • Scope: how will the new tools be deployed— the subcontractor’s SCM process as part of the for instance, through the entire organization subcontract and the means for monitoring com- or only on specific projects? pliance need to be established. The latter includes • Ownership: who is responsible for the intro- consideration of what SCM information must be duction of new tools? available for effective compliance monitoring. Software Configuration Management 6-5

1.3.5. Interface Control • SCM Schedules (coordination with other [2*, c12] [3*, c24s4] project activities) • SCM Resources (tools, physical resources, When a software item will interface with and human resources) another software or hardware item, a change • SCMP Maintenance. to either item can affect the other. Planning for the SCM process considers how the interfacing 1.5. Surveillance of Software Configuration items will be identified and how changes to the Management items will be managed and communicated. The [3*, c11s3] SCM role may be part of a larger, system-level process for interface specification and control; After the SCM process has been implemented, it may involve interface specifications, interface some degree of surveillance may be necessary control plans, and interface control documents. to ensure that the provisions of the SCMP are In this case, SCM planning for interface control properly carried out. There are likely to be spe- takes place within the context of the system- cific SQA requirements for ensuring compliance level process. with specified SCM processes and procedures. The person responsible for SCM ensures that 1.4. SCM Plan those with the assigned responsibility perform [2*, ann. D] [3*, c23] [4*, c29s1] the defined SCM tasks correctly. The software quality assurance authority, as part of a compli- The results of SCM planning for a given project ance auditing activity, might also perform this are recorded in a software configuration manage- surveillance. ment plan (SCMP), a “living document” which The use of integrated SCM tools with process serves as a reference for the SCM process. It is control capability can make the surveillance maintained (that is, updated and approved) as task easier. Some tools facilitate process com- necessary during the software life cycle. In imple- pliance while providing flexibility for the soft- menting the SCMP, it is typically necessary to ware engineer to adapt procedures. Other tools develop a number of more detailed, subordinate enforce process, leaving the software engineer procedures defining how specific requirements with less flexibility. Surveillance requirements will be carried out during day-to-day activities— and the level of flexibility to be provided to the for example, which branching strategies will be software engineer are important considerations used and how frequently builds occur and auto- in tool selection. mated tests of all kinds are run. Guidance on the creation and maintenance of 1.5.1. SCM Measures and Measurement an SCMP, based on the information produced by [3*, c9s2, c25s2–s3] the planning activity, is available from a number of sources, such as [2*]. This reference provides SCM measures can be designed to provide spe- requirements for the information to be contained cific information on the evolving product orto in an SCMP; it also defines and describes six cat- provide insight into the functioning of the SCM egories of SCM information to be included in an process. A related goal of monitoring the SCM SCMP: process is to discover opportunities for process improvement. Measurements of SCM processes • Introduction (purpose, scope, terms used) provide a good means for monitoring the effec- • SCM Management (organization, respon- tiveness of SCM activities on an ongoing basis. sibilities, authorities, applicable policies, These measurements are useful in characteriz- directives, and procedures) ing the current state of the process as well as in • SCM Activities (configuration identification, providing a basis for making comparisons over configuration control, and so on) time. Analysis of the measurements may produce 6-6 SWEBOK® Guide V3.0

insights leading to process changes and corre- This involves understanding the software config- sponding updates to the SCMP. uration within the context of the system configu- Software libraries and the various SCM tool ration, selecting software configuration items, capabilities provide sources for extracting infor- developing a strategy for labeling software items mation about the characteristics of the SCM and describing their relationships, and identifying process (as well as providing project and man- both the baselines to be used and the procedure agement information). For example, information for a baseline’s acquisition of the items. about the time required to accomplish various types of changes would be useful in an evalua- 2.1.1. Software Configuration tion of the criteria for determining what levels of [1, c3] authority are optimal for authorizing certain types of changes and for estimating future changes. Software configuration is the functional and phys- Care must be taken to keep the focus of the ical characteristics of hardware or software as set surveillance on the insights that can be gained forth in technical documentation or achieved in from the measurements, not on the measurements a product. It can be viewed as part of an overall themselves. Discussion of software process and system configuration. product measurement is presented in the Soft- ware Engineering Process KA. Software mea- 2.1.2. Software Configuration Item surement programs are described in the Software [4*, c29s1.1] Engineering Management KA. A configuration item (CI) is an item or aggre- 1.5.2. In-Process Audits of SCM gation of hardware or software or both that is [3*, c1s1] designed to be managed as a single entity. A software configuration item (SCI) is a software entity Audits can be carried out during the software that has been established as a configuration item engineering process to investigate the current sta- [1]. The SCM typically controls a variety of items tus of specific elements of the configuration or to in addition to the code itself. Software items with assess the implementation of the SCM process. potential to become SCIs include plans, specifi- In-process auditing of SCM provides a more for- cations and design documentation, testing mate- mal mechanism for monitoring selected aspects rials, software tools, source and executable code, of the process and may be coordinated with the code libraries, data and data dictionaries, and SQA function (see topic 5, Software Configura- documentation for installation, maintenance, tion Auditing). operations, and software use. Selecting SCIs is an important process in 2. Software Configuration Identification which a balance must be achieved between pro- [2*, c8] [4*, c29s1.1] viding adequate visibility for project control purposes and providing a manageable number of Software configuration identification identifies controlled items. items to be controlled, establishes identification schemes for the items and their versions, and 2.1.3. Software Configuration Item establishes the tools and techniques to be used in Relationships acquiring and managing controlled items. These [3*, c7s4] activities provide the basis for the other SCM activities. Structural relationships among the selected SCIs, and their constituent parts, affect other 2.1. Identifying Items to Be Controlled SCM activities or tasks, such as software [2*, c8s2.2] [4*, c29s1.1] building or analyzing the impact of proposed changes. Proper tracking of these relationships One of the first steps in controlling change is is also important for supporting traceability. identifying the software items to be controlled. The design of the identification scheme for SCIs Software Configuration Management 6-7

Figure 6.2. Acquisition of Items should consider the need to map identified items baselines. The functional baseline corresponds to the software structure, as well as the need to to the reviewed system requirements. The allo- support the evolution of the software items and cated baseline corresponds to the reviewed their relationships. software requirements specification and software interface requirements specification. The 2.1.4. Software Version developmental baseline represents the evolving [1, c3] [4*, c29s3] software configuration at selected times during the software life cycle. Change authority for Software items evolve as a software project pro- this baseline typically rests primarily with the ceeds. A version of a software item is an identi- development organization but may be shared fied instance of an item. It can be thought of as a with other organizations (for example, SCM or state of an evolving item. A variant is a version of Test). The product baseline corresponds to the a program resulting from the application of soft- completed software product delivered for sys- ware diversity. tem integration. The baselines to be used for a given project, along with the associated levels of 2.1.5. Baseline authority needed for change approval, are typi- [1, c3] cally identified in the SCMP.

A software baseline is a formally approved ver- 2.1.6. Acquiring Software Configuration Items sion of a configuration item (regardless of media) [3*, c18] that is formally designated and fixed at a specific time during the configuration item’s life cycle. Software configuration items are placed under The term is also used to refer to a particular ver- SCM control at different times; that is, they are sion of a software configuration item that has incorporated into a particular baseline at a particu- been agreed on. In either case, the baseline can lar point in the software life cycle. The triggering only be changed through formal change con- event is the completion of some form of formal trol procedures. A baseline, together with all acceptance task, such as a formal review. Figure approved changes to the baseline, represents the 6.2 characterizes the growth of baselined items as current approved configuration. the life cycle proceeds. This figure is based on the Commonly used baselines include func- waterfall model for purposes of illustration only; tional, allocated, developmental, and product the subscripts used in the figure indicate versions 6-8 SWEBOK® Guide V3.0

of the evolving items. The software change request what changes to make, the authority for approv- (SCR) is described in section 3.1. ing certain changes, support for the implementa- In acquiring an SCI, its origin and initial integ- tion of those changes, and the concept of formal rity must be established. Following the acquisi- deviations from project requirements as well as tion of an SCI, changes to the item must be for- waivers of them. Information derived from these mally approved as appropriate for the SCI and activities is useful in measuring change traffic the baseline involved, as defined in the SCMP. and breakage as well as aspects of rework. Following approval, the item is incorporated into the software baseline according to the appropriate 3.1. Requesting, Evaluating, and Approving procedure. Software Changes [2*, c9s2.4] [4*, c29s2] 2.2. Software Library [3*, c1s3] [4*, c29s1.2] The first step in managing changes to controlled items is determining what changes to make. The A software library is a controlled collection of software change request process (see a typical software and related documentation designed to flow of a change request process in Figure 6.3) aid in software development, use, or maintenance provides formal procedures for submitting and [1]. It is also instrumental in software release man- recording change requests, evaluating the poten- agement and delivery activities. Several types of tial cost and impact of a proposed change, and libraries might be used, each corresponding to the accepting, modifying, deferring, or rejecting software item’s particular level of maturity. For the proposed change. A change request (CR) is example, a working library could support coding a request to expand or reduce the project scope; and a project support library could support test- modify policies, processes, plans, or procedures; ing, while a master library could be used for fin- modify costs or budgets; or revise schedules ished products. An appropriate level of SCM con- [1]. Requests for changes to software configura- trol (associated baseline and level of authority for tion items may be originated by anyone at any change) is associated with each library. Security, point in the software life cycle and may include in terms of access control and the backup facili- a suggested solution and requested priority. One ties, is a key aspect of library management. source of a CR is the initiation of corrective The tool(s) used for each library must support action in response to problem reports. Regardless the SCM control needs for that library—both in of the source, the type of change (for example, terms of controlling SCIs and controlling access defect or enhancement) is usually recorded on the to the library. At the working library level, this is Software CR (SCR). a code management capability serving develop- This provides an opportunity for tracking ers, maintainers, and SCM. It is focused on man- defects and collecting change activity measure- aging the versions of software items while sup- ments by change type. Once an SCR is received, porting the activities of multiple developers. At a technical evaluation (also known as an impact higher levels of control, access is more restricted analysis) is performed to determine the extent of and SCM is the primary user. the modifications that would be necessary should These libraries are also an important source the change request be accepted. A good under- of information for measurements of work and standing of the relationships among software progress. (and, possibly, hardware) items is important for this task. Finally, an established authority—com- 3. Software Configuration Control mensurate with the affected baseline, the SCI [2*, c9] [4*, c29s2] involved, and the nature of the change—will evaluate the technical and managerial aspects Software configuration control is concerned of the change request and either accept, modify, with managing changes during the software reject, or defer the proposed change. life cycle. It covers the process for determining Software Configuration Management 6-9

Figure 6.3. Flow of a Change Control Process

3.1.1. Software Configuration Control Board CCB decisions, and reporting change process [2*, c9s2.2] [3*, c11s1] [4*, c29s2] information. A link between this tool capability and the problem-reporting system can facilitate The authority for accepting or rejecting proposed the tracking of solutions for reported problems. changes rests with an entity typically known as a Configuration Control Board (CCB). In smaller 3.2. Implementing Software Changes projects, this authority may actually reside with [4*, c29] the leader or an assigned individual rather than a multiperson board. There can be multiple levels Approved SCRs are implemented using the of change authority depending on a variety of cri- defined software procedures in accordance with teria—such as the criticality of the item involved, the applicable schedule requirements. Since a the nature of the change (for example, impact on number of approved SCRs might be implemented budget and schedule), or the project’s current simultaneously, it is necessary to provide a means point in the life cycle. The composition of the for tracking which SCRs are incorporated into CCBs used for a given system varies depending particular software versions and baselines. As on these criteria (an SCM representative would part of the closure of the change process, com- always be present). All stakeholders, appropriate pleted changes may undergo configuration audits to the level of the CCB, are represented. When and software quality verification—this includes the scope of authority of a CCB is strictly soft- ensuring that only approved changes have been ware, it is known as a Software Configuration made. The software change request process Control Board (SCCB). The activities of the CCB described above will typically document the are typically subject to software quality audit or SCM (and other) approval information for the review. change. Changes may be supported by source code ver- 3.1.2. Software Change Request Process sion control tools. These tools allow a team of [3*, c1s4, c8s4] software engineers, or a single software engineer, to track and document changes to the source code. An effective software change request (SCR) pro- These tools provide a single repository for storing cess requires the use of supporting tools and pro- the source code, can prevent more than one soft- cedures for originating change requests, enforc- ware engineer from editing the same module at ing the flow of the change process, capturing the same time, and record all changes made to the 6-10 SWEBOK® Guide V3.0

source code. Software engineers check modules information system, the configuration status infor- out of the repository, make changes, document mation to be managed for the evolving configura- the changes, and then save the edited modules tions must be identified, collected, and maintained. in the repository. If needed, changes can also be Various information and measurements are needed discarded, restoring a previous baseline. More to support the SCM process and to meet the con- powerful tools can support parallel development figuration status reporting needs of management, and geographically distributed environments. software engineering, and other related activities. These tools may be manifested as separate, The types of information available include the specialized applications under the control of an approved configuration identification as well as independent SCM group. They may also appear the identification and current implementation sta- as an integrated part of the software engineering tus of changes, deviations, and waivers. environment. Finally, they may be as elementary Some form of automated tool support is neces- as a rudimentary change control system provided sary to accomplish the SCSA data collection and with an operating system. reporting tasks; this could be a database capability, a stand-alone tool, or a capability of a larger, 3.3. Deviations and Waivers integrated tool environment. [1, c3] 4.2. Software Configuration Status Reporting The constraints imposed on a software engineer- [2*, c10s2.4] [3*, c1s5, c9s1, c17] ing effort or the specifications produced during the development activities might contain provisions Reported information can be used by various that cannot be satisfied at the designated point organizational and project elements—including in the life cycle. A deviation is a written autho- the development team, the maintenance team, rization, granted prior to the manufacture of an project management, and software quality activi- item, to depart from a particular performance or ties. Reporting can take the form of ad hoc que- design requirement for a specific number of units ries to answer specific questions or the periodic or a specific period of time. A waiver is- awrit production of predesigned reports. Some infor- ten authorization to accept a configuration item or mation produced by the status accounting activity other designated item that is found, during produc- during the course of the life cycle might become tion or after having been submitted for inspection, quality assurance records. to depart from specified requirements but is nev- In addition to reporting the current status of the ertheless considered suitable for use as-is or after configuration, the information obtained by the rework by an approved method. In these cases, a SCSA can serve as a basis of various measure- formal process is used for gaining approval for ments. Examples include the number of change deviations from, or waivers of, the provisions. requests per SCI and the average time needed to implement a change request. 4. Software Configuration Status Accounting [2*, c10] 5. Software Configuration Auditing [2*, c11] Software configuration status accounting (SCSA) is an element of configuration management con- A software audit is an independent examina- sisting of the recording and reporting of information of a work product or set of work products to tion needed to manage a configuration effectively. assess compliance with specifications, standards, contractual agreements, or other criteria [1]. 4.1. Software Configuration Status Information Audits are conducted according to a well-defined [2*, c10s2.1] process consisting of various auditor roles and responsibilities. Consequently, each audit must The SCSA activity designs and operates a sys- be carefully planned. An audit can require a num- tem for the capture and reporting of necessary ber of individuals to perform a variety of tasks information as the life cycle proceeds. As in any over a fairly short period of time. Tools to support Software Configuration Management 6-11

the planning and conduct of an audit can greatly the development activity; this includes internal facilitate the process. releases as well as distribution to customers. When Software configuration auditing determines different versions of a software item are available the extent to which an item satisfies the required for delivery (such as versions for different plat- functional and physical characteristics. Informal forms or versions with varying capabilities), it is audits of this type can be conducted at key points frequently necessary to recreate specific versions in the life cycle. Two types of formal audits might and package the correct materials for delivery of be required by the governing contract (for exam- the version. The software library is a key element ple, in contracts covering critical software): the in accomplishing release and delivery tasks. Functional Configuration Audit (FCA) and the Physical Configuration Audit (PCA). Successful 6.1. Software Building completion of these audits can be a prerequisite [4*, c29s4] for the establishment of the product baseline. Software building is the activity of combining the 5.1. Software Functional Configuration Audit correct versions of software configuration items, [2*, c11s2.1] using the appropriate configuration data, into an executable program for delivery to a customer or The purpose of the software FCA is to ensure that other recipient, such as the testing activity. For the audited software item is consistent with its systems with hardware or firmware, the executable governing specifications. The output of the soft- program is delivered to the system-building activ- ware verification and validation activities (see ity. Build instructions ensure that the proper build Verification and Validation in the Software Qual- steps are taken in the correct sequence. In addition ity KA) is a key input to this audit. to building software for new releases, it is usually also necessary for SCM to have the capability to 5.2. Software Physical Configuration Audit reproduce previous releases for recovery, testing, [2*, c11s2.2] maintenance, or additional release purposes. Software is built using particular versions of The purpose of the software physical configura- supporting tools, such as compilers (see Com- tion audit (PCA) is to ensure that the design and piler Basics in the Computing Foundations KA). reference documentation is consistent with the It might be necessary to rebuild an exact copy of as-built software product. a previously built software configuration item. In this case, supporting tools and associated build 5.3. In-Process Audits of a Software Baseline instructions need to be under SCM control to [2*, c11s2.3] ensure availability of the correct versions of the tools. As mentioned above, audits can be carried out A tool capability is useful for selecting the cor- during the development process to investigate rect versions of software items for a given target the current status of specific elements of the con- environment and for automating the process of figuration. In this case, an audit could be applied building the software from the selected versions to sampled baseline items to ensure that per- and appropriate configuration data. For projects formance is consistent with specifications or to with parallel or distributed development envi- ensure that evolving documentation continues to ronments, this tool capability is necessary. Most be consistent with the developing baseline item. software engineering environments provide this capability. These tools vary in complexity from 6. Software Release Management and requiring the software engineer to learn a spe- Delivery cialized scripting language to graphics-oriented [2*, c14] [3*, c8s2] approaches that hide much of the complexity of an “intelligent” build facility. In this context, release refers to the distribu- The build process and products are often sub- tion of a software configuration item outside ject to software quality verification. Outputs of 6-12 SWEBOK® Guide V3.0

the build process might be needed for future refer- 7. Software Configuration Management Tools ence and may become quality assurance records. [3*, c26s1] [4*, c8s2]

6.2. Software Release Management When discussing software configuration manage- [4*, c29s3.2] ment tools, it is helpful to classify them. SCM tools can be divided into three classes in terms Software release management encompasses the of the scope at which they provide support: indi- identification, packaging, and delivery of the vidual support, project-related support, and com- elements of a product—for example, an execut- panywide-process support. able program, documentation, release notes, and Individual support tools are appropriate and configuration data. Given that product changes typically sufficient for small organizations or can occur on a continuing basis, one concern for development groups without variants of their release management is determining when to issue software products or other complex SCM require- a release. The severity of the problems addressed ments. They include: by the release and measurements of the fault densities of prior releases affect this decision. The • Version control tools: track, document, and packaging task must identify which product items store individual configuration items such as are to be delivered and then select the correct source code and external documentation. variants of those items, given the intended appli- • Build handling tools: in their simplest form, cation of the product. The information document- such tools compile and link an executable ing the physical contents of a release is known version of the software. More advanced as a version description document. The release building tools extract the latest version from notes typically describe new capabilities, known the version control software, perform qual- problems, and platform requirements necessary ity checks, run regression tests, and produce for proper product operation. The package to be various forms of reports, among other tasks. released also contains installation or upgrading • Change control tools: mainly support the instructions. The latter can be complicated by the control of change requests and events noti- fact that some current users might have versions fication (for example, change request status that are several releases old. In some cases, release changes, milestones reached). management might be required in order to track distribution of the product to various customers Project-related support tools mainly support or target systems—for example, in a case where workspace management for development teams the supplier was required to notify a customer of and integrators; they are typically able to sup- newly reported problems. Finally, a mechanism port distributed development environments. Such to ensure the integrity of the released item can be tools are appropriate for medium to large organi- implemented—for example by releasing a digital zations with variants of their software products signature with it. and parallel development but no certification A tool capability is needed for supporting requirements. these release management functions. It is use- Companywide-process support tools can typi- ful to have a connection with the tool capability cally automate portions of a companywide pro- supporting the change request process in order to cess, providing support for workflow manage- map release contents to the SCRs that have been ments, roles, and responsibilities. They are able received. This tool capability might also maintain to handle many items, data, and life cycles. Such information on various target platforms and on tools add to project-related support by supporting various customer environments. a more formal development process, including certification requirements. Software Configuration Management 6-13

MATRIX OF TOPICS VS. REFERENCE MATERIAL [4*] [2*] [3*] [5*] Hass 2003 Moore 2006 IEEE 828-2012 Sommerville 2011

1. Management of the SCM Process 1.1. Organizational Context for c6, ann.D introduction c29 SCM 1.2. Constraints and Guidance c6, ann.D, c2 c19s2.2 c29 intro for the SCM Process ann.E c6, ann.D, 1.3. Planning for SCM c23 c29 ann.E 1.3.1. SCM Organization and ann.Ds5–6 c10 –11 c29 intro Responsibilities 1.3.2. SCM Resources and ann.Ds8 c23 Schedules 1.3.3. Tool Selection and c26s2; s6 c29s5 Implementation 1.3.4. Vendor/Subcontractor c13 c13s9–c14s2 Control 1.3.5. Interface Control c12 c24s4 1.4. SCM Plan ann.D c23 c29s1 1.5. Surveillance of Software c11s3 Configuration Management 1.5.1. SCM Measures and c9s2; Measurement c25s2–s3 1.5.2. In-Process Audits of c1s1 SCM 2. Software Configuration c29s1.1 Identification 2.1. Identifying Items to Be c8s2.2 c29s1.1 Controlled 2.1.1. Software Configuration 2.1.2. Software Configuration c29s1.1 Item 2.1.3. Software Configuration c7s4 Item Relationships 2.1.4. Software Version c29s3 6-14 SWEBOK® Guide V3.0 [4*] [2*] [3*] [5*] Hass 2003 Moore 2006 IEEE 828-2012 Sommerville 2011

2.1.5. Baseline 2.1.6. Acquiring Software c18 Configuration Items 2.2. Software Library c1s3 c29s1.2 3. Software Configuration c9 c29s2 Control 3.1. Requesting, Evaluating, and c9s2.4 c29s2 Approving Software Changes 3.1.1. Software Configuration c9s2.2 c11s1 c29s2 Control Board 3.1.2. Software Change c1s4, c8s4 Request Process 3.2. Implementing Software c29 Changes 3.3. Deviations and Waivers 4. Software Configuration c10 Status Accounting 4.1. Software Configuration c10s2.1 Status Information 4.2. Software Configuration c1s5, c9s1, c10s2.4 Status Reporting c17 5. Software Configuration c11 Auditing 5.1. Software Functional c11s2.1 Configuration Audit 5.2. Software Physical c11s2.2 Configuration Audit 5.3. In-Process Audits of a c11s2.3 Software Baseline 6. Software Release c14 c8s2 c29s3 Management and Delivery 6.1. Software Building c29s4 6.2. Software Release c29s3.2 Management 7. Software Configuration c26s1 Management Tools Software Configuration Management 6-15

FURTHER READINGS REFERENCES

Stephen P. Berczuk and Brad Appleton, [1] ISO/IEC/IEEE 24765:2010 Systems and Software Configuration Management Software Engineering—Vocabulary, ISO/ Patterns: Effective Teamwork, Practical IEC/IEEE, 2010. Integration [6]. [2*] IEEE Std. 828-2012, Standard for This book expresses useful SCM practices and Configuration Management in Systems and strategies as patterns. The patterns can be imple- Software Engineering, IEEE, 2012. mented using various tools, but they are expressed in a tool-agnostic fashion. [3*] A.M.J. Hass, Configuration Management Principles and Practices, 1st ed., Addison- “CMMI for Development,” Version 1.3, pp. Wesley, 2003. 137–147 [7]. [4*] I. Sommerville, Software Engineering, 9th This model presents a collection of best prac- ed., Addison-Wesley, 2011. tices to help software development organizations improve their processes. At maturity level 2, it [5*] J.W. Moore, The Road Map to Software suggests configuration management activities. Engineering: A Standards-Based Guide, Wiley-IEEE Computer Society Press, 2006.

[6] S.P. Berczuk and B. Appleton, Software Configuration Management Patterns: Effective Teamwork, Practical Integration, Addison-Wesley Professional, 2003.

[7] CMMI Product Team, “CMMI for Development, Version 1.3,” Software Engineering Institute, 2010; http:// resources.sei.cmu.edu/library/asset-view. cfm?assetID=9661. CHAPTER 7

SOFTWARE ENGINEERING MANAGEMENT

ACRONYMS • Clients often don’t know what is needed or what is feasible. ® PMBOK Guide to the Project Management • Clients often lack appreciation for the com- Guide Body of Knowledge plexities inherent in software engineering, SDLC Software Development Life Cycle particularly regarding the impact of chang- SEM Software Engineering Management ing requirements. • It is likely that increased understanding and SQA Software Quality Assurance changing conditions will generate new or Software Extension to the PMBOK® changed software requirements. SWX Guide • As a result of changing requirements, soft- WBS Work Breakdown Structure ware is often built using an iterative process rather than as a sequence of closed tasks. • Software engineering necessarily incorpo- INTRODUCTION rates creativity and discipline. Maintaining an appropriate balance between the two is Software engineering management can be defined sometimes difficult. as the application of management activities—plan- • The degree of novelty and complexity is ning, coordinating, measuring, monitoring, con- often high. trolling, and reporting1—to ensure that software • There is often a rapid rate of change in the products and software engineering services are underlying technology. delivered efficiently, effectively, and to the benefit of stakeholders. The related discipline of manage- Software engineering management activities ment is an important element of all the knowledge occur at three levels: organizational and infra- areas (KAs), but it is of course more relevant to structure management, project management, this KA than to other KAs. Measurement is also an and management of the measurement program. important aspect of all KAs; the topic of measure- The last two are covered in detail in this KA ment programs is presented in this KA. description. However, this is not to diminish the In one sense, it should be possible to manage importance of organizational and infrastructure a software engineering project in the same way management issues. It is generally agreed that other complex endeavors are managed. However, software organizational engineering managers there are aspects specific to software projects should be conversant with the project manage- and software life cycle processes that complicate ment and software measurement knowledge effective management, including these: described in this KA. They should also possess some target domain knowledge. Likewise, it is also helpful if managers of complex projects and 1 The terms Initiating, Planning, Executing, programs in which software is a component of Monitoring and Controlling, and Closing are used to the system architecture are aware of the differ- describe process groups in the PMBOK® Guide and ences that software processes introduce into proj- SWX. ect management and project measurement.

7-1 7-2 SWEBOK® Guide V3.0

Figure 7.1. Breakdown of Topics for the Software Engineering Management KA

Other aspects of organizational management Another important aspect of organizational exert an impact on software engineering (for management is personnel management policies example, organizational policies and procedures and procedures for hiring, training, and mentor- that provide the framework in which software ing personnel for career development, not only at engineering projects are undertaken). These poli- the project level, but also to the longer-term suc- cies and procedures may need to be adjusted by cess of an organization. Software engineering per- the requirements for effective software develop- sonnel may present unique training or personnel ment and maintenance. In addition, a number of management challenges (for example, maintaining policies specific to software engineering may currency in a context where the underlying tech- need to be in place or established for effective nology undergoes rapid and continuous change). management of software engineering at the orga- Communication management is also often nizational level. For example, policies are usually mentioned as an overlooked but important aspect necessary to establish specific organization-wide of the performance of individuals in a field where processes or procedures for software engineering precise understanding of user needs, software tasks such as software design, software construc- requirements, and software designs is necessary. tion, estimating, monitoring, and reporting. Such Furthermore, portfolio management, which pro- policies are important for effective long-term vides an overall view, not only of software cur- management of software engineering projects rently under development in various projects and across an organization (for example, establishing programs (integrated projects), but also of soft- a consistent basis by which to analyze past proj- ware planned and currently in use in an organiza- ect performance and implement improvements). tion, is desirable. Also, software reuse is a key Software Engineering Management 7-3

factor in maintaining and improving productivity management—a basic principle of any true engi- and competitiveness. Effective reuse requires a neering discipline (see Measurement in the Engi- strategic vision that reflects the advantages and neering Foundations KA)—can help improve disadvantages of reuse. the perception and the reality. In essence, man- In addition to understanding the aspects of agement without measurement (qualitative and management that are uniquely influenced by soft- quantitative) suggests a lack of discipline, and ware projects, software engineers should have measurement without management suggests a some knowledge of the more general aspects of lack of purpose or context. Effective management management that are discussed in this KA (even requires a combination of both measurement and in the first few years after graduation). experience. Attributes of organizational culture and behav- The following working definitions are adopted ior, plus management of other functional areas here: of the enterprise, have an influence, albeit indi- rectly, on an organization’s software engineering • Management is a system of processes and processes. controls required to achieve the strategic Extensive information concerning software objectives set by the organization. project management can be found in the Guide • Measurement refers to the assignment of val- to the Project Management Body of Knowledge ues and labels to software engineering work (PMBOK® Guide) and the Software Extension to products, processes, and resources plus the the PMBOK® Guide (SWX) [1] [2]. Each of these models that are derived from them, whether guides includes ten project management KAs: these models are developed using statistical project integration management, project scope or other techniques [3* , c7, c8]. management, project time management, project cost management, project quality management, The software engineering project management project human resource management, project sections in this KA make extensive use of the communications management, project risk man- software engineering measurement section. agement, project procurement management, and This KA is closely related to others in the project stakeholder management. Each KA has SWEBOK Guide, and reading the following KA direct relevance to this Software Engineering descriptions in conjunction with this one will be Management KA. particularly helpful: Additional information is also provided in the other references and further readings for this KA. • The Engineering Foundations KA describes This Software Engineering Management KA some general concepts of measurement that consists of the software project management pro- are directly applicable to the Software Engi- cesses in the first five topics in Figure 7.1 (Initia- neering Measurement section of this KA. tion and Scope Definition, Software Project Plan- In addition, the concepts and techniques ning, Software Project Enactment, Review and presented in the Statistical Analysis section Evaluation, Closure), plus Software Engineering of the Engineering Foundations KA apply Measurement in the sixth topic and Software directly to many topics in this KA. Engineering Management Tools in the seventh • The Software Requirements KA describes topic. While project management and measure- some of the activities that should be per- ment management are often regarded as being formed during the Initiation and Scope defi- separate, and indeed each does possess many nition phase of the project. unique attributes, the close relationship has led to • The Software Configuration Management combined treatment in this KA. KA deals with identification, control, status Unfortunately, a common perception of the soft- accounting, and auditing of software con- ware industry is that software products are deliv- figurations along with software release man- ered late, over budget, of poor quality, and with agement and delivery and software configu- incomplete functionality. Measurement-informed ration management tools. 7-4 SWEBOK® Guide V3.0

• The Software Engineering Process KA implementation of measurement programs in describes software life cycle models and the software engineering organizations; relationships between processes and work • Software Engineering Management Tools, products. which describes the selection and use of tools • The Software Quality KA emphasizes qual- for managing a software engineering project. ity as a goal of management and as an aim of many software engineering activities. 1. Initiation and Scope Definition • The Software Engineering Economics KA discusses how to make software-related The focus of these activities is on effective deter- decisions in a business context. mination of software requirements using various elicitation methods and the assessment of BREAKDOWN OF TOPICS FOR project feasibility from a variety of standpoints. SOFTWARE ENGINEERING Once project feasibility has been established, the MANAGEMENT remaining tasks within this section are the specification of requirements and selection of the pro- Because most software development life cycle cesses for revision and review of requirements. models require similar activities that may be executed in different ways, the breakdown of topics 1.1. Determination and Negotiation of is activity-based. That breakdown is shown in Requirements Figure 7.1. The elements of the top-level break- [3*, c3] down shown in that figure are the activities that are usually performed when a software develop- Determining and negotiating requirements set ment project is being managed, independent of the visible boundaries for the set of tasks being the software development life cycle model (see undertaken (see the Software Requirements KA). Software Life Cycle Models in the Software Activities include requirements elicitation, analy- Engineering Process KA) that has been chosen for sis, specification, and validation. Methods and a specific project. There is no intent in this break- techniques should be selected and applied, taking down to recommend a specific life cycle model. into account the various stakeholder perspectives. The breakdown implies only what happens and This leads to the determination of project scope in does not imply when, how, or how many times order to meet objectives and satisfy constraints. each activity occurs. The seven topics are: 1.2. Feasibility Analysis • Initiation and Scope Definition, which deal [4*, c4] with the decision to embark on a software engineering project; The purpose of feasibility analysis is to develop a • Software Project Planning, which addresses clear description of project objectives and evalu- the activities undertaken to prepare for a suc- ate alternative approaches in order to determine cessful software engineering project from whether the proposed project is the best alterna- the management perspective; tive given the constraints of technology, resources, • Software Project Enactment, which deals finances, and social/political considerations. An with generally accepted software engineering initial project and product scope statement, project management activities that occur during the deliverables, project duration constraints, and an execution of a software engineering project; estimate of resources needed should be prepared. • Review and Evaluation, which deal with Resources include a sufficient number of ensuring that technical, schedule, cost, and people who have the needed skills, facilities, quality engineering activities are satisfactory; infrastructure, and support (either internally or • Closure, which addresses the activities externally). Feasibility analysis often requires accomplished to complete a project; approximate estimations of effort and cost based • Software Engineering Measurement, which on appropriate methods (see section 2.3, Effort, deals with the effective development and Schedule, and Cost Estimation). Software Engineering Management 7-5

1.3. Process for the Review and Revision of 2.1. Process Planning Requirements [3*, c3, c4, c5] [5*, c1] [3*, c3] Software development life cycle (SDLC) mod- Given the inevitability of change, stakeholders els span a continuum from predictive to adaptive should agree on the means by which requirements (see Software Life Cycle Models in the Software and scope are to be reviewed and revised (for Engineering Process KA). Predictive SDLCs are example, change management procedures, itera- characterized by development of detailed soft- tive cycle retrospectives). This clearly implies ware requirements, detailed project planning, and that scope and requirements will not be “set in minimal planning for iteration among develop- stone” but can and should be revisited at predeter- ment phases. Adaptive SDLCs are designed to mined points as the project unfolds (for example, accommodate emergent software requirements at the time when backlog priorities are created or and iterative adjustment of plans. A highly pre- at milestone reviews). If changes are accepted, dictive SDLC executes the first five processes then some form of traceability analysis and risk listed in Figure 7.1 in a linear sequence with revi- analysis should be used to ascertain the impact sions to earlier phases only as necessary. Adap- of those changes (see section 2.5, Risk Manage- tive SDLCs are characterized by iterative devel- ment, and Software Configuration Control in the opment cycles. SDLCs in the mid-range of the Software Configuration Management KA). SDLC continuum produce increments of func- A managed-change approach can also form the tionality on either a preplanned schedule (on the basis for evaluation of success during closure of predictive side of the continuum) or as the prod- an incremental cycle or an entire project, based ucts of frequently updated development cycles on changes that have occurred along the way (see (on the adaptive side of the continuum). topic 5, Closure). Well-known SDLCs include the waterfall, incremental, and spiral models plus various forms 2. Software Project Planning of agile software development [2] [3*, c2]. Relevant methods (see the Software Engineer- The first step in software project planning should ing Models and Methods KA) and tools should be be selection of an appropriate software develop- selected as part of planning. Automated tools that ment life cycle model and perhaps tailoring it will be used throughout the project should also based on project scope, software requirements, be planned for and acquired. Tools may include and a risk assessment. Other factors to be consid- tools for project scheduling, software require- ered include the nature of the application domain, ments, software design, software construction, functional and technical complexity, and soft- software maintenance, software configuration ware quality requirements (see Software Quality management, software engineering process, soft- Requirements in the Software Quality KA). ware quality, and others. While many of these In all SDLCs, risk assessment should be an tools should be selected based primarily on the element of initial project planning, and the “risk technical considerations discussed in other KAs, profile” of the project should be discussed and some of them are closely related to the manage- accepted by all relevant stakeholders. Software ment considerations discussed in this chapter. quality management processes (see Software Quality Management Processes in the Software 2.2. Determine Deliverables Quality KA) should be determined as part of the [3*, c4, c5, c6] planning process and result in procedures and responsibilities for software quality assurance, The work product(s) of each project activity (for verification and validation, reviews, and audits example, software architecture design docu- (see the Software Quality KA). Processes and ments, inspection reports, tested software) should responsibilities for ongoing review and revision be identified and characterized. Opportunities to of the project plan and related plans should also reuse software components from previous proj- be clearly stated and agreed upon. ects or to utilize off-the-shelf software products 7-6 SWEBOK® Guide V3.0

should be evaluated. Procurement of software well as by issues relating to personnel (for exam- and use of third parties to develop deliverables ple, productivity of individuals and teams, team should be planned and suppliers selected (see dynamics, and team structures). section 3.2, Software Acquisition and Supplier Contract Management). 2.5. Risk Management [3*, c9] [5*, c5] 2.3. Effort, Schedule, and Cost Estimation [3*, c6] Risk and uncertainty are related but distinct concepts. Uncertainty results from lack of informa- The estimated range of effort required for a proj- tion. Risk is characterized by the probability of an ect, or parts of a project, can be determined using event that will result in a negative impact plus a a calibrated estimation model based on historical characterization of the negative impact on a proj- size and effort data (when available) and other ect. Risk is often the result of uncertainty. The relevant methods such as expert judgment and converse of risk is opportunity, which is charac- analogy. Task dependencies can be established terized by the probability that an event having a and potential opportunities for completing tasks positive outcome might occur. concurrently and sequentially can be identified Risk management entails identification of risk and documented using a Gantt chart, for exam- factors and analysis of the probability and poten- ple. For predictive SDLC projects, the expected tial impact of each risk factor, prioritization of schedule of tasks with projected start times, dura- risk factors, and development of risk mitigation tions, and end times is typically produced during strategies to reduce the probability and minimize planning. For adaptive SDLC projects, an over- the negative impact if a risk factor becomes a all estimate of effort and schedule is typically problem. Risk assessment methods (for example, developed from the initial understanding of the expert judgment, historical data, decision trees, requirements, or, alternatively, constraints on and process simulations) can sometimes be used overall effort and schedule may be specified and in order to identify and evaluate risk factors. used to determine an initial estimate of the num- Project abandonment conditions can also be ber of iterative cycles and estimates of effort and determined at this point in discussion with all other resources allocated to each cycle. relevant stakeholders. Software-unique aspects Resource requirements (for example, people of risk, such as software engineers’ tendency to and tools) can be translated into cost estimates. add unneeded features, or the risks related to soft- Initial estimation of effort, schedule, and cost is ware’s intangible nature, can influence risk man- an iterative activity that should be negotiated and agement of a software project. Particular atten- revised among affected stakeholders until con- tion should be paid to the management of risks sensus is reached on resources and time available related to software quality requirements such as for project completion. safety or security (see the Software Quality KA). Risk management should be done not only at the 2.4. Resource Allocation beginning of a project, but also at periodic inter- [3*, c5, c10, c11] vals throughout the project life cycle.

Equipment, facilities, and people should be allo- 2.6. Quality Management cated to the identified tasks, including the - allo [3*, c4] [4*, c24] cation of responsibilities for completion of various elements of a project and the overall project. Software quality requirements should be identi- A matrix that shows who is responsible for, fied, perhaps in both quantitative and qualitative accountable for, consulted about, and informed terms, for a software project and the associated about each of the tasks can be used. Resource work products. Thresholds for acceptable qual- allocation is based on, and constrained by, the ity measurements should be set for each software availability of resources and their optimal use, as quality requirement based on stakeholder needs Software Engineering Management 7-7

and expectations. Procedures concerned with example, software design, software code, and ongoing Software Quality Assurance (SQA) and software test cases) are generated. quality improvement throughout the development process, and for verification and validation of 3.2. Software Acquisition and Supplier Contract the deliverable software product, should also be Management specified during quality planning (for example, [3*, c3, c4] technical reviews and inspections or demonstrations of completed functionality; see the Software Software acquisition and supplier contract man- Quality KA). agement is concerned with issues involved in contracting with customers of the software devel- 2.7. Plan Management opment organization who acquire the deliverable [3*, c4] work products and with suppliers who supply products or services to the software engineering For software projects, where change is an expec- organization. tation, plans should be managed. Managing the This may involve selection of appropriate kinds project plan should thus be planned. Plans and of contracts, such as fixed price, time and materi- processes selected for software development als, cost plus fixed fee, or cost plus incentive fee. should be systematically monitored, reviewed, Agreements with customers and suppliers typi- reported, and, when appropriate, revised. Plans cally specify the scope of work and the deliver- associated with supporting processes (for exam- ables and include clauses such as penalties for late ple, documentation, software configuration man- delivery or nondelivery and intellectual property agement, and problem resolution) also should be agreements that specify what the supplier or sup- managed. Reporting, monitoring, and controlling pliers are providing and what the acquirer is pay- a project should fit within the selected SDLC and ing for, plus what will be delivered to and owned the realities of the project; plans should account by the acquirer. For software being developed by for the various artifacts that will be used to man- suppliers (both internal to or external to the soft- age the project. ware development organization), agreements commonly indicate software quality requirements for 3. Software Project Enactment acceptance of the delivered software. After the agreement has been put in place, exe- During software project enactment (also known cution of the project in compliance with the terms as project execution) plans are implemented and of the agreement should be managed (see chapter the processes embodied in the plans are enacted. 12 of SWX, Software Procurement Management, Throughout, there should be a focus on adher- for more information on this topic [2]). ence to the selected SDLC processes, with an overriding expectation that adherence will lead to 3.3. Implementation of Measurement Process the successful satisfaction of stakeholder require- [3*, c7] ments and achievement of the project’s objectives. Fundamental to enactment are the ongoing The measurement process should be enacted dur- management activities of monitoring, control- ing the software project to ensure that relevant ling, and reporting. and useful data are collected (see sections 6.2, Plan the Measurement Process, and 6.3, Perform 3.1. Implementation of Plans the Measurement Process). [4*, c2] 3.4. Monitor Process Project activities should be undertaken in accor- [3*, c8] dance with the project plan and supporting plans. Resources (for example, personnel, technology, Adherence to the project plan and related and funding) are utilized and work products (for plans should be assessed continually and at 7-8 SWEBOK® Guide V3.0

predetermined intervals. Also, outputs and com- software configuration control and software con- pletion criteria for each task should be assessed. figuration management procedures should be Deliverables should be evaluated in terms of their adhered to (see the Software Configuration Man- required characteristics (for example, via inspec- agement KA), decisions should be documented tions or by demonstrating working functionality). and communicated to all relevant parties, plans Effort expenditure, schedule adherence, and costs should be revisited and revised when necessary, to date should be analyzed, and resource usage and relevant data recorded (see section 6.3, Per- examined. The project risk profile (see section form the Measurement Process). 2.5, Risk Management) should be revisited, and adherence to software quality requirements eval- 3.6. Reporting uated (see Software Quality Requirements in the [3*, c11] Software Quality KA). Measurement data should be analyzed (see Sta- At specified and agreed-upon times, progress to tistical Analysis in the Engineering Foundations date should be reported—both within the orga- KA). Variance analysis based on the deviation of nization (for example, to a project steering com- actual from expected outcomes and values should mittee) and to external stakeholders (for exam- be determined. This may include cost overruns, ple, clients or users). Reports should focus on schedule slippage, or other similar measures. the information needs of the target audience as Outlier identification and analysis of quality and opposed to the detailed status reporting within the other measurement data should be performed (for project team. example, defect analysis; see Software Quality Measurement in the Software Quality KA). Risk 4. Review and Evaluation exposures should be recalculated (see section 2.5, Risk Management). These activities can enable At prespecified times and as needed, overall prog- problem detection and exception identification ress towards achievement of the stated objectives based on thresholds that have been exceeded. and satisfaction of stakeholder (user and customer) Outcomes should be reported when thresholds requirements should be evaluated. Similarly, have been exceeded, or as necessary. assessments of the effectiveness of the software process, the personnel involved, and the tools and 3.5. Control Process methods employed should also be undertaken reg- [3*, c7, c8] ularly and as determined by circumstances.

The outcomes of project monitoring activities 4.1. Determining Satisfaction of Requirements provide the basis on which decisions can be made. [4*, c8] Where appropriate, and when the probability and impact of risk factors are understood, changes can Because achieving stakeholder satisfaction is be made to the project. This may take the form of a principal goal of the software engineering corrective action (for example, retesting certain manager, progress towards this goal should software components); it may involve incorpo- be assessed periodically. Progress should be rating additional actions (for example, deciding assessed on achievement of major project mile- to use prototyping to assist in software require- stones (for example, completion of software ments validation; see Prototyping in the Software design architecture or completion of a soft- Requirements KA); and/or it may entail revision ware technical review), or upon completion of of the project plan and other project documents an iterative development cycle that results in (for example, the software requirements specifi- a product increment. Variances from software cation) to accommodate unanticipated events and requirements should be identified and appropri- their implications. ate actions should be taken. In some instances, the control process may As in the control process activity above (see sec- lead to abandonment of the project. In all cases, tion 3.5, Control Process), software configuration Software Engineering Management 7-9

control and software configuration management 5.2. Closure Activities procedures should be followed (see the Software [2, s3.7, s4.8] Configuration Management KA), decisions documented and communicated to all relevant parties, After closure has been confirmed, archiving of plans revisited and revised where necessary, and project materials should be accomplished in relevant data recorded (see section 6.3, Perform accordance with stakeholder agreed-upon meth- the Measurement Process). ods, location, and duration—possibly including destruction of sensitive information, software, 4.2. Reviewing and Evaluating Performance and the medium on which copies are resident. [3*, c8, c10] The organization’s measurement database should be updated with relevant project data. A project, Periodic performance reviews for project per- phase, or iteration retrospective analysis should sonnel can provide insights as to the likelihood be undertaken so that issues, problems, risks, of adherence to plans and processes as well as and opportunities encountered can be analyzed possible areas of difficulty (for example, team (see topic 4, Review and Evaluation). Lessons member conflicts). The various methods, tools, learned should be drawn from the project and fed and techniques employed should be evaluated for into organizational learning and improvement their effectiveness and appropriateness, and the endeavors. process being used by the project should also be systematically and periodically assessed for rel- 6. Software Engineering Measurement evance, utility, and efficacy in the project context. Where appropriate, changes should be made and The importance of measurement and its role in managed. better management and engineering practices is widely acknowledged (see Measurement in the 5. Closure Engineering Foundations KA). Effective measurement has become one of the cornerstones An entire project, a major phase of a project, of organizational maturity. Measurement can be or an iterative development cycle reaches clo- applied to organizations, projects, processes, and sure when all the plans and processes have been work products. In this section the focus is on the enacted and completed. The criteria for project, application of measurement at the levels of proj- phase, or iteration success should be evaluated. ects, processes, and work products. Once closure is established, archival, retrospec- This section follows the IEEE 15939:2008 tive, and process improvement activities can be standard [6], which describes a process to define performed. the activities and tasks necessary to implement a software measurement process. The standard also 5.1. Determining Closure includes a measurement information model. [1, s3.7, s4.6] 6.1. Establish and Sustain Measurement Closure occurs when the specified tasks for a Commitment project, a phase, or an iteration have been com- [7*, c1, c2]2 pleted and satisfactory achievement of the completion criteria has been confirmed. Software • Requirements for measurement. Each mea- requirements can be confirmed as satisfied or not, surement endeavor should be guided by and the degree of achieving the objectives can organizational objectives and driven by a set be determined. Closure processes should involve of measurement requirements established by relevant stakeholders and result in documentation of relevant stakeholders’ acceptance; any known 2 Please note that these two chapters can be problems should be documented. downloaded free of charge from www.psmsc.com/ PSMBook.asp. 7-10 SWEBOK® Guide V3.0

the organization and the project (for exam- prioritized. Then a subset of objectives to be ple, an organizational objective might be addressed can be selected, documented, com- “first-to-market with new products”). municated, and reviewed by stakeholders. • Scope of measurement. The organizational • Select measures. Candidate measures should unit to which each measurement requirement be selected, with clear links to the informa- is to be applied should be established. This tion needs. Measures should be selected may consist of a functional area, a single based on the priorities of the information project, a single site, or an entire enterprise. needs and other criteria such as cost of col- The temporal scope of the measurement lection, degree of process disruption during effort should also be considered because collection, ease of obtaining accurate, con- time series of some measurements may be sistent data, and ease of analysis and report- required; for example, to calibrate estima- ing. Because internal quality characteristics tion models (see section 2.3, Effort, Sched- (see Models and Quality Characteristics in ule, and Cost Estimation). the Software Quality KA) are often not con- • Team commitment to measurement. The tained in the contractually binding software commitment should be formally established, requirements, it is important to consider mea- communicated, and supported by resources suring the internal quality of the software to (see next item). provide an early indicator of potential issues • Resources for measurement. An organiza- that may impact external stakeholders. tion’s commitment to measurement is an • Define data collection, analysis, and report- essential factor for success, as evidenced by ing procedures. This encompasses collection the assignment of resources for implement- procedures and schedules, storage, verifica- ing the measurement process. Assigning tion, analysis, reporting, and configuration resources includes allocation of responsibil- management of data. ity for the various tasks of the measurement • Select criteria for evaluating the information process (such as analyst and librarian). Ade- products. Criteria for evaluation are influ- quate funding, training, tools, and support to enced by the technical and business objec- conduct the process should also be allocated. tives of the organizational unit. Information products include those associated with the product being produced, as well as those 6.2. Plan the Measurement Process associated with the processes being used to [7*, c1, c2] manage and measure the project. • Provide resources for measurement tasks. The • Characterize the organizational unit. The measurement plan should be reviewed and organizational unit provides the context for approved by the appropriate stakeholders to measurement, so the organizational context include all data collection procedures; storage, should be made explicit, including the con- analysis, and reporting procedures; evaluation straints that the organization imposes on criteria; schedules; and responsibilities. Crite- the measurement process. The characteriza- ria for reviewing these artifacts should have tion can be stated in terms of organizational been established at the organizational-unit processes, application domains, technology, level or higher and should be used as the basis organizational interfaces, and organizational for these reviews. Such criteria should take structure. into consideration previous experience, avail- • Identify information needs. Information ability of resources, and potential disruptions needs are based on the goals, constraints, to projects when changes from current prac- risks, and problems of the organizational tices are proposed. Approval demonstrates unit. They may be derived from business, commitment to the measurement process. organizational, regulatory, and/or product • Identify resources to be made available for objectives. They should be identified and implementing the planned and approved Software Engineering Management 7-11

measurement tasks. Resource availability Engineering Foundations KA). The results may be staged in cases where changes are and conclusions are usually reviewed, using to be piloted before widespread deployment. a process defined by the organization (which Consideration should be paid to the resources may be formal or informal). Data providers necessary for successful deployment of new and measurement users should participate procedures or measures. in reviewing the data to ensure that they are • Acquire and deploy supporting technologies. meaningful and accurate and that they can This includes evaluation of available supporting result in reasonable actions. technologies, selection of the most appropriate • Communicate results. Information products technologies, acquisition of those technologies, should be documented and communicated to and deployment of those technologies. users and stakeholders.

6.3. Perform the Measurement Process 6.4. Evaluate Measurement [7*, c1, c2] [7*, c1, c2]

• Integrate measurement procedures with rel- • Evaluate information products and the mea- evant software processes. The measurement surement process against specified evalu- procedures, such as data collection, should ation criteria and determine strengths and be integrated into the software processes weaknesses of the information products or they are measuring. This may involve chang- process, respectively. Evaluation may be ing current software processes to accommo- performed by an internal process or an exter- date data collection or generation activities. nal audit; it should include feedback from It may also involve analysis of current soft- measurement users. Lessons learned should ware processes to minimize additional effort be recorded in an appropriate database. and evaluation of the effect on employees to • Identify potential improvements. Such ensure that the measurement procedures will improvements may be changes in the format be accepted. Morale issues and other human of indicators, changes in units measured, or factors should be considered. In addition, the reclassification of measurement categories. measurement procedures should be commu- The costs and benefits of potential improve- nicated to those providing the data. Training ments should be determined and appropriate and support may also need to be provided. improvement actions should be reported. Data analysis and reporting procedures are • Communicate proposed improvements to the typically integrated into organizational and/ measurement process owner and stakehold- or project processes in a similar manner. ers for review and approval. Also, lack of • Collect data. Data should be collected, veri- potential improvements should be commu- fied, and stored. Collection can sometimes nicated if the analysis fails to identify any be automated by using software engineer- improvements. ing management tools (see topic 7, Soft- ware Engineering Management Tools) to 7. Software Engineering Management Tools analyze data and develop reports. Data may [3*, c5, c6, c7] be aggregated, transformed, or recoded as part of the analysis process, using a degree Software engineering management tools are often of rigor appropriate to the nature of the data used to provide visibility and control of software and the information needs. The results of engineering management processes. Some tools this analysis are typically indicators such as are automated while others are manually imple- graphs, numbers, or other indications that mented. There has been a recent trend towards will be interpreted, resulting in conclusions the use of integrated suites of software engineer- and recommendations to be presented to ing tools that are used throughout a project to stakeholders (see Statistical Analysis in the plan, collect and record, monitor and control, and 7-12 SWEBOK® Guide V3.0

report project and product information. Tools can and subjective estimates of the probabilities of be divided into the following categories: risk events. Monte Carlo simulation tools can Project Planning and Tracking Tools. Project be used to produce probability distributions of planning and tracking tools can be used to esti- effort, schedule, and risk by combining multiple mate project effort and cost and to prepare project input probability distributions in an algorithmic schedules. Some projects use automated estima- manner. tion tools that accept as input the estimated size Communications Tools. Communication tools and other characteristics of a software product can assist in providing timely and consistent and produce estimates of the required total effort, information to relevant stakeholders involved in a schedule, and cost. Planning tools also include project. These tools can include things like email automated scheduling tools that analyze the tasks notifications and broadcasts to team members within a work breakdown structure, their esti- and stakeholders. They also include communica- mated durations, their precedence relationships, tion of minutes from regularly scheduled project and the resources assigned to each task to pro- meetings, daily stand-up meetings, plus charts duce a schedule in the form of a Gantt chart. showing progress, backlogs, and maintenance Tracking tools can be used to track project request resolutions. milestones, regularly scheduled project status Measurement Tools. Measurement tools sup- meetings, scheduled iteration cycles, product port activities related to the software measure- demonstrations, and/or action items. ment program (see topic 6, Software Engineer- Risk Management Tools. Risk management ing Measurement). There are few completely tools (see section 2.5, Risk Management) can automated tools in this category. Measurement be used to track risk identification, estimation, tools used to gather, analyze, and report project and monitoring. These tools include the use of measurement data may be based on spreadsheets approaches such as simulation or decision trees developed by project team members or organiza- to analyze the effect of costs versus payoffs tional employees. Software Engineering Management 7-13

MATRIX OF TOPICS VS. REFERENCE MATERIAL [4*] [3*] [5*] [7*] Fairley 2009Fairley Sommerville 2011 McGarry et al. 2001 Boehm and Turner 2003 Boehm and Turner

1. Initiation and Scope Definition 1.1. Determination and c3 Negotiation of Requirements 1.2. Feasibility Analysis c4 1.3. Process for the Review and c3 Revision of Requirements 2. Software Project Planning 2.1. Process Planning c2, c3, c4, c5 c1 2.2. Determine Deliverables c4, c5, c6 2.3. Effort, Schedule, and Cost c6 Estimation 2.4. Resource Allocation c5, c10, c11 2.5. Risk Management c9 c5 2.6. Quality Management c4 c24 2.7. Plan Management c4 3. Software Project Enactment 3.1. Implementation of Plans c2 3.2. Software Acquisition and c3, c4 Supplier Contract Management 3.3. Implementation of c7 Measurement Process 3.4. Monitor Process c8 3.5. Control Process c7, c8 3.6. Reporting c11 4. Review and Evaluation 4.1. Determining Satisfaction of Requirements 4.2. Reviewing and Evaluating c8, c10 Performance 7-14 SWEBOK® Guide V3.0 [4*] [3*] [5*] [7*] Fairley 2009Fairley Sommerville 2011 McGarry et al. 2001 Boehm and Turner 2003 Boehm and Turner

5. Closure 5.1. Determining Closure 5.2. Closure Activities 6. Software Engineering Measurement 6.1. Establish and Sustain c1, c2 Measurement Commitment 6.2. Plan the Measurement c1, c2 Process 6.3. Perform the Measurement c1, c2 Process 6.4. Evaluate Measurement c1, c2 7. Software Engineering c5, c6, c7 Management Tools Software Engineering Management 7-15

FURTHER READINGS REFERENCES

A Guide to the Project Management Body of [1] Project Management Institute, A Guide to the Knowledge (PMBOK® Guide) [1]. Project Management Body of Knowledge (PMBOK(R) Guide), 5th ed., Project The PMBOK® Guide provides guidelines for Management Institute, 2013. managing individual projects and defines project management-related concepts. It also describes [2] Project Management Institute and IEEE the project management life cycle and its related Computer Society, Software Extension to processes, as well as the project life cycle. It is the PMBOK® Guide Fifth Edition, Project a globally recognized guide for the project man- Management Institute, 2013. agement profession. [3*] R.E. Fairley, Managing and Leading Software Extension to the Guide to the Software Projects, Wiley-IEEE Computer Project Management Body of Knowledge Society Press, 2009. (PMBOK® Guide) [2]. [4*] I. Sommerville, Software Engineering, 9th SWX provides adaptations and extensions to ed., Addison-Wesley, 2011. the generic practices of project management documented in the PMBOK® Guide for manag- [5*] B. Boehm and R. Turner, Balancing Agility ing software projects. The primary contribution and Discipline: A Guide for the Perplexed, of this extension to the PMBOK® Guide is a Addison-Wesley, 2003. description of processes that are applicable for managing adaptive life cycle software projects. [6] IEEE Std. 15939-2008 Standard Adoption of ISO/IEC 15939:2007 Systems and Software IEEE Standard Adoption of ISO/IEC 15939 [6]. Engineering—Measurement Process, IEEE, 2008. This international standard identifies a process that supports defining a suitable set of measures [7*] J. McGarry et al., Practical Software to address specific information needs. It identi- Measurement: Objective Information fies the activities and tasks that are necessary to for Decision Makers, Addison-Wesley successfully identify, define, select, apply, and Professional, 2001. improve measurement within an overall project or organizational measurement structure. [8] J. McDonald, Managing the Development of Software Intensive Systems, John Wiley and J. McDonald, Managing the Development of Sons, Inc., 2010. Software Intensive Systems, Wiley, 2010 [8].

This textbook provides an introduction to project management for beginning software and hardware developers plus unique advanced material for experienced project managers. Case studies are included for planning and managing verification and validation for large software projects, complex software, and hardware systems, as well as inspection results and testing metrics to monitor project status. CHAPTER 8

SOFTWARE ENGINEERING PROCESS

ACRONYMS process” will be referred to as “software process” in this KA. In addition, please note that “software Business Process Modeling BPMN process” denotes work activities—not the execu- Notation tion process for implemented software. Computer-Assisted Software Software processes are specified for a number CASE Engineering of reasons: to facilitate human understanding, CM Configuration Management communication, and coordination; to aid man- Capability Maturity Model agement of software projects; to measure and CMMI Integration improve the quality of software products in an efficient manner; to support process improve- GQM Goal-Question-Metric ment; and to provide a basis for automated sup- IDEF0 Integration Definition port of process execution. LOE Level of Effort SWEBOK KAs closely related to this Soft- ODC Orthogonal Defect Classification ware Engineering Process KA include Software Engineering Management, Software Engineer- SDLC Software Development Life Cycle ing Models and Methods, and Software Quality; SPLC Software Product Life Cycle the Measurement and Root Cause Analysis topic UML Unified Modeling Language found in the Engineering Foundations KA is also closely related. Software Engineering Manage- ment is concerned with tailoring, adapting, and INTRODUCTION implementing software processes for a specific software project (see Process Planning in the An engineering process consists of a set of inter- Software Engineering Management KA). Mod- related activities that transform one or more inputs els and methods support a systematic approach to into outputs while consuming resources to accom- software development and modification. plish the transformation. Many of the processes of The Software Quality KA is concerned with traditional engineering disciplines (e.g., electrical, the planning, assurance, and control processes mechanical, civil, chemical) are concerned with for project and product quality. Measurement and transforming energy and physical entities from measurement results in the Engineering Founda- one form into another, as in a hydroelectric dam tions KA are essential for evaluating and control- that transforms potential energy into electrical ling software processes. energy or a petroleum refinery that uses chemical processes to transform crude oil into gasoline. BREAKDOWN OF TOPICS FOR In this knowledge area (KA), software engineer- SOFTWARE ENGINEERING PROCESS ing processes are concerned with work activities accomplished by software engineers to develop, As illustrated in Figure 8.1, this KA is concerned maintain, and operate software, such as require- with software process definition, software life ments, design, construction, testing, configura- cycles, software process assessment and improve- tion management, and other software engineering ment, software measurement, and software engi- processes. For readability, “software engineering neering process tools.

8-1 8-2 SWEBOK® Guide V3.0

Figure 8.1. Breakdown of Topics for the Software Engineering Process KA

1. Software Process Definition concluded, including the acceptance criteria for [1*, p177] [2*, p295] [3*, p28–29, p36, c5] the output work product or work products. A software process may include subprocesses. This topic is concerned with a definition of soft- For example, software requirements validation is ware process, software process management, and a process used to determine whether the require- software process infrastructure. ments will provide an adequate basis for software As stated above, a software process is a set of development; it is a subprocess of the software interrelated activities and tasks that transform requirements process. Inputs for requirements val- input work products into output work products. idation are typically a software requirements spec- At minimum, the description of a software pro- ification and the resources needed to perform vali- cess includes required inputs, transforming work dation (personnel, validation tools, sufficient time). activities, and outputs generated. As illustrated in The tasks of the requirements validation activity Figure 8.2, a software process may also include might include requirements reviews, prototyping, its entry and exit criteria and decomposition and model validation. These tasks involve work of the work activities into tasks, which are the assignments for individuals and teams. The output smallest units of work subject to management of requirements validation is typically a validated accountability. A process input may be a trigger- software requirements specification that provides ing event or the output of another process. Entry inputs to the software design and software test- criteria should be satisfied before a process can ing processes. Requirements validation and other commence. All specified conditions should be subprocesses of the software requirements process satisfied before a process can be successfully are often interleaved and iterated in various ways; Software Engineering Process 8-3

Figure 8.2. Elements of a Software Process the software requirements process and its subpro- result from a systematic approach to accomplish- cesses may be entered and exited multiple times ing software processes and producing work prod- during software development or modification. ucts—be it at the individual, project, or organiza- Complete definition of a software process may tional level—and to introduce new or improved also include the roles and competencies, IT sup- processes. port, software engineering techniques and tools, Processes are changed with the expectation that and work environment needed to perform the a new or modified process will improve the effi- process, as well as the approaches and measures ciency and/or effectiveness of the process and the (Key Performance Indicators) used to determine quality of the resulting work products. Changing the efficiency and effectiveness of performing the to a new process, improving an existing process, process. organizational change, and infrastructure change In addition, a software process may include (technology insertion or changes in tools) are interleaved technical, collaborative, and adminis- closely related, as all are usually initiated with the trative activities. goal of improving the cost, development sched- Notations for defining software processes ule, or quality of the software products. Process include textual lists of constituent activities and change has impacts not only for the software tasks described in natural language; data-flow product; they often lead to organizational change. diagrams; state charts; BPMN; IDEF0; Petri nets; Changing a process or introducing a new process and UML activity diagrams. The transforming can have ripple effects throughout an organiza- tasks within a process may be defined as proce- tion. For example, changes in IT infrastruc- dures; a procedure may be specified as an ordered ture tools and technology often require process set of steps or, alternatively, as a checklist of the changes. work to be accomplished in performing a task. Existing processes may be modified when It must be emphasized that there is no best soft- other new processes are deployed for the first ware process or set of software processes. Soft- time (for example, introducing an inspection ware processes must be selected, adapted, and activity within a software development project applied as appropriate for each project and each will likely impact the software testing process— organizational context. No ideal process, or set of see Reviews and Audits in the Software Quality processes, exists. KA and in the Software Testing KA). These situations can also be termed “process evolution.” 1.1. Software Process Management If the modifications are extensive, then changes [3*, s26.1] [4*, p453–454] in the organizational culture and business model will likely be necessary to accommodate the pro- Two objectives of software process management cess changes. are to realize the efficiency and effectiveness that 8-4 SWEBOK® Guide V3.0

1.2. Software Process Infrastructure process adaptation, and practical considerations. [2*, p183, p186] [4*, p437–438] A software development life cycle (SDLC) includes the software processes used to specify Establishing, implementing, and managing soft- and transform software requirements into a deliv- ware processes and software life cycle models erable software product. A software product life often occurs at the level of individual software cycle (SPLC) includes a software development projects. However, systematic application of life cycle plus additional software processes that software processes and software life cycle mod- provide for deployment, maintenance, support, els across an organization can provide benefits evolution, retirement, and all other inception- to all software work within the organization, to-retirement processes for a software product, although it requires commitment at the organi- including the software configuration management zational level. A software process infrastructure and software quality assurance processes that are can provide process definitions, policies for inter- applied throughout a software product life cycle. preting and applying the processes, and descrip- A software product life cycle may include multi- tions of the procedures to be used to implement ple software development life cycles for evolving the processes. Additionally, a software process and enhancing the software. infrastructure may provide funding, tools, train- Individual software processes have no tempo- ing, and staff members who have been assigned ral ordering among them. The temporal relation- responsibilities for establishing and maintaining ships among software processes are provided by the software process infrastructure. a software life cycle model: either an SDLC or Software process infrastructure varies, depend- SPLC. Life cycle models typically emphasize ing on the size and complexity of the organization the key software processes within the model and the projects undertaken within the organiza- and their temporal and logical interdependen- tion. Small, simple organizations and projects cies and relationships. Detailed definitions of have small, simple infrastructure needs. Large, the software processes in a life cycle model may complex organizations and projects, by neces- be provided directly or by reference to other sity, have larger and more complex software documents. process infrastructures. In the latter case, various In addition to conveying the temporal and organizational units may be established (such as logical relationships among software processes, a software engineering process group or a steer- the software development life cycle model (or ing committee) to oversee implementation and models used within an organization) includes the improvement of the software processes. control mechanisms for applying entry and exit A common misperception is that establishing a criteria (e.g., project reviews, customer approv- software process infrastructure and implementing als, software testing, quality thresholds, dem- repeatable software processes will add time and onstrations, team consensus). The output of one cost to software development and maintenance. software process often provides the input for oth- There is a cost associated with introducing or ers (e.g., software requirements provide input for improving a software process; however, experi- a software architectural design process and the ence has shown that implementing systematic software construction and software testing pro- improvement of software processes tends to result cesses). Concurrent execution of several software in lower cost through improved efficiency, avoid- process activities may produce a shared output ance of rework, and more reliable and affordable (e.g., the interface specifications for interfaces software. Process performance thus influences among multiple software components developed software product quality. by different teams). Some software processes may be regarded as less effective unless other 2. Software Life Cycles software processes are being performed at the [1*, c2] [2*, p190] same time (e.g., software test planning during software requirements analysis can improve the This topic addresses categories of software pro- software requirements). cesses, software life cycle models, software Software Engineering Process 8-5

2.1. Categories of Software Processes 2.2. Software Life Cycle Models [1*, Preface] [2* , p294–295] [3*, c22–c24] [1*, c2] [2*, s3.2] [3*, s2.1] [5]

Many distinct software processes have been The intangible and malleable nature of software defined for use in the various parts of the soft- permits a wide variety of software development ware development and software maintenance life life cycle models, ranging from linear models in cycles. These processes can be categorized as which the phases of software development are follows: accomplished sequentially with feedback and iteration as needed followed by integration, test- 1. Primary processes include software pro- ing, and delivery of a single product; to iterative cesses for development, operation, and models in which software is developed in incre- maintenance of software. ments of increasing functionality on iterative 2. Supporting processes are applied intermit- cycles; to agile models that typically involve tently or continuously throughout a software frequent demonstrations of working software to product life cycle to support primary pro- a customer or user representative who directs cesses; they include software processes such development of the software in short iterative as configuration management, quality assur- cycles that produce small increments of working, ance, and verification and validation. deliverable software. Incremental, iterative, and 3. Organizational processes provide sup- agile models can deliver early subsets of working port for software engineering; they include software into the user environment, if desired. training, process measurement analysis, Linear SDLC models are sometimes referred infrastructure management, portfolio and to as predictive software development life cycle reuse management, organizational process models, while iterative and agile SDLCs are improvement, and management of software referred to as adaptive software development life cycle models. life cycle models. It should be noted that vari- 4. Cross-project processes, such as reuse, soft- ous maintenance activities during an SPLC can ware product line, and domain engineering; be conducted using different SDLC models, as they involve more than a single software appropriate to the maintenance activities. project in an organization. A distinguishing feature of the various software development life cycle models is the way in Software processes in addition to those listed which software requirements are managed. Lin- above include the following. ear development models typically develop a com- Project management processes include pro- plete set of software requirements, to the extent cesses for planning and estimating, resource possible, during project initiation and planning. management, measuring and controlling, leading, The software requirements are then rigorously managing risk, managing stakeholders, and coor- controlled. Changes to the software requirements dinating the primary, supporting, organizational, are based on change requests that are processed and cross-project processes of software develop- by a change control board (see Requesting, ment and maintenance projects. Evaluating and Approving Software Changes in Software processes are also developed for the Change Control Board in the Software Con- particular needs, such as process activities that figuration Management KA). An incremental address software quality characteristics (see model produces successive increments of work- the Software Quality KA). For example, secu- ing, deliverable software based on partitioning rity concerns during software development may of the software requirements to be implemented necessitate one or more software processes to in each of the increments. The software require- protect the security of the development environments may be rigorously controlled, as in a linear ment and reduce the risk of malicious acts. Soft- model, or there may be some flexibility in revising ware processes may also be developed to provide the software requirements as the software product adequate grounds for establishing confidence in evolves. Agile models may define product scope the integrity of the software. and high-level features initially; however, agile 8-6 SWEBOK® Guide V3.0

models are designed to facilitate evolution of the construction, and testing) can be adapted to facili- software requirements during the project. tate operation, support, maintenance, migration, It must be emphasized that the continuum of and retirement of the software. SDLCs from linear to agile is not a thin, straight Additional factors to be considered when line. Elements of different approaches may be defining and tailoring a software life cycle model incorporated into a specific model; for -exam include required conformance to standards, direc- ple, an incremental software development life tives, and policies; customer demands; criticality cycle model may incorporate sequential soft- of the software product; and organizational matu- ware requirements and design phases but permit rity and competencies. Other factors include the considerable flexibility in revising the software nature of the work (e.g., modification of exist- requirements and architecture during software ing software versus new development) and the construction. application domain (e.g., aerospace versus hotel management). 2.3. Software Process Adaptation [1*, s2.7] [2*, p51] 3. Software Process Assessment and Improvement Predefined SDLCs, SPLCs, and individual soft- [2*, p188, p194] [3*, c26] [4*, p397, c15] ware processes often need to be adapted (or “tailored”) to better serve local needs. Organiza- This topic addresses software process assess- tional context, innovations in technology, project ment models, software process assessment meth- size, product criticality, regulatory requirements, ods, software process improvement models, and industry practices, and corporate culture may continuous and staged process ratings. Software determine needed adaptations. Adaptation of process assessments are used to evaluate the form individual software processes and software life and content of a software process, which may cycle models (development and product) may be specified by a standardized set of criteria. In consist of adding more details to software pro- some instances, the terms “process appraisal” cesses, activities, tasks, and procedures to address and “capability evaluation” are used instead of critical concerns. It may consist of using an alter- process assessment. Capability evaluations are nate set of activities that achieves the purpose and typically performed by an acquirer (or potential outcomes of the software process. Adaptation acquirer) or by an external agent on behalf of may also include omitting software processes an acquirer (or potential acquirer). The results or activities from a development or product life are used as an indicator of whether the software cycle model that are clearly inapplicable to the processes used by a supplier (or potential sup- scope of work to be accomplished. plier) are acceptable to the acquirer. Performance appraisals are typically performed within an orga- 2.4. Practical Considerations nization to identify software processes in need of [2*, p188–190] improvement or to determine whether a process (or processes) satisfies the criteria at a given level In practice, software processes and activities are of process capability or maturity. often interleaved, overlapped, and applied concur- Process assessments are performed at the lev- rently. Software life cycle models that specify dis- els of entire organizations, organizational units crete software processes, with rigorously specified within organizations, and individual projects. entry and exit criteria and prescribed boundaries Assessment may involve issues such as assess- and interfaces, should be recognized as idealiza- ing whether software process entry and exit cri- tions that must be adapted to reflect the realities of teria are being met, to review risk factors and software development and maintenance within the risk management, or to identify lessons learned. organizational context and business environment. Process assessment is carried out using both an Another practical consideration: software assessment model and an assessment method. The processes (such as configuration management, model can provide a norm for a benchmarking Software Engineering Process 8-7

comparison among projects within an organiza- examining the procedural steps followed and tion and among organizations. results obtained plus data concerning defects A process audit differs from a process assess- found and time required to find and fix the defects ment. Assessments are performed to determine as compared to software testing. levels of capability or maturity and to identify A typical method of software process assess- software processes to be improved. Audits are ment includes planning, fact-finding (by collect- typically conducted to ascertain compliance with ing evidence through questionnaires, interviews, policies and standards. Audits provide manage- and observation of work practices), collection ment visibility into the actual operations being and validation of process data, and analysis and performed in the organization so that accurate reporting. Process assessments may rely on the and meaningful decisions can be made concern- subjective, qualitative judgment of the assessor, ing issues that are impacting a development proj- or on the objective presence or absence of defined ect, a maintenance activity, or a software-related artifacts, records, and other evidence. topic. The activities performed during a software pro- Success factors for software process assess- cess assessment and the distribution of effort for ment and improvement within software engineer- assessment activities are different depending on ing organizations include management sponsor- the purpose of the software process assessment. ship, planning, training, experienced and capable Software process assessments may be undertaken leaders, team commitment, expectation manage- to develop capability ratings used to make recom- ment, the use of change agents, plus pilot projects mendations for process improvements or may be and experimentation with tools. Additional fac- undertaken to obtain a process maturity rating in tors include independence of the assessor and the order to qualify for a contract or award. timeliness of the assessment. The quality of assessment results depends on the software process assessment method, the 3.1. Software Process Assessment Models integrity and quality of the obtained data, the [2*, s4.5, s4.6] [3*, s26.5] [4*, p44–48] assessment team’s capability and objectivity, and the evidence examined during the assessment. Software process assessment models typically The goal of a software process assessment is to include assessment criteria for software processes gain insight that will establish the current status that are regarded as constituting good practices. of a process or processes and provide a basis for These practices may address software develop- process improvement; performing a software ment processes only, or they may also include process assessment by following a checklist for topics such as software maintenance, software conformance without gaining insight adds little project management, systems engineering, or value. human resources management. 3.3. Software Process Improvement Models 3.2. Software Process Assessment Methods [2*, p187–188] [3*, s26.5] [4*, s2.7] [1*, p322–331] [3*, s26.3] [4*, p44–48, s16.4] [6] Software process improvement models emphasize iterative cycles of continuous improvement. A software process assessment method can be A software process improvement cycle typically qualitative or quantitative. Qualitative assess- involves the subprocesses of measuring, ana- ments rely on the judgment of experts; quanti- lyzing, and changing. The Plan-Do-Check-Act tative assessments assign numerical scores to model is a well-known iterative approach to software processes based on analysis of objective software process improvement. Improvement evidence that indicates attainment of the goals activities include identifying and prioritizing and outcomes of a defined software process. For desired improvements (planning); introducing example, a quantitative assessment of the soft- an improvement, including change management ware inspection process might be performed by and training (doing); evaluating the improvement 8-8 SWEBOK® Guide V3.0

as compared to previous or exemplary process visibility into intermediate work products and results and costs (checking); and making further can exert some control over transitions between modifications (acting). The Plan-Do-Check-Act processes. At level 3, a single software process or process improvement model can be applied, for the processes in a maturity level 3 group plus the example, to improve software processes that process or processes in maturity level 2 are well enhance defect prevention. defined (perhaps in organizational policies and procedures) and are being repeated across dif- 3.4. Continuous and Staged Software Process ferent projects. Level 3 of process capability or Ratings maturity provides the basis for process improve- [1*, p28–34] [3*, s26.5] [4*, p39–45] ment across an organization because the process is (or processes are) conducted in a similar man- Software process capability and software process ner. This allows collection of performance data maturity are typically rated using five or six levels in a uniform manner across multiple projects. At to characterize the capability or maturity of the maturity level 4, quantitative measures can be software processes used within an organization. applied and used for process assessment; statis- A continuous rating system involves assign- tical analysis may be used. At maturity level 5, ing a rating to each software process of interest; the mechanisms for continuous process improve- a staged rating system is established by assignments are applied. ing the same maturity rating to all of the software Continuous and staged representations can be processes within a specified process level. A rep- used to determine the order in which software resentation of continuous and staged process lev- processes are to be improved. In the continuous els is provided in Table 8.1. Continuous models representation, the different capability levels for typically use a level 0 rating; staged models typi- different software processes provide a guideline cally do not. for determining the order in which software processes will be improved. In the staged representa- Table 8.1. Software Process Rating Levels tion, satisfying the goals of a set of software pro- Continuous Staged cesses within a maturity level is accomplished for Representation Representation that maturity level, which provides a foundation Level of Capability of Maturity for improving all of the software processes at the Levels Levels next higher level. 0 Incomplete 4. Software Measurement 1 Performed Initial [3*, s26.2] [4*, s18.1.1] 2 Managed Managed 3 Defined Defined This topic addresses software process and product measurement, quality of measurement results, Quantitatively 4 software information models, and software pro- Managed cess measurement techniques (see Measurement 5 Optimizing in the Engineering Foundations KA). Before a new process is implemented or a cur- In Table 8.1, level 0 indicates that a software rent process is modified, measurement results for process is incompletely performed or may not be the current situation should be obtained to pro- performed. At level 1, a software process is being vide a baseline for comparison between the cur- performed (capability rating), or the software rent situation and the new situation. For exam- processes in a maturity level 1 group are being ple, before introducing the software inspection performed but on an ad hoc, informal basis. At process, effort required to fix defects discovered level 2, a software process (capability rating) or by testing should be measured. Following an ini- the processes in maturity level 2 are being per- tial start-up period after the inspection process formed in a manner that provides management is introduced, the combined effort of inspection Software Engineering Process 8-9

plus testing can be compared to the previous design documentation, and other related work amount of effort required for testing alone. Simi- products. lar considerations apply if a process is changed. Also note that efficiency and effectiveness are independent concepts. An effective software pro- 4.1. Software Process and Product Measurement cess can be inefficient in achieving a desired soft- [1*, s6.3, p273] [3*, s26.2, p638] ware process result; for example, the amount of effort expended to find and fix software defects Software process and product measurement are could be very high and result in low efficiency, as concerned with determining the efficiency and compared to expectations. effectiveness of a software process, activity, or An efficient process can be ineffective in accom- task. The efficiency of a software process, activity, plishing the desired transformation of input work or task is the ratio of resources actually consumed products into output work products; for example, to resources expected or desired to be consumed failure to find and correct a sufficient number of in accomplishing a software process, activity, or software defects during the testing process. task (see Efficiency in the Software Engineering Causes of low efficiency and/or low effective- Economics KA). Effort (or equivalent cost) is the ness in the way a software process, activity, or primary measure of resources for most software task is executed might include one or more of the processes, activities, and tasks; it is measured in following problems: deficient input work -prod units such as person-hours, person-days, staff- ucts, inexperienced personnel, lack of adequate weeks, or staff-months of effort or in equivalent tools and infrastructure, learning a new process, monetary units—such as euros or dollars. a complex product, or an unfamiliar product Effectiveness is the ratio of actual output to domain. The efficiency and effectiveness of soft- expected output produced by a software process, ware process execution are also affected (either activity, or task; for example, actual number of positively or negatively) by factors such as turn- defects detected and corrected during software over in software personnel, schedule changes, a testing to expected number of defects to be new customer representative, or a new organiza- detected and corrected—perhaps based on his- tional policy. torical data for similar projects (see Effectiveness In software engineering, productivity in per- in the Software Engineering Economics KA). forming a process, activity, or task is the ratio of Note that measurement of software process effec- output produced divided by resources consumed; tiveness requires measurement of the relevant for example, the number of software defects dis- product attributes; for example, measurement of covered and corrected divided by person-hours of software defects discovered and corrected during effort (see Productivity in the Software Engineer- software testing. ing Economics KA). Accurate measurement of One must take care when measuring product productivity must include total effort used to sat- attributes for the purpose of determining process isfy the exit criteria of a software process, activ- effectiveness. For example, the number of defects ity, or task; for example, the effort required to detected and corrected by testing may not achieve correct defects discovered during software test- the expected number of defects and thus provide ing must be included in software development a misleadingly low effectiveness measure, either productivity. because the software being tested is of better- Calculation of productivity must account for than-usual quality or perhaps because introduc- the context in which the work is accomplished. tion of a newly introduced upstream inspection For example, the effort to correct discovered process has reduced the remaining number of defects will be included in the productivity cal- defects in the software. culation of a software team if team members Product measures that may be important in correct the defects they find—as in unit testing determining the effectiveness of software pro- by software developers or in a cross-functional cesses include product complexity, total defects, agile team. Or the productivity calculation defect density, and the quality of requirements, may include either the effort of the software 8-10 SWEBOK® Guide V3.0

developers or the effort of an independent test- 4.3. Software Information Models ing team, depending on who fixes the defects [1*, p310–311] [3*, p712–713] [4*, s19.2] found by the independent testers. Note that this example refers to the effort of teams of devel- Software information models allow modeling, opers or teams of testers and not to individuals. analysis, and prediction of software process and Software productivity calculated at the level of software product attributes to provide answers to individuals can be misleading because of the relevant questions and achieve process and product many factors that can affect the individual pro- improvement goals. Needed data can be collected ductivity of software engineers. and retained in a repository; the data can be ana- Standardized definitions and counting rules lyzed and models can be constructed. Validation for measurement of software processes and work and refinement of software information models products are necessary to provide standardized occur during software projects and after projects measurement results across projects within an are completed to ensure that the level of accuracy organization, to populate a repository of histori- is sufficient and that their limitations are known cal data that can be analyzed to identify software and understood. Software information models may processes that need to be improved, and to build also be developed for contexts other than software predictive models based on accumulated data. In projects; for example, a software information the example above, definitions of software defects model might be developed for processes that apply and staff-hours of testing effort plus counting across an organization, such as software configu- rules for defects and effort would be necessary to ration management or software quality assurance obtain satisfactory measurement results. processes at the organizational level. The extent to which the software process is Analysis-driven software information model institutionalized is important; failure to institu- building involves the development, calibration, tionalize a software process may explain why and evaluation of a model. A software infor- “good” software processes do not always pro- mation model is developed by establishing a duce anticipated results. Software processes may hypothesized transformation of input variables be institutionalized by adoption within the local into desired outputs; for example, product size organizational unit or across larger units of an and complexity might be transformed into esti- enterprise. mated effort needed to develop a software product using a regression equation developed from 4.2. Quality of Measurement Results observed data from past projects. A model is [4*, s3.4–3.7] calibrated by adjusting parameters in the model to match observed results from past projects; for The quality of process and product measurement example, the exponent in a nonlinear regression results is primarily determined by the reliability model might be changed by applying the regres- and validity of the measured results. Measure- sion equation to a different set of past projects ments that do not satisfy these quality criteria other than the projects used to develop the model. can result in incorrect interpretations and faulty A model is evaluated by comparing computed software process improvement initiatives. Other results to actual outcomes for a different set of desirable properties of software measurements similar data. There are three possible evaluation include ease of collection, analysis, and presenta- outcomes: tion plus a strong correlation between cause and effect. 1. results computed for a different data set vary The Software Engineering Measurement topic widely from actual outcomes for that data in the Software Engineering Management KA set, in which case the derived model is not describes a process for implementing a software applicable for the new data set and should measurement program. not be applied to analyze or make predictions for future projects; Software Engineering Process 8-11

2. results computed for a new data set are Process measurement techniques also provide close to actual outcomes for that data set, the information needed to measure the effects of in which case minor adjustments are made process improvement initiatives. Process mea- to the parameters of the model to improve surement techniques can be used to collect both agreement; quantitative and qualitative data. 3. results computed for the new data set and subsequent data sets are very close and no 4.4.1. Quantitative Process Measurement adjustments to the model are needed. Techniques [4*, s5.1, s5.7, s9.8] Continuous evaluation of the model may indicate a need for adjustments over time as the con- The purpose of quantitative process measurement text in which the model is applied changes. techniques is to collect, transform, and analyze The Goals/Questions/Metrics (GQM) method quantitative process and work product data that was originally intended for establishing measure- can be used to indicate where process improvement activities, but it can also be used to guide ments are needed and to assess the results of analysis and improvement of software processes. process improvement initiatives. Quantitative It can be used to guide analysis-driven software process measurement techniques are used to col- information model building; results obtained lect and analyze data in numerical form to which from the software information model can be used mathematical and statistical techniques can be to guide process improvement. applied. The following example illustrates application Quantitative process data can be collected as of the GQM method: a byproduct of software processes. For example, the number of defects discovered during software • Goal: Reduce the average change request testing and the staff-hours expended can be col- processing time by 10% within six months. lected by direct measurement, and the productiv- • Question 1-1: What is the baseline change ity of defect discovery can be derived by calculat- request processing time? ing defects discovered per staff-hour. • Metric 1-1-1: Average of change request Basic tools for quality control can be used to processing times on starting date analyze quantitative process measurement data • Metric 1-1-2: Standard deviation of change (e.g., check sheets, Pareto diagrams, histograms, request processing times on starting date scatter diagrams, run charts, control charts, and • Question 1-2: What is the current change cause-and-effect diagrams) (see Root Cause request processing time? Analysis in the Engineering Foundations KA). In • Metric 1-2-1: Average of change request addition, various statistical techniques can be used processing times currently that range from calculation of medians and means • Metric 1-2-2: Standard deviation of change to multivariate analysis methods (see Statistical request processing times currently Analysis in the Engineering Foundations KA). Data collected using quantitative process mea- 4.4. Software Process Measurement Techniques surement techniques can also be used as inputs [1*, c8] to simulation models (see Modeling, Prototyp- ing, and Simulation in the Engineering Founda- Software process measurement techniques are tions KA); these models can be used to assess the used to collect process data and work product impact of various approaches to software process data, transform the data into useful information, improvement. and analyze the information to identify process Orthogonal Defect Classification (ODC) can activities that are candidates for improvement. be used to analyze quantitative process measure- In some cases, new software processes may be ment data. ODC can be used to group detected needed. defects into categories and link the defects in 8-12 SWEBOK® Guide V3.0

each category to the software process or soft- addition, general purpose business tools, such as ware processes where a group of defects origi- a spreadsheet, may be useful. nated (see Defect Characterization in the Soft- Computer-Assisted Software Engineering ware Quality KA). Software interface defects, (CASE) tools can reinforce the use of integrated for example, may have originated during an inad- processes, support the execution of process defi- equate software design process; improving the nitions, and provide guidance to humans in per- software design process will reduce the number forming well-defined processes. Simple tools of software interface defects. ODC can provide such as word processors and spreadsheets can quantitative data for applying root cause analysis. be used to prepare textual descriptions of pro- Statistical Process Control can be used to track cesses, activities, and tasks; these tools also sup- process stability, or the lack of process stability, port traceability among the inputs and outputs of using control charts. multiple software processes (such as stakeholder needs analysis, software requirements specifica- 4.4.2. Qualitative Process Measurement tion, software architecture, and software detailed Techniques design) as well as the results of software pro- [1*, s6.4] cesses such as documentation, software components, test cases, and problem reports. Qualitative process measurement techniques— Most of the knowledge areas in this Guide including interviews, questionnaires, and expert describe specialized tools that can be used to judgment—can be used to augment quantitative manage the processes within that KA. In particu- process measurement techniques. Group consen- lar, see the Software Configuration Management sus techniques, including the Delphi technique, KA for a discussion of software configuration can be used to obtain consensus among groups of management tools that can be used to manage the stakeholders. construction, integration, and release processes for software products. Other tools, such as those 5. Software Engineering Process Tools for requirements management and testing, are [1*, s8.7] described in the appropriate KAs. Software process tools can support projects Software process tools support many of the nota- that involve geographically dispersed (virtual) tions used to define, implement, and manage teams. Increasingly, software process tools are individual software processes and software life available through cloud computing facilities as cycle models. They include editors for notations well as through dedicated infrastructures. such as data-flow diagrams, state charts, BPMN, A project control panel or dashboard can dis- IDEF0 diagrams, Petri nets, and UML activity play selected process and product attributes for diagrams. In some cases, software process tools software projects and indicate measurements that allow different types of analyses and simula- are within control limits and those needing cor- tions (for example, discrete event simulation). In rective action. Software Engineering Process 8-13

MATRIX OF TOPICS VS. REFERENCE MATERIAL [1*] [4*] [2*] [3*] Kan 2003 Moore 2009Moore Fairley 2009Fairley Sommerville 2011 p28–29, 1. Software Process Definition p177 p295 p36, c5 1.1. Software Process Management s26.1 p453–454 p183, p186 1.2. Software Process Infrastructure p437–438

2. Software Life Cycles c2 p190 c22, c23, 2.1. Categories of Software Processes preface p294–295 c24 2.2. Software Life Cycle Models c2 s3.2 s2.1 2.3. Software Process Adaptation s2.7 p51 2.4. Practical Considerations p188–190 3. Software Process Assessment and p188, p194 c26 p397, c15 Improvement s4.5, 3.1. Software Process Assessment Models s26.5 p44–48 s4.6 3.2. Software Process Assessment p44–48, p322–331 s26.3 Methods s16.4 3.3. Software Process Improvement p187–188 s26.5 s2.7 Models 3.4. Continuous and Staged Ratings p28–34 s26.5 p39–45 4. Software Measurement s26.2 s18.1.1 4.1. Software Process and Product s6.3, s26.2, Measurement p273 p638 s3.4, s3.5, 4.2. Quality of Measurement Results s3.6, s3.7 4.3. Software Information Models p310–311 p. 712–713 s19.2 s5.1, 4.4. Software Process Measurement s6.4, s5.7, Techniques c8 s9.8 5. Software Engineering Process Tools s8.7 8-14 SWEBOK® Guide V3.0

FURTHER READINGS REFERENCES

Software Extension to the Guide to the Project [1*] R.E. Fairley, Managing and Leading Management Body of Knowledge® (SWX) Software Projects, Wiley-IEEE Computer [5]. Society Press, 2009.

SWX provides adaptations and extensions to the [2*] J.W. Moore, The Road Map to Software generic practices of project management docu- Engineering: A Standards-Based Guide, mented in the PMBOK® Guide for managing Wiley-IEEE Computer Society Press, 2006. software projects. The primary contribution of this extension to the PMBOK® Guide is descrip- [3*] I. Sommerville, Software Engineering, 9th tion of processes that are applicable for managing ed., Addison-Wesley, 2011. adaptive life cycle software projects. [4*] S.H. Kan, Metrics and Models in Software D. Gibson, D. Goldenson, and K. Kost, Quality Engineering, 2nd ed., Addison- “Performance Results of CMMI-Based Wesley, 2002. Process Improvement” [6]. [5] Project Management Institute and IEEE This technical report summarizes publicly avail- Computer Society, Software Extension able empirical evidence about the performance to the PMBOK® Guide Fifth Edition, ed: results that can occur as a consequence of CMMI- Project Management Institute, 2013. based process improvement. The report contains a series of brief case descriptions that were cre- [6] D. Gibson, D. Goldenson, and K. Kost, ated with collaboration from representatives “Performance Results of CMMI-Based from 10 organizations that have achieved notable Process Improvement,” Software quantitative performance results through their Engineering Institute, 2006; http:// CMMI-based improvement efforts. resources.sei.cmu.edu/library/asset-view. cfm?assetID=8065. CMMI® for Development, Version 1.3 [7]. [7] CMMI Product Team, “CMMI for CMMI® for Development, Version 1.3 provides an Development, Version 1.3,” Software integrated set of process guidelines for develop- Engineering Institute, 2010; http:// ing and improving products and services. These resources.sei.cmu.edu/library/asset-view. guidelines include best practices for developing cfm?assetID=9661. and improving products and services to meet the needs of customers and end users. [8] ISO/IEC 15504-1:2004, Information Technology—Process Assessment—Part 1: ISO/IEC 15504-1:2004 Information tech- Concepts and Vocabulary, ISO/IEC, 2004. nology—Process assessment—Part 1: Concepts and vocabulary [8].

This standard, commonly known as SPICE (Software Process Improvement and Capability Determination), includes multiple parts. Part 1 provides concepts and vocabulary for software development processes and related business- management functions. Other parts of 15504 define the requirements and procedures for performing process assessments. CHAPTER 9

SOFTWARE ENGINEERING MODELS AND METHODS

ACRONYMS BREAKDOWN OF TOPICS FOR SOFTWARE ENGINEERING MODELS 3GL 3rd Generation Language AND METHODS BNF Backus-Naur Form FDD Feature-Driven Development This chapter on software engineering models and Integrated Development methods is divided into four main topic areas: IDE Environment • Modeling: discusses the general practice PBI Product Backlog Item of modeling and presents topics in model- RAD Rapid Application Development ing principles; properties and expression of UML Unified Modeling Language models; modeling syntax, semantics, and XP eXtreme Programming pragmatics; and preconditions, postconditions, and invariants. • Types of Models: briefly discusses models INTRODUCTION and aggregation of submodels and provides some general characteristics of model types Software engineering models and methods commonly found in the software engineering impose structure on software engineering with practice. the goal of making that activity systematic, • Analysis of Models: presents some of the repeatable, and ultimately more success-oriented. common analysis techniques used in model- Using models provides an approach to problem ing to verify completeness, consistency, cor- solving, a notation, and procedures for model rectness, traceability, and interaction. construction and analysis. Methods provide an • Software Engineering Methods: presents a approach to the systematic specification, design, brief summary of commonly used software construction, test, and verification of the end-item engineering methods. The discussion guides software and associated work products. the reader through a summary of heuristic Software engineering models and methods methods, formal methods, prototyping, and vary widely in scope—from addressing a single agile methods. software life cycle phase to covering the complete software life cycle. The emphasis in this The breakdown of topics for the Software knowledge area (KA) is on software engineer- Engineering Models and Methods KA is shown ing models and methods that encompass multiple in Figure 9.1. software life cycle phases, since methods specific for single life cycle phases are covered by other 1. Modeling KAs. Modeling of software is becoming a pervasive technique to help software engineers understand,

9-1 9-2 SWEBOK® Guide V3.0

Figure 9.1. Breakdown of Topics for the Software Engineering Models and Methods KA engineer, and communicate aspects of the soft- significant decisions to others in the stakeholder ware to appropriate stakeholders. Stakeholders communities. There are three general principles are those persons or parties who have a stated guiding such modeling activities: or implied interest in the software (for example, user, buyer, supplier, architect, certifying author- • Model the Essentials: good models do not ity, evaluator, developer, software engineer, and usually represent every aspect or feature of perhaps others). the software under every possible condition. While there are many modeling languages, Modeling typically involves developing only notations, techniques, and tools in the literature those aspects or features of the software that and in practice, there are unifying general con- need specific answers, abstracting away any cepts that apply in some form to them all. The nonessential information. This approach following sections provide background on these keeps the models manageable and useful. general concepts. • Provide Perspective: modeling provides views of the software under study using 1.1. Modeling Principles a defined set of rules for expression of the [1*, c2s2, c5s1, c5s2] [2*, c2s2] [3*, c5s0] model within each view. This perspective- driven approach provides dimensionality to Modeling provides the software engineer with the model (for example, a structural view, an organized and systematic approach for repre- behavioral view, temporal view, organiza- senting significant aspects of the software under tional view, and other views as relevant). study, facilitating decision-making about the soft- Organizing information into views focuses ware or elements of it, and communicating those the software modeling efforts on specific Software Engineering Models and Methods 9-3

concerns relevant to that view using the Models are constructed to represent real-world appropriate notation, vocabulary, methods, objects and their behaviors to answer specific and tools. questions about how the software is expected • Enable Effective Communications: modeling to operate. Interrogating the models—either employs the application domain vocabulary through exploration, simulation, or review—may of the software, a modeling language, and expose areas of uncertainty within the model and semantic expression (in other words, mean- the software to which the model refers. These ing within context). When used rigorously uncertainties or unanswered questions regarding and systematically, this modeling results in the requirements, design, and/or implementation a reporting approach that facilitates effective can then be handled appropriately. communication of software information to The primary expression element of a model is project stakeholders. an entity. An entity may represent concrete artifacts (for example, processors, sensors, or robots) A model is an abstraction or simplification of or abstract artifacts (for example, software mod- a software component. A consequence of using ules or communication protocols). Model enti- abstraction is that no single abstraction com- ties are connected to other entities using rela- pletely describes a software component. Rather, tions (in other words, lines or textual operators the model of the software is represented as an on target entities). Expression of model entities aggregation of abstractions, which—when taken may be accomplished using textual or graphical together—describe only selected aspects, per- modeling languages; both modeling language spectives, or views—only those that are needed types connect model entities through specific lan- to make informed decisions and respond to the guage constructs. The meaning of an entity may reasons for creating the model in the first place. be represented by its shape, textual attributes, or This simplification leads to a set of assumptions both. Generally, textual information adheres to about the context within which the model is language-specific syntactic structure. The- pre placed that should also be captured in the model. cise meanings related to the modeling of context, Then, when reusing the model, these assumptions structure, or behavior using these entities and can be validated first to establish the relevancy of relations is dependent on the modeling language the reused model within its new use and context. used, the design rigor applied to the modeling effort, the specific view being constructed, and 1.2. Properties and Expression of Models the entity to which the specific notation element [1*, c5s2, c5s3] [3*, c4s1.1p7, c4s6p3, may be attached. Multiple views of the model c5s0p3] may be required to capture the needed semantics of the software. Properties of models are those distinguishing fea- When using models supported with automa- tures of a particular model used to characterize tion, models may be checked for completeness its completeness, consistency, and correctness and consistency. The usefulness of these checks within the chosen modeling notation and tooling depends greatly on the level of semantic and syn- used. Properties of models include the following: tactic rigor applied to the modeling effort in addition to explicit tool support. Correctness is typi- • Completeness: the degree to which all cally checked through simulation and/or review. requirements have been implemented and verified within the model. 1.3. Syntax, Semantics, and Pragmatics • Consistency: the degree to which the model [2* c2s2.2.2p6] [3*, c5s0] contains no conflicting requirements, assertions, constraints, functions, or component Models can be surprisingly deceptive. The fact descriptions. that a model is an abstraction with missing infor- • Correctness: the degree to which the model mation can lead one into a false sense of com- satisfies its requirements and design specifi- pletely understanding the software from a single cations and is free of defects. model. A complete model (“complete” being 9-4 SWEBOK® Guide V3.0

relative to the modeling effort) may be a union can be introduced, leading to errors. With many of multiple submodels and any special function software engineers working on a model part over models. Examination and decision-making rela- time coupled with tool updates and perhaps new tive to a single model within this collection of requirements, there are opportunities for portions submodels may be problematic. of the model to represent something different Understanding the precise meanings of mod- from the original author’s intent and initial model eling constructs can also be difficult. Modeling context. languages are defined by syntactic and semantic rules. For textual languages, syntax is defined 1.4. Preconditions, Postconditions, and using a notation grammar that defines valid lan- Invariants guage constructs (for example, Backus-Naur [2*, c4s4] [4*, c10s4p2, c10s5p2p4] Form (BNF)). For graphical languages, syntax is defined using graphical models called metamod- When modeling functions or methods, the soft- els. As with BNF, metamodels define the valid ware engineer typically starts with a set of syntactical constructs of a graphical modeling assumptions about the state of the software prior language; the metamodel defines how these con- to, during, and after the function or method exe- structs can be composed to produce valid models. cutes. These assumptions are essential to the cor- Semantics for modeling languages specify the rect operation of the function or method and are meaning attached to the entities and relations grouped, for discussion, as a set of preconditions, captured within the model. For example, a simple postconditions, and invariants. diagram of two boxes connected by a line is open to a variety of interpretations. Knowing that the • Preconditions: a set of conditions that must diagram on which the boxes are placed and con- be satisfied prior to execution of the function nected is an object diagram or an activity diagram or method. If these preconditions do not hold can assist in the interpretation of this model. prior to execution of the function or method, As a practical matter, there is usually a good the function or method may produce errone- understanding of the semantics of a specific ous results. software model due to the modeling language • Postconditions: a set of conditions that is selected, how that modeling language is used to guaranteed to be true after the function or express entities and relations within that model, method has executed successfully. Typically, the experience base of the modeler(s), and the the postconditions represent how the state context within which the modeling has been of the software has changed, how param- undertaken and so represented. Meaning is com- eters passed to the function or method have municated through the model even in the presence changed, how data values have changed, or of incomplete information through abstraction; how the return value has been affected. pragmatics explains how meaning is embodied • Invariants: a set of conditions within the in the model and its context and communicated operational environment that persist (in effectively to other software engineers. other words, do not change) before and after There are still instances, however, where cau- execution of the function or method. These tion is needed regarding modeling and semantics. invariants are relevant and necessary to the For example, any model parts imported from software and the correct operation of the another model or library must be examined for function or method. semantic assumptions that conflict in the new modeling environment; this may not be obvious. 2. Types of Models The model should be checked for documented assumptions. While modeling syntax may be A typical model consists of an aggregation of identical, the model may mean something quite submodels. Each submodel is a partial descrip- different in the new environment, which is a dif- tion and is created for a specific purpose; it may ferent context. Also, consider that as software be comprised of one or more diagrams. The matures and changes are made, semantic discord collection of submodels may employ multiple Software Engineering Models and Methods 9-5

modeling languages or a single modeling lan- 2.3. Structure Modeling guage. The Unified Modeling Language (UML) [1*, c7s2.5, c7s3.1, c7s3.2] [3*, c5s3] [4*, c4] recognizes a rich collection of modeling diagrams. Use of these diagrams, along with the Structure models illustrate the physical or logical modeling language constructs, brings about three composition of software from its various com- broad model types commonly used: information ponent parts. Structure modeling establishes the models, behavioral models, and structure models defined boundary between the software being (see section 1.1). implemented or modeled and the environment in which it is to operate. Some common struc- 2.1. Information Modeling tural constructs used in structure modeling are [1*, c7s2.2] [3*, c8s1] composition, decomposition, generalization, and specialization of entities; identification of -rel Information models provide a central focus on evant relations and cardinality between entities; data and information. An information model is an and the definition of process or functional inter- abstract representation that identifies and defines faces. Structure diagrams provided by the UML a set of concepts, properties, relations, and confor structure modeling include class, component, straints on data entities. The semantic or concep- object, deployment, and packaging diagrams. tual information model is often used to provide some formalism and context to the software being 3. Analysis of Models modeled as viewed from the problem perspective, without concern for how this model is actually The development of models affords the software mapped to the implementation of the software. engineer an opportunity to study, reason about, The semantic or conceptual information model and understand the structure, function, opera- is an abstraction and, as such, includes only the tional usage, and assembly considerations asso- concepts, properties, relations, and constraints ciated with software. Analysis of constructed needed to conceptualize the real-world view of models is needed to ensure that these models are the information. Subsequent transformations of complete, consistent, and correct enough to serve the semantic or conceptual information model their intended purpose for the stakeholders. lead to the elaboration of logical and then physi- The sections that follow briefly describe the cal data models as implemented in the software. analysis techniques generally used with software models to ensure that the software engineer 2.2. Behavioral Modeling and other relevant stakeholders gain appropriate [1*, c7s2.1, c7s2.3, c7s2.4] [2*, c9s2] value from the development and use of models. [3*, c5s4] 3.1. Analyzing for Completeness Behavioral models identify and define the func- [3*, c4s1.1p7, c4s6] [5*, p8–11] tions of the software being modeled. Behav- ioral models generally take three basic forms: In order to have software that fully meets the needs state machines, control-flow models, and data- of the stakeholders, completeness is critical—from flow models. State machines provide a model the requirements elicitation process to code imple- of the software as a collection of defined states, mentation. Completeness is the degree to which events, and transitions. The software transitions all of the specified requirements have been imple- from one state to the next by way of a guarded mented and verified. Models may be checked for or unguarded triggering event that occurs in the completeness by a modeling tool that uses tech- modeled environment. Control-flow models niques such as structural analysis and state-space depict how a sequence of events causes processes reachability analysis (which ensure that all paths in to be activated or deactivated. Data-flow behav- the state models are reached by some set of correct ior is typified as a sequence of steps where data inputs); models may also be checked for complete- moves through processes toward data stores or ness manually by using inspections or other review data sinks. techniques (see the Software Quality KA). Errors 9-6 SWEBOK® Guide V3.0

and warnings generated by these analysis tools and and pseudo-code, handwritten and tool-generated found by inspection or review indicate probable code, manual and automated test cases and reports, needed corrective actions to ensure completeness and files and data. These work products may be of the models. related through various dependency relationships (for example, uses, implements, and tests). As soft- 3.2. Analyzing for Consistency ware is being developed, managed, maintained, or [3*, c4s1.1p7, c4s6] [5*, p8–11] extended, there is a need to map and control these traceability relationships to demonstrate soft- Consistency is the degree to which models con- ware requirements consistency with the software tain no conflicting requirements, assertions, - con model (see Requirements Tracing in the Software straints, functions, or component descriptions. Requirements KA) and the many work products. Typically, consistency checking is accomplished Use of traceability typically improves the manage- with the modeling tool using an automated analysis ment of software work products and software pro- function; models may also be checked for consis- cess quality; it also provides assurances to stake- tency manually using inspections or other review holders that all requirements have been satisfied. techniques (see the Software Quality KA). As Traceability enables change analysis once the soft- with completeness, errors and warnings generated ware is developed and released, since relationships by these analysis tools and found by inspection or to software work products can easily be traversed review indicate the need for corrective action. to assess change impact. Modeling tools typically provide some automated or manual means to spec- 3.3. Analyzing for Correctness ify and manage traceability links between require- [5*, p8–11] ments, design, code, and/or test entities as may be represented in the models and other software work Correctness is the degree to which a model sat- products. (For more information on traceability, isfies its software requirements and software see the Software Configuration Management KA). design specifications, is free of defects, and ultimately meets the stakeholders’ needs. Analyzing 3.5. Interaction Analysis for correctness includes verifying syntactic cor- [2*, c10, c11] [3*, c29s1.1, c29s5] [4*, c5] rectness of the model (that is, correct use of the modeling language grammar and constructs) and Interaction analysis focuses on the communica- verifying semantic correctness of the model (that tions or control flow relations between entities is, use of the modeling language constructs to used to accomplish a specific task or function correctly represent the meaning of that which is within the software model. This analysis exam- being modeled). To analyze a model for syntactic ines the dynamic behavior of the interactions and semantic correctness, one analyzes it—either between different portions of the software model, automatically (for example, using the modeling including other software layers (such as the oper- tool to check for model syntactic correctness) ating system, middleware, and applications). It or manually (using inspections or other review may also be important for some software applica- techniques)—searching for possible defects and tions to examine interactions between the com- then removing or repairing the confirmed defects puter software application and the user interface before the software is released for use. software. Some software modeling environments provide simulation facilities to study aspects of 3.4. Traceability the dynamic behavior of modeled software. Step- [3*, c4s7.1, c4s7.2] ping through the simulation provides an analysis option for the software engineer to review the Developing software typically involves the use, interaction design and verify that the different creation, and modification of many work products parts of the software work together to provide the such as planning documents, process specifica- intended functions. tions, software requirements, diagrams, designs Software Engineering Models and Methods 9-7

4. Software Engineering Methods database designs or data repositories typically found in business software, where data Software engineering methods provide an orga- is actively managed as a business systems nized and systematic approach to developing soft- resource or asset. ware for a target computer. There are numerous • Object-Oriented Analysis and Design Meth- methods from which to choose, and it is important ods: The object-oriented model is represented for the software engineer to choose an appropriate as a collection of objects that encapsulate method or methods for the software development data and relationships and interact with other task at hand; this choice can have a dramatic effect objects through methods. Objects may be on the success of the software project. Use of these real-world items or virtual items. The soft- software engineering methods coupled with people ware model is constructed using diagrams of the right skill set and tools enable the software to constitute selected views of the software. engineers to visualize the details of the software Progressive refinement of the software mod- and ultimately transform the representation into a els leads to a detailed design. The detailed working set of code and data. design is then either evolved through suc- Selected software engineering methods are dis- cessive iteration or transformed (using some cussed below. The topic areas are organized into mechanism) into the implementation view discussions of Heuristic Methods, Formal Meth- of the model, where the code and packag- ods, Prototyping Methods, and Agile Methods. ing approach for eventual software product release and deployment is expressed. 4.1. Heuristic Methods [1*, c13, c15, c16] [3*, c2s2.2, c5s4.1, c7s1,] 4.2. Formal Methods [1*, c18] [3*, c27] [5*, p8–24] Heuristic methods are those experience-based software engineering methods that have been and Formal methods are software engineering meth- are fairly widely practiced in the software indus- ods used to specify, develop, and verify the soft- try. This topic area contains three broad discus- ware through application of a rigorous mathemat- sion categories: structured analysis and design ically based notation and language. Through use methods, data modeling methods, and object- of a specification language, the software model oriented analysis and design methods. can be checked for consistency (in other words, lack of ambiguity), completeness, and correctness • Structured Analysis and Design Methods: in a systematic and automated or semi-automated The software model is developed primarily fashion. This topic is related to the Formal Analy- from a functional or behavioral viewpoint, sis section in the Software Requirements KA. starting from a high-level view of the soft- This section addresses specification languages, ware (including data and control elements) program refinement and derivation, formal verifi- and then progressively decomposing or refin- cation, and logical inference. ing the model components through increasingly detailed designs. The detailed design • Specification Languages: Specification eventually converges to very specific details languages provide the mathematical basis or specifications of the software that must be for a formal method; specification lan- coded (by hand, automatically generated, or guages are formal, higher level computer both), built, tested, and verified. languages (in other words, not a classic • Data Modeling Methods: The data model is 3rd Generation Language (3GL) program- constructed from the viewpoint of the data or ming language) used during the software information used. Data tables and relation- specification, requirements analysis, and/ ships define the data models. This data mod- or design stages to describe specific input/ eling method is used primarily for defining output behavior. Specification languages are and analyzing data requirements supporting not directly executable languages; they are 9-8 SWEBOK® Guide V3.0

typically comprised of a notation and syntax, 4.3. Prototyping Methods semantics for use of the notation, and a set of [1*, c12s2] [3*, c2s3.1] [6*, c7s3p5] allowed relations for objects. • Program Refinement and Derivation: Pro- Software prototyping is an activity that generally gram refinement is the process of creating a creates incomplete or minimally functional ver- lower level (or more detailed) specification sions of a software application, usually for try- using a series of transformations. It is through ing out specific new features, soliciting feedback successive transformations that the software on software requirements or user interfaces, fur- engineer derives an executable representation ther exploring software requirements, software of a program. Specifications may be refined, design, or implementation options, and/or gaining adding details until the model can be formu- some other useful insight into the software. The lated in a 3GL programming language or in software engineer selects a prototyping method to an executable portion of the chosen specifica- understand the least understood aspects or com- tion language. This specification refinement is ponents of the software first; this approach is in made possible by defining specifications with contrast with other software engineering methods precise semantic properties; the specifications that usually begin development with the most must set out not only the relationships between understood portions first. Typically, the proto- entities but also the exact runtime meanings of typed product does not become the final software those relationships and operations. product without extensive development rework • Formal Verification: Model checking is or refactoring. a formal verification method; it typically This section discusses prototyping styles, tar- involves performing a state-space explora- gets, and evaluation techniques in brief. tion or reachability analysis to demonstrate that the represented software design has or • Prototyping Style: This addresses the various preserves certain model properties of inter- approaches to developing prototypes. Proto- est. An example of model checking is an types can be developed as throwaway code analysis that verifies correct program behav- or paper products, as an evolution of a work- ior under all possible interleaving of event or ing design, or as an executable specification. message arrivals. The use of formal verifi- Different prototyping life cycle processes are cation requires a rigorously specified model typically used for each style. The style cho- of the software and its operational environ- sen is based on the type of results the project ment; this model often takes the form of a needs, the quality of the results needed, and finite state machine or other formally defined the urgency of the results. automaton. • Prototyping Target: The target of the pro- • Logical Inference: Logical inference is a totype activity is the specific product being method of designing software that involves served by the prototyping effort. Examples specifying preconditions and postconditions of prototyping targets include a requirements around each significant block of the design, specification, an architectural design element and—using mathematical logic—developing or component, an algorithm, or a human- the proof that those preconditions and post- machine user interface. conditions must hold under all inputs. This • Prototyping Evaluation Techniques: A pro- provides a way for the software engineer to totype may be used or evaluated in a num- predict software behavior without having ber of ways by the software engineer or to execute the software. Some Integrated other project stakeholders, driven primarily Development Environments (IDEs) include by the underlying reasons that led to pro- ways to represent these proofs along with the totype development in the first place. Pro- design or code. totypes may be evaluated or tested against the actual implemented software or against Software Engineering Models and Methods 9-9

a target set of requirements (for example, a • Scrum: This agile approach is more project requirements prototype); the prototype may management-friendly than the others. The also serve as a model for a future software scrum master manages the activities within development effort (for example, as in a user the project increment; each increment is interface specification). called a sprint and lasts no more than 30 days. A Product Backlog Item (PBI) list is 4.4. Agile Methods developed from which tasks are identified, [3*, c3] [6*, c7s3p7] [7*, c6, App. A] defined, prioritized, and estimated. A working version of the software is tested and Agile methods were born in the 1990s from the released in each increment. Daily scrum need to reduce the apparent large overhead associ- meetings ensure work is managed to plan. ated with heavyweight, plan-based methods used • FDD: This is a model-driven, short, itera- in large-scale software-development projects. tive software development approach using Agile methods are considered lightweight meth- a five-phase process: (1) develop a product ods in that they are characterized by short, itera- model to scope the breadth of the domain, (2) tive development cycles, self-organizing teams, create the list of needs or features, (3) build simpler designs, code refactoring, test-driven the feature development plan, (4) develop development, frequent customer involvement, and designs for iteration-specific features, and an emphasis on creating a demonstrable working (5) code, test, and then integrate the features. product with each development cycle. FDD is similar to an incremental software Many agile methods are available in the lit- development approach; it is also similar to erature; some of the more popular approaches, XP, except that code ownership is assigned which are discussed here in brief, include Rapid to individuals rather than the team. FDD Application Development (RAD), eXtreme Pro- emphasizes an overall architectural approach gramming (XP), Scrum, and Feature-Driven to the software, which promotes building the Development (FDD). feature correctly the first time rather than emphasizing continual refactoring. • RAD: Rapid software development methods are used primarily in data-intensive, business- There are many more variations of agile meth- systems application development. The RAD ods in the literature and in practice. Note that method is enabled with special-purpose data- there will always be a place for heavyweight, base development tools used by software plan-based software engineering methods as well engineers to quickly develop, test, and deploy as places where agile methods shine. There are new or modified business applications. new methods arising from combinations of agile • XP: This approach uses stories or scenarios and plan-based methods where practitioners are for requirements, develops tests first, has defining new methods that balance the features direct customer involvement on the team needed in both heavyweight and lightweight (typically defining acceptance tests), uses methods based primarily on prevailing organi- pair programming, and provides for continu- zational business needs. These business needs, ous code refactoring and integration. Stories as typically represented by some of the project are decomposed into tasks, prioritized, esti- stakeholders, should and do drive the choice in mated, developed, and tested. Each incre- using one software engineering method over ment of software is tested with automated another or in constructing a new method from the and manual tests; an increment may be best features of a combination of software engi- released frequently, such as every couple of neering methods. weeks or so. 9-10 SWEBOK® Guide V3.0

MATRIX OF TOPICS VS. REFERENCE MATERIAL [1*] [4*] [6*] [2*] [3*] [5*] [7*] Wing 1990 Budgen 2003Budgen Page-Jones 1999 Brookshear 2008 Sommerville 2011 Mellor and Balcer 2002 Boehm and Turner 2003 Boehm and Turner 1. Modeling c2s2, 1.1. Modeling c5s1, c2s2 c5s0 Principles c5s2 1.2. Properties c4s1.1p7, c5s2, and Expression of c4s6p3, c5s3 Models c5s0p3 1.3. Syntax, c2s2.2.2 Semantics, and c5s0 p6 Pragmatics 1.4. Preconditions, c10s4p2, Postconditions, and c4s4 c10s5 Invariants p2p4 2. Types of Models 2.1. Information c7s2.2 c8s1 Modeling c7s2.1, 2.2. Behavioral c7s2.3, c9s2 c5s4 Modeling c7s2.4 c7s2.5, 2.3. Structure c7s3.1, c5s3 c4 Modeling c7s3.2 3. Analysis of Models 3.1. Analyzing for c4s1.1p7, pp8–11 Completeness c4s6 3.2. Analyzing for c4s1.1p7, pp8–11 Consistency c4s6 3.3. Analyzing for pp8–11 Correctness c4s7.1, 3.4. Traceability c4s7.2 3.5. Interaction c29s1.1, c10, c11 c5 Analysis c29s5 Software Engineering Models and Methods 9-11 [1*] [4*] [6*] [2*] [3*] [5*] [7*] Wing 1990 Budgen 2003Budgen Page-Jones 1999 Brookshear 2008 Sommerville 2011 Mellor and Balcer 2002 Boehm and Turner 2003 Boehm and Turner 4. Software Engineering Methods c2s2.2, 4.1. Heuristic c13, c15, c7s1, Methods c16 c5s4.1 4.2. Formal Methods c18 c27 pp8–24 4.3. Prototyping c12s2 c2s3.1 c7s3p5 Methods c6, app. 4.4. Agile Methods c3 c7s3p7 A 9-12 SWEBOK® Guide V3.0

REFERENCES [1*] D. Budgen, Software Design, 2nd ed., [5*] J.M. Wing, “A Specifier’s Introduction to Addison-Wesley, 2003. Formal Methods,” Computer, vol. 23, no. 9, 1990, pp. 8, 10–23. [2*] S.J. Mellor and M.J. Balcer, Executable UML: A Foundation for Model-Driven [6*] J.G. Brookshear, Computer Science: An Architecture, 1st ed., Addison-Wesley, Overview, 10th ed., Addison-Wesley, 2008. 2002. [7*] B. Boehm and R. Turner, Balancing Agility [3*] I. Sommerville, Software Engineering, 9th and Discipline: A Guide for the Perplexed, ed., Addison-Wesley, 2011. Addison-Wesley, 2003.

[4*] M. Page-Jones, Fundamentals of Object- Oriented Design in UML, 1st ed., Addison- Wesley, 1999. CHAPTER 10

SOFTWARE QUALITY

ACRONYMS quality,” where the “customer is the final arbiter” [3*, p8]. Capability Maturity Model CMMI More recently, software quality is defined as the Integration “capability of software product to satisfy stated CoSQ Cost of Software Quality and implied needs under specified conditions” [4] Commercial Off-the-Shelf and as “the degree to which a software product COTS Software meets established requirements; however, quality FMEA Failure Mode and Effects Analysis depends upon the degree to which those established requirements accurately represent stake- FTA Fault Tree Analysis holder needs, wants, and expectations” [5]. Both PDCA Plan-Do-Check-Act definitions embrace the premise of conformance PDSA Plan-Do-Study-Act to requirements. Neither refers to types of require- QFD Quality Function Deployment ments (e.g., functional, reliability, performance, dependability, or any other characteristic). Signifi- SPI Software Process Improvement cantly, however, these definitions emphasize that SQA Software Quality Assurance quality is dependent upon requirements. SQC Software Quality Control These definitions also illustrate another reason SQM Software Quality Management for the prevalence of software quality throughout this Guide: a frequent ambiguity of software TQM Total Quality Management quality versus software quality requirements V&V Verification and Validation (“the -ilities” is a common shorthand). Software quality requirements are actually attributes of (or constraints on) functional requirements (what INTRODUCTION the system does). Software requirements may also specify resource usage, a communication What is software quality, and why is it so impor- protocol, or many other characteristics. This KA tant that it is included in many knowledge areas attempts clarity by using software quality in the (KAs) of the SWEBOK Guide? broadest sense from the definitions above and One reason is that the term software quality is by using software quality requirements as con- overloaded. Software quality may refer: to desir- straints on functional requirements. Software able characteristics of software products, to the quality is achieved by conformance to all require- extent to which a particular software product pos- ments regardless of what characteristic is speci- sess those characteristics, and to processes, tools, fied or how requirements are grouped or named. and techniques used to achieve those character- Software quality is also considered in many of istics. Over the years, authors and organizations the SWEBOK KAs because it is a basic param- have defined the term quality differently. To Phil eter of a software engineering effort. For all engi- Crosby, it was “conformance to requirements” neered products, the primary goal is delivering [1]. Watts Humphrey refers to it as “achieving maximum stakeholder value, while balancing the excellent levels of “fitness for use” [2]. Mean- constraints of development cost and schedule; while, IBM coined the phrase “market-driven this is sometimes characterized as “fitness for

10-1 10-2 SWEBOK® Guide V3.0

Figure 10.1. Breakdown of Topics for the Software Quality KA use.” Stakeholder value is expressed in require- the many aspects of quality be formally defined ments. For software products, stakeholders could and discussed. value price (what they pay for the product), lead A software engineer should understand qual- time (how fast they get the product), and software ity concepts, characteristics, values, and their quality. application to the software under development or This KA addresses definitions and provides an maintenance. The important concept is that the overview of practices, tools, and techniques for software requirements define the required quality defining software quality and for appraising the attributes of the software. Software requirements state of software quality during development, influence the measurement methods and -accep maintenance, and deployment. Cited references tance criteria for assessing the degree to which provide additional details. the software and related documentation achieve the desired quality levels. BREAKDOWN OF TOPICS FOR SOFTWARE QUALITY 1.1. Software Engineering Culture and Ethics [3*, c1s4] [6*, c2s3.5] The breakdown of topics for the Software Quality KA is presented in Figure 10.1. Software engineers are expected to share a commitment to software quality as part of their culture. 1. Software Quality Fundamentals A healthy software engineering culture includes many characteristics, including the understanding Reaching agreement on what constitutes quality that tradeoffs among cost, schedule, and quality for all stakeholders and clearly communicating are a basic tenant of the engineering of any prod- that agreement to software engineers require that uct. A strong software engineering ethic assumes Software Quality 10-3

that engineers accurately report information, con- software product to the customer. External fail- ditions, and outcomes related to quality. ure costs include activities to respond to software Ethics also play a significant role in software problems discovered after delivery to the customer. quality, the culture, and the attitudes of software Software engineers should be able to use CoSQ engineers. The IEEE Computer Society and the methods to ascertain levels of software quality ACM have developed a code of ethics and pro- and should also be able to present quality alter- fessional practice (see Codes of Ethics and Pro- natives and their costs so that tradeoffs between fessional Conduct in the Software Engineering cost, schedule, and delivery of stakeholder value Professional Practice KA). can be made.

1.2. Value and Costs of Quality 1.3. Models and Quality Characteristics [7*, c17, c22] [3*, c24s1] [7*, c2s4] [8*, c17]

Defining and then achieving software quality is Terminology for software quality characteristics not simple. Quality characteristics may or may differs from one taxonomy (or model of software not be required, or they may be required to a quality) to another, each model perhaps having greater or lesser degree, and tradeoffs may be a different number of hierarchical levels and a made among them. To help determine the level different total number of characteristics. Various of software quality, i.e., achieving stakeholder authors have produced models of software qual- value, this section presents cost of software quality characteristics or attributes that can be useful ity (CoSQ): a set of measurements derived from for discussing, planning, and rating the quality the economic assessment of software quality of software products. ISO/IEC 25010: 2011 [4] development and maintenance processes. The defines product quality and quality in use as two CoSQ measurements are examples of process related quality models. Appendix B in the SWE- measurements that may be used to infer charac- BOK Guide provides a list of applicable standards teristics of a product. for each KA. Standards for this KA cover various The premise underlying the CoSQ is that the ways of characterizing software quality. level of quality in a software product can be inferred from the cost of activities related to deal- 1.3.1. Software Process Quality ing with the consequences of poor quality. Poor quality means that the software product does not Software quality management and software engi- fully “satisfy stated and implied needs” or “estab- neering process quality have a direct bearing on lished requirements.” There are four cost of qual- the quality of the software product. ity categories: prevention, appraisal, internal fail- Models and criteria that evaluate the capabili- ure, and external failure. ties of software organizations are primarily proj- Prevention costs include investments in software ect organization and management considerations process improvement efforts, quality infrastruc- and, as such, are covered in the Software Engi- ture, quality tools, training, audits, and manage- neering Management and Software Engineering ment reviews. These costs are usually not specific Process KAs. to a project; they span the organization. Appraisal It is not possible to completely distinguish pro- costs arise from project activities that find defects. cess quality from product quality because process These appraisal activities can be categorized into outcomes include products. Determining whether costs of reviews (design, peer) and costs of test- a process has the capability to consistently pro- ing (software unit testing, software integration, duce products of desired quality is not simple. system level testing, acceptance testing); appraisal The software engineering process, discussed costs would be extended to subcontracted software in the Software Engineering Process KA, influ- suppliers. Costs of internal failures are those that ences the quality characteristics of software prod- are incurred to fix defects found during appraisal ucts, which in turn affect quality as perceived by activities and discovered prior to delivery of the stakeholders. 10-4 SWEBOK® Guide V3.0

1.3.2. Software Product Quality in quality who have stated that the quality of a product is directly linked to the quality of the The software engineer, first of all, must determine process used to create it. Approaches such as the the real purpose of the software. In this regard, Deming improvement cycle of Plan-Do-Check- stakeholder requirements are paramount, and they Act (PDCA), evolutionary delivery, kaizen, and include quality requirements in addition to func- quality function deployment (QFD) offer tech- tional requirements. Thus, software engineers niques to specify quality objectives and determine have a responsibility to elicit quality requirements whether they are met. The Software Engineering that may not be explicit at the outset and to under- Institute’s IDEAL is another method [7*]. Qual- stand their importance as well as the level of diffi- ity management is now recognized by the SWE- culty in attaining them. All software development BOK Guide as an important discipline. processes (e.g., eliciting requirements, designing, Management sponsorship supports process and constructing, building, checking, improving qual- product evaluations and the resulting findings. ity) are designed with these quality requirements Then an improvement program is developed in mind and may carry additional development identifying detailed actions and improvement costs if attributes such as safety, security, and projects to be addressed in a feasible time frame. dependability are important. The additional devel- Management support implies that each improve- opment costs help ensure that quality obtained can ment project has enough resources to achieve the be traded off against the anticipated benefits. goal defined for it. Management sponsorship is The term work-product means any artifact that solicited frequently by implementing proactive is the outcome of a process used to create the communication activities. final software product. Examples of a work-product include a system/subsystem specification, a 1.5. Software Safety software requirements specification for a soft- [9*, c11s3] ware component of a system, a software design description, source code, software test documen- Safety-critical systems are those in which a sys- tation, or reports. While some treatments of qual- tem failure could harm human life, other living ity are described in terms of final software and things, physical structures, or the environment. system performance, sound engineering practice The software in these systems is safety-critical. requires that intermediate work-products relevant There are increasing numbers of applications to quality be evaluated throughout the software of safety-critical software in a growing number engineering process. of industries. Examples of systems with safety- critical software include mass transit systems, 1.4. Software Quality Improvement chemical manufacturing plants, and medical [3*, c1s4] [9*, c24] [10*, c11s2.4] devices. The failure of software in these systems could have catastrophic effects. There are indus- The quality of software products can be improved try standards, such as DO-178C [11], and emerg- through preventative processes or an itera- ing processes, tools, and techniques for develop- tive process of continual improvement, which ing safetycritical software. The intent of these requires management control, coordination, and standards, tools, and techniques is to reduce the feedback from many concurrent processes: (1) risk of injecting faults into the software and thus the software life cycle processes, (2) the process improve software reliability. of fault/defect detection, removal, and preven- Safety-critical software can be categorized as tion, and (3) the quality improvement process. direct or indirect. Direct is that software embed- The theory and concepts behind qual- ded in a safety-critical system, such as the flight ity improvement—such as building in quality control computer of an aircraft. Indirect includes through the prevention and early detection of software applications used to develop safety- defects, continual improvement, and stakeholder critical software. Indirect software is included in focus—are pertinent to software engineering. software engineering environments and software These concepts are based on the work of experts test environments. Software Quality 10-5

Three complementary techniques for reduc- comply with standards established for the project ing the risk of failure are avoidance, detection (including requirements, constraints, designs, and removal, and damage limitation. These contracts, and plans). SQC evaluates intermedi- techniques impact software functional require- ate products as well as the final products. ments, software performance requirements, and The fourth SQM category dealing with improve- development processes. Increasing levels of risk ment has various names within the software indus- imply increasing levels of software quality assur- try, including SPI, software quality improvement, ance and control techniques such as inspections. and software corrective and preventive action. The Higher risk levels may necessitate more thorough activities in this category seek to improve process inspections of requirements, design, and code effectiveness, efficiency, and other characteris- or the use of more formal analytical techniques. tics with the ultimate goal of improving software Another technique for managing and control- quality. Although SPI could be included in any of ling software risk is building assurance cases. An the first three categories, an increasing number assurance case is a reasoned, auditable artifact of organizations organize SPI into a separate cat- created to support the contention that its claim egory that may span across many projects (see the or claims are satisfied. It contains the following Software Engineering Process KA). and their relationships: one or more claims about Software quality processes consist of tasks properties; arguments that logically link the evi- and techniques to indicate how software plans dence and any assumptions to the claims; and a (e.g., software management, development, qual- body of evidence and assumptions supporting ity management, or configuration management these arguments [12]. plans) are being implemented and how well the intermediate and final products are meeting their 2. Software Quality Management Processes specified requirements. Results from these tasks are assembled in reports for management before Software quality management is the collection of corrective action is taken. The management of all processes that ensure that software products, an SQM process is tasked with ensuring that the services, and life cycle process implementations results of these reports are accurate. meet organizational software quality objectives Risk management can also play an important and achieve stakeholder satisfaction [13, 14]. role in delivering quality software. Incorporating SQM defines processes, process owners, require- disciplined risk analysis and management tech- ments for the processes, measurements of the niques into the software life cycle processes can processes and their outputs, and feedback chan- help improve product quality (see the Software nels throughout the whole software life cycle. Engineering Management KA for related mate- SQM comprises four subcategories: software rial on risk management). quality planning, software quality assurance (SQA), software quality control (SQC), and soft- 2.1. Software Quality Assurance ware process improvement (SPI). Software qual- [7*, c4–c6, c11, c12, c26–27] ity planning includes determining which quality standards are to be used, defining specific quality To quell a widespread misunderstanding, soft- goals, and estimating the effort and schedule of ware quality assurance is not testing. software software quality activities. In some cases, soft- quality assurance (SQA) is a set of activities that ware quality planning also includes defining the define and assess the adequacy of software pro- software quality processes to be used. SQA activ- cesses to provide evidence that establishes confi- ities define and assess the adequacy of software dence that the software processes are appropriate processes to provide evidence that establishes and produce software products of suitable qual- confidence that the software processes are appro- ity for their intended purposes. A key attribute of priate for and produce software products of suit- SQA is the objectivity of the SQA function with able quality for their intended purposes [5]. SQC respect to the project. The SQA function may activities examine specific project artifacts (docu- also be organizationally independent of the proj- ments and executables) to determine whether they ect; that is, free from technical, managerial, and 10-6 SWEBOK® Guide V3.0

financial pressures from the project [5]. SQA has life cycle. This assessment demonstrates two aspects: product assurance and process assur- whether the requirements are correct, com- ance, which are explained in section 2.3. plete, accurate, consistent, and testable. The software quality plan (in some industry The V&V processes determine whether sectors it is termed the software quality assurance the development products of a given activ- plan) defines the activities and tasks employed ity conform to the requirements of that to ensure that software developed for a specific activity and whether the product satisfies product satisfies the project’s established require- its intended use and user needs. ments and user needs within project cost and schedule constraints and is commensurate with Verification is an attempt to ensure that the project risks. The SQAP first ensures that quality product is built correctly, in the sense that the targets are clearly defined and understood. output products of an activity meet the specifi- The SQA plan’s quality activities and tasks are cations imposed on them in previous activities. specified with their costs, resource requirements, Validation is an attempt to ensure that the right objectives, and schedule in relation to related product is built—that is, the product fulfills its objectives in the software engineering manage- specific intended purpose. Both the verification ment, software development, and software main- process and the validation process begin early tenance plans. The SQA plan should be consis- in the development or maintenance phase. They tent with the software configuration management provide an examination of key product features plan (see the Software Configuration Manage- in relation to both the product’s immediate prede- ment KA). The SQA plan identifies documents, cessor and the specifications to be met. standards, practices, and conventions governing The purpose of planning V&V is to ensure that the project and how these items are checked and each resource, role, and responsibility is clearly monitored to ensure adequacy and compliance. assigned. The resulting V&V plan documents The SQA plan also identifies measures; statistical describe the various resources and their roles and techniques; procedures for problem reporting and activities, as well as the techniques and tools to be corrective action; resources such as tools, tech- used. An understanding of the different purposes of niques, and methodologies; security for physical each V&V activity helps in the careful planning of media; training; and SQA reporting and docu- the techniques and resources needed to fulfill their mentation. Moreover, the SQA plan addresses purposes. The plan also addresses the manage- the software quality assurance activities of any ment, communication, policies, and procedures of other type of activity described in the software the V&V activities and their interaction, as well as plans—such as procurement of supplier software defect reporting and documentation requirements. for the project, commercial off-the-shelf software (COTS) installation, and service after delivery of 2.3. Reviews and Audits the software. It can also contain acceptance crite- [9*, c24s3] [16*] ria as well as reporting and management activities that are critical to software quality. Reviews and audit processes are broadly defined as static—meaning that no software programs or 2.2. Verification & Validation models are executed—examination of software [9*, c2s2.3, c8, c15s1.1, c21s3.3] engineering artifacts with respect to standards that have been established by the organization or proj- As stated in [15], ect for those artifacts. Different types of reviews and audits are distinguished by their purpose, lev- The purpose of V&V is to help the devel- els of independence, tools and techniques, roles, opment organization build quality into the and by the subject of the activity. Product assur- system during the life cycle. V&V pro- ance and process assurance audits are typically cesses provide an objective assessment conducted by software quality assurance (SQA) of products and processes throughout the personnel who are independent of development Software Quality 10-7

teams. Management reviews are conducted by 2.3.2. Technical Reviews organizational or project management. The engineering staff conducts technical reviews. As stated in [16*],

• Management reviews evaluate actual project The purpose of a technical review is to results with respect to plans. evaluate a software product by a team of • Technical reviews (including inspections, qualified personnel to determine its - suit walkthrough, and desk checking) examine ability for its intended use and identify engineering work-products. discrepancies from specifications and • Process assurance audits. SQA process standards. It provides management with assurance activities make certain that the evidence to confirm the technical status of processes used to develop, install, operate, the project. and maintain software conform to contracts, comply with any imposed laws, rules, and Although any work-product can be reviewed, regulations and are adequate, efficient and technical reviews are performed on the main effective for their intended purpose [5]. software engineering work-products of software • Product assurance audits. SQA product requirements and software design. assurance activities make certain to provide Purpose, roles, activities, and most importantly evidence that software products and related the level of formality distinguish different types documentation are identified in and comply of technical reviews. Inspections are the most for- with contracts; and ensure that nonconfor- mal, walkthroughs less, and pair reviews or desk mances are identified and addressed [5]. checks are the least formal. Examples of specific roles include a decision 2.3.1. Management Reviews maker (i.e., software lead), a review leader, a recorder, and checkers (technical staff members As stated in [16*], who examine the work-products). Reviews are also distinguished by whether meetings (face to The purpose of a management review is to face or electronic) are included in the process. In monitor progress, determine the status of some review methods checkers solitarily exam- plans and schedules, and evaluate the effec- ine work-products and send their results back to tiveness of management processes, tools a coordinator. In other methods checkers work and techniques. Management reviews com- cooperatively in meetings. A technical review pare actual project results against plans to may require that mandatory inputs be in place in determine the status of projects or mainte- order to proceed: nance efforts. The main parameters of management reviews are project cost, schedule, • Statement of objectives scope, and quality. Management reviews • Specific software product evaluate decisions about corrective actions, • Specific project management plan changes in the allocation of resources, or • Issues list associated with this product changes to the scope of the project. • Technical review procedure.

Inputs to management reviews may include The team follows the documented review pro- audit reports, progress reports, V&V reports, and cedure. The technical review is completed once plans of many types, including risk management, all the activities listed in the examination have project management, software configuration been completed. management, software safety, and risk assess- Technical reviews of source code may include a ment, among others. (Refer to the Software Engi- wide variety of concerns such as analysis of algo- neering Management and the Software Configu- rithms, utilization of critical computer resources, ration Management KAs for related material.) adherence to coding standards, structure and 10-8 SWEBOK® Guide V3.0

organization of code for testability, and safety- small section of the product at a time (samples). critical considerations. Each team member examines the software prod- Note that technical reviews of source code or uct and other review inputs prior to the review design models such as UML are also termed static meeting, perhaps by applying an analytical tech- analysis (see topic 3, Practical Considerations). nique (see section 3.3.3) to a small section of the product or to the entire product with a focus 2.3.3. Inspections on only one aspect—e.g., interfaces. During the inspection, the moderator conducts the session “The purpose of an inspection is to detect and and verifies that everyone has prepared for the identify software product anomalies” [16*]. inspection and conducts the session. The inspec- Some important differentiators of inspections as tion recorder documents anomalies found. A set compared to other types of technical reviews are of rules, with criteria and questions germane to these: the issues of interest, is a common tool used in inspections. The resulting list often classifies the 1. Rules. Inspections are based upon examining anomalies (see section 3.2, Defect Characteriza- a work-product with respect to a defined set tion) and is reviewed for completeness and accu- of criteria specified by the organization. Sets racy by the team. The inspection exit decision of rules can be defined for different types of corresponds to one of the following options: workproducts (e.g., rules for requirements, architecture descriptions, source code). 1. Accept with no or, at most, minor reworking 2. Sampling. Rather that attempt to examine 2. Accept with rework verification every word and figure in a document, the 3. Reinspect. inspection process allows checkers to evaluate defined subsets (samples) of the docu- 2.3.4. Walkthroughs ments under review. 3. Peer. Individuals holding management posi- As stated in [16*], tions over members of the inspection team do not participate in the inspection. This is The purpose of a systematic walk-through a key distinction between peer review and is to evaluate a software product. A walk- management review. through may be conducted for the purpose 4. Led. An impartial moderator who is trained of educating an audience regarding a soft- in inspection techniques leads inspection ware product. meetings. 5. Meeting. The inspection process includes Walkthroughs are distinguished from inspec- meetings (face to face or electronic) con- tions. The main difference is that the author pres- ducted by a moderator according to a formal ents the work-product to the other participants in procedure in which inspection team mem- a meeting (face to face or electronic). Unlike an bers report the anomalies they have found inspection, the meeting participants may not have and other issues. necessarily seen the material prior to the meeting. The meetings may be conducted less for- Software inspections always involve the author mally. The author takes the role of explaining and of an intermediate or final product; other reviews showing the material to participants and solicits might not. Inspections also include an inspection feedback. Like inspections, walkthroughs may be leader, a recorder, a reader, and a few (two to five) conducted on any type of work-product including checkers (inspectors). The members of an inspec- project plan, requirements, design, source code, tion team may possess different expertise, such as and test reports. domain expertise, software design method expertise, or programming language expertise. Inspec- tions are usually conducted on one relatively Software Quality 10-9

2.3.5. Process Assurance and Product Assur- • the specific software engineering standards ance Audits applicable • the methods and software tools to be used for As stated in [16*], development and maintenance and for quality evaluation and improvement The purpose of a software audit is to pro- • the budget, staff, project organization, plans, vide an independent evaluation of the con- and scheduling of all processes formance of software products and pro- • the intended users and use of the system cesses to applicable regulations, standards, • the integrity level of the system. guidelines, plans, and procedures. Information on these factors influences how Process assurance audits determine the adequacy the SQM processes are organized and docu- of plans, schedules, and requirements to achieve mented, how specific SQM activities are selected, project objectives [5]. The audit is a formally what resources are needed, and which of those organized activity with participants having spe- resources impose bounds on the efforts. cific roles—such as lead auditor, another auditor, a recorder, or an initiator—and including a represen- 3.1.2. Dependability tative of the audited organization. Audits identify instances of nonconformance and produce a report In cases where system failure may have extremely requiring the team to take corrective action. severe consequences, overall dependability (hard- While there may be many formal names for ware, software, and human or operational) is the reviews and audits, such as those identified in the main quality requirement over and above basic standard [16*], the important point is that they functionality. This is the case for the following can occur on almost any product at any stage of reasons: system failures affect a large number of the development or maintenance process. people; users often reject systems that are unreliable, unsafe, or insecure; system failure costs 3. Practical Considerations may be enormous; and undependable systems may cause information loss. System and soft- 3.1. Software Quality Requirements ware dependability include such characteristics [9*, c11s1] [18*, c12] as availability, reliability, safety, and security. [17*, c15s3.2.2, c15s3.3.1, c16s9.10] When developing dependable software, tools and techniques can be applied to reduce the risk of 3.1.1. Influence Factors injecting faults into the intermediate deliverables or the final software product. Verification, valida- Various factors influence planning, management, tion, and testing processes, techniques, methods, and selection of SQM activities and techniques, and tools identify faults that impact dependability including as early as possible in the life cycle. Addition- ally, mechanisms may need to be in place in the • the domain of the system in which the soft- software to guard against external attacks and to ware resides; the system functions could be tolerate faults. safety-critical, mission-critical, business- critical, security-critical 3.1.3. Integrity Levels of Software • the physical environment in which the software system resides Defining integrity levels is a method of risk • system and software functional (what the management. system does) and quality (how well the system performs its functions) requirements Software integrity levels are a range of • the commercial (external) or standard (inter- values that represent software complexity, nal) components to be used in the system criticality, risk, safety level, security level, 10-10 SWEBOK® Guide V3.0

desired performance, reliability, or other Specific types of problems need to be grouped to project-unique characteristics that define identify trends over time. The point is to establish the importance of the software to the user a defect taxonomy that is meaningful to the orga- and acquirer. The characteristics used to nization and to software engineers. determine software integrity level vary Software quality control activities discover infor- depending on the intended application and mation at all stages of software development and use of the system. The software is a part of maintenance. In some cases, the word defect is the system, and its integrity level is to be overloaded to refer to different types of anomalies. determined as a part of that system. However, different engineering cultures and standards may use somewhat different meanings for The assigned software integrity levels may these terms. The variety of terms prompts this sec- change as the software evolves. Design, coding, tion to provide a widely used set of definitions [19]: procedural, and technology features implemented in the system or software can raise or lower the • Computational Error: “the difference assigned software integrity levels. The software between a computed, observed, or measured integrity levels established for a project result value or condition and the true, specified, or from agreements among the acquirer, supplier, theoretically correct value or condition.” developer, and independent assurance authorities. • Error: “A human action that produces an A software integrity level scheme is a tool used in incorrect result.” A slip or mistake that a per- determining software integrity levels. [5] son makes. Also called human error. As noted in [17*], “the integrity levels can be • Defect: An “imperfection or deficiency in a applied during development to allocate additional work product where that work product does verification and validation efforts to high-integ- not meet its requirements or specifications rity components.” and needs to be either repaired or replaced.” A defect is caused by a person committing 3.2. Defect Characterization an error. [3*, c3s3, c8s8, c10s2] • Fault: A defect in source code. An “incorrect step, process, or data definition in computer Software quality evaluation (i.e., software quality program.” The encoding of a human error in control) techniques find defects, faults and fail- source code. Fault is the formal name of a bug. ures. Characterizing these techniques leads to an • Failure: An “event in which a system or sys- understanding of the product, facilitates correc- tem component does not perform a required tions to the process or the product, and informs function within specified limits.” A failure is management and other stakeholders of the sta- produced when a fault is encountered by the tus of the process or product. Many taxonomies processor under specified conditions. exist and, while attempts have been made to gain consensus, the literature indicates that there are Using these definitions three widely used soft- quite a few in use. Defect characterization is also ware quality measurements are defect density used in audits and reviews, with the review leader (number of defects per unit size of documents), often presenting a list of issues provided by team fault density (number of faults per 1K lines of members for consideration at a review meeting. code), and failure intensity (failures per use-hour As new design methods and languages evolve, or per test-hour). Reliability models are built along with advances in overall software technolo- from failure data collected during software test- gies, new classes of defects appear, and a great ing or from software in service and thus can be deal of effort is required to interpret previously used to estimate the probability of future failures defined classes. When tracking defects, the soft- and to assist in decisions on when to stop testing. ware engineer is interested in not only the number One probable action resulting from SQM find- of defects but also the types. Information alone, ings is to remove the defects from the product without some classification, may not be sufficient under examination (e.g., find and fix bugs, create to identify the underlying causes of the defects. new build). Other activities attempt to eliminate Software Quality 10-11

the causes of the defects—for example, root cause also Formal Methods in the Software Engineer- analysis (RCA). RCA activities include analyzing ing Models and Methods KA.) and summarizing the findings to find root causes and using measurement techniques to improve 3.3.2. Dynamic Techniques the product and the process as well as to track the defects and their removal. Process improvement Dynamic techniques involve executing the soft- is primarily discussed in the Software Engineer- ware code. Different kinds of dynamic techniques ing Process KA, with the SQM process being a are performed throughout the development and source of information. maintenance of software. Generally, these are Data on inadequacies and defects found by testing techniques, but techniques such as simu- software quality control techniques may be lost lation and model analysis may be considered unless they are recorded. For some techniques dynamic (see the Software Engineering Models (e.g., technical reviews, audits, inspections), and Methods KA). Code reading is considered a recorders are present to set down such informa- static technique, but experienced software engi- tion, along with issues and decisions. When auto- neers may execute the code as they read through mated tools are used (see topic 4, Software Qual- it. Code reading may utilize dynamic techniques. ity Tools), the tool output may provide the defect This discrepancy in categorizing indicates that information. Reports about defects are provided people with different roles and experience in the to the management of the organization. organization may consider and apply these techniques differently. 3.3. Software Quality Management Techniques Different groups may perform testing during [7*, c7s3] [8*, c17] [9*, c12s5, c15s1, p417] software development, including groups inde- [16*] pendent of the development team. The Software Testing KA is devoted entirely to this subject. Software quality control techniques can be categorized in many ways, but a straightforward 3.3.3. Testing approach uses just two categories: static and dynamic. Dynamic techniques involve executing Two types of testing may fall under V&V because the software; static techniques involve analyzing of their responsibility for the quality of the mate- documents and source code but not executing the rials used in the project: software. • Evaluation and tests of tools to be used on 3.3.1. Static Techniques the project • Conformance tests (or review of confor- Static techniques examine software documenta- mance tests) of components and COTS prod- tion (including requirements, interface specifica- ucts to be used in the product. tions, designs, and models) and software source code without executing the code. There are many Sometimes an independent (third-party or tools and techniques for statically examining soft- IV&V) organization may be tasked to perform ware work-products (see section 2.3.2). In addi- testing or to monitor the test process V&V may tion, tools that analyze source code control flow be called upon to evaluate the testing itself: ade- and search for dead code are considered to be quacy of plans, processes, and procedures, and static analysis tools because they do not involve adequacy and accuracy of results. executing the software code. The third party is not the developer, nor is it Other, more formal, types of analytical tech- associated with the development of the product. niques are known as formal methods. They are Instead, the third party is an independent facil- notably used to verify software requirements and ity, usually accredited by some body of authority. designs. They have mostly been used in the veri- Their purpose is to test a product for conformance fication of crucial parts of critical systems, such to a specific set of requirements (see the Software as specific security and safety requirements. (See Testing KA). 10-12 SWEBOK® Guide V3.0

3.4. Software Quality Measurement troublesome areas of the software product under [3*, c4] [8*, c17] [9*, p90] examination. The resulting charts and graphs are visualization aids, which the decision mak- Software quality measurements are used to ers can use to focus resources and conduct pro- support decision-making. With the increasing cess improvements where they appear to be most sophistication of software, questions of quality needed. Results from trend analysis may indicate go beyond whether or not the software works to that a schedule is being met, such as in testing, or how well it achieves measurable quality goals. that certain classes of faults may become more Decisions supported by software quality mea- likely to occur unless some corrective action is surement include determining levels of software taken in development. The predictive techniques quality (notably because models of software assist in estimating testing effort and schedule product quality include measures to determine and in predicting failures. More discussion on the degree to which the software product achieves measurement in general appears in the Software quality goals); managerial questions about effort, Engineering Process and Software Engineering cost, and schedule; determining when to stop test- Management KAs. More specific information on ing and release a product (see Termination under testing measurement is presented in the Software section 5.1, Practical Considerations, in the Soft- Testing KA. ware Testing KA); and determining the efficacy Software quality measurement includes mea- of process improvement efforts. suring defect occurrences and applying statistical The cost of SQM processes is an issue fre- methods to understand the types of defects that quently raised in deciding how a project or a soft- occur most frequently. This information may be ware development and maintenance group should used by software process improvement for deter- be organized. Often, generic models of cost are mining methods to prevent, reduce, or eliminate used, which are based on when a defect is found their recurrence. They also aid in understanding and how much effort it takes to fix the defect rela- trends, how well detection and containment tech- tive to finding the defect earlier in the develop- niques are working, and how well the development process. Software quality measurement data ment and maintenance processes are progressing. collected internally may give a better picture of From these measurement methods, defect cost within this project or organization. profiles can be developed for a specific applica- While the software quality measurement data tion domain. Then, for the next software project may be useful in itself (e.g., the number of defec- within that organization, the profiles can be used tive requirements or the proportion of defective to guide the SQM processes—that is, to expend requirements), mathematical and graphical tech- the effort where problems are most likely to occur. niques can be applied to aid in the interpretation Similarly, benchmarks, or defect counts typical of of the measures (see the Engineering Foundations that domain, may serve as one aid in determining KA). These techniques include when the product is ready for delivery. Discus- sion on using data from SQM to improve devel- • descriptive statistics based (e.g., Pareto opment and maintenance processes appears in the analysis, run charts, scatter plots, normal Software Engineering Management and Software distribution) Engineering Process KAs. • statistical tests (e.g., the binomial test, chi- squared test) 4. Software Quality Tools • trend analysis (e.g., control charts; see The Quality Toolbox in the list of further Software quality tools include static and dynamic readings) analysis tools. Static analysis tools input source • prediction (e.g., reliability models). code, perform syntactical and semantic analysis without executing the code, and present results to Descriptive statistics-based techniques and users. There is a large variety in the depth, thor- tests often provide a snapshot of the more oughness, and scope of static analysis tools that Software Quality 10-13

can be applied to artifacts including models, in • Tools that support tracking of software prob- addition to source code. (See the Software Con- lems provide for entry of anomalies discov- struction, Software Testing, and Software Main- ered during software testing and subsequent tenance KAs for descriptions of dynamic analysis analysis, disposition, and resolution. Some tools.) tools include support for workflow and for Categories of static analysis tools include the tracking the status of problem resolution. following: • Tools that analyze data captured from software engineering environments and soft- • Tools that facilitate and partially automate ware test environments and produce visual reviews and inspections of documents and displays of quantified data in the form of code. These tools can route work to differ- graphs, charts, and tables. These tools some- ent participants in order to partially automate times include the functionality to perform and control a review process. They allow statistical analysis on data sets (for the pur- users to enter defects found during inspec- pose of discerning trends and making fore- tions and reviews for later removal. casts). Some of these tools provide defect • Some tools help organizations perform soft- and removal injection rates; defect densities; ware safety hazard analysis. These tools yields; distribution of defect injection and provide, e.g., automated support for failure removal for each of the life cycle phases. mode and effects analysis (FMEA) and fault tree analysis (FTA). 10-14 SWEBOK® Guide V3.0

MATRIX OF TOPICS VS. REFERENCE MATERIAL [6*] [3*] [7*] [9*] [8*] [16*] [17*] [18*] [10*] Kan 2002 Galin 2004 Moore 2006Moore Voland 2003 Voland Wiegers 2003 Bott et al. 2000 Sommerville 2011 IEEE Std. 1028-2008 Naik and Tripathy 2008Naik and Tripathy

1. Software Quality Fundamentals 1.1. Software Engineering c1s4 c2s3.5 Culture and Ethics 1.2. Value and c17, Cost of Quality c22 1.3. Models and Quality c24s1 c2s4 c17 Characteristics 1.4. Software c11 Quality c1s4 c24 s2.4 Improvement 1.5. Software c11s3 Safety 2. Software Quality Management Processes 2.1. Software c4–c6, Quality c11, Assurance c26–27 c2 s2.3, 2.2. Verification c8, c15 and Validation s1.1, c21 s3.3 2.3. Reviews c24s3 * and Audits Software Quality 10-15 [6*] [3*] [7*] [9*] [8*] [16*] [17*] [18*] [10*] Kan 2002 Galin 2004 Moore 2006Moore Voland 2003 Voland Wiegers 2003 Bott et al. 2000 Sommerville 2011 IEEE Std. 1028-2008 Naik and Tripathy 2008Naik and Tripathy

3. Software Quality Practical Considerations c15 s3.2.2, 3.1. Software c15 Quality c11s1 c12 s3.3.1, Requirements c16 s9.10 c3s3, 3.2. Defect c8s8, Characterization c10s2 c12s5, 3.3. SQM c7s3 c17 c15s1, * Techniques p417 3.4. Software Quality c4 c17 p90 Measurement 4. Software Quality Tools 10-16 SWEBOK® Guide V3.0

FURTHER READINGS N. Leveson, Safeware: System Safety and K.E. Wiegers, Peer Reviews in Software: A Computers [20]. Practical Guide [23].

This book describes the importance of software This book provides clear, succinct explanations safety practices and how these practices can be of different peer review methods distinguished by incorporated into software development projects. level of formality and effectiveness. Pragmatic guidance for implementing the methods and how T. Gilb, Principles of Software Engineering to select which methods are appropriate for given Management [21]. circumstances is provided.

This is one of the first books on iterative and N.R. Tague, The Quality Toolbox, 2nd ed., [24]. incremental development techniques. The Evo Method defines quantified goals, frequent time- Provides a pragmatic how-to explanation of a boxed iterations, measurements of progress comprehensive set of methods, tools, and tech- toward goals, and adaptation of plans based on niques for solving quality improvement prob- actual results. lems. Includes the seven basic quality control tools and many others. T. Gilb and D. Graham, Software Inspection [22]. IEEE Std. P730-2013 Draft Standard for Software Quality Assurance Processes [5]. This book introduces measurement and statistical sampling for reviews and defects. It presents This draft standard expands the SQA processes techniques that produce quantified results for identified in IEEE/ISO/IEC 12207-2008. P730 reducing defects, improving productivity, track- establishes standards for initiating, planning, ing projects, and creating documentation. controlling, and executing the software quality assurance processes of a software development or maintenance project. Approval of this draft standard is expected in 2014. Software Quality 10-17

REFERENCES [1] P.B. Crosby, Quality Is Free, McGraw-Hill, [13] IEEE Std. 12207-2008 (a.k.a. ISO/IEC 1979. 12207:2008) Standard for Systems and Software Engineering—Software Life Cycle [2] W. Humphrey, Managing the Software Processes, IEEE, 2008. Process, Addison-Wesley, 1989. [14] ISO 9000:2005 Quality Management [3*] S.H. Kan, Metrics and Models in Software Systems—Fundamentals and Vocabulary, Quality Engineering, 2nd ed., Addison- ISO, 2005. Wesley, 2002. [15] IEEE Std. 1012-2012 Standard for System [4] ISO/IEC 25010:2011 Systems and Software and Software Verification and Validation, Engineering—Systems and Software IEEE, 2012. Quality Requirements and Evaluation (SQuaRE)—Systems and Software Quality [16*] IEEE Std. 1028-2008, Software Reviews Models, ISO/IEC, 2011. and Audits, IEEE, 2008.

[5] IEEE P730™/D8 Draft Standard for [17*] J.W. Moore, The Road Map to Software Software Quality Assurance Processes, Engineering: A Standards-Based Guide, IEEE, 2012. Wiley-IEEE Computer Society Press, 2006.

[6*] F. Bott et al., Professional Issues in [18*] K.E. Wiegers, Software Requirements, 2nd Software Engineering, 3rd ed., Taylor & ed., Microsoft Press, 2003. Francis, 2000. [19] ISO/IEC/IEEE 24765:2010 Systems and [7*] D. Galin, Software Quality Assurance: Software Engineering—Vocabulary, ISO/ From Theory to Implementation, Pearson IEC/IEEE, 2010. Education Limited, 2004. [20] N. Leveson, Safeware: System Safety and [8*] S. Naik and P. Tripathy, Software Testing Computers, Addison-Wesley Professional, and Quality Assurance: Theory and 1995. Practice, Wiley-Spektrum, 2008. [21] T. Gilb, Principles of Software Engineering [9*] P. Clements et al., Documenting Software Management, Addison-Wesley Professional, Architectures: Views and Beyond, 2nd ed., 1988. Pearson Education, 2010. [22] T. Gilb and D. Graham, Software [10*] G. Voland, Engineering by Design, 2nd Inspection, Addison-Wesley Professional, ed., Prentice Hall, 2003. 1993.

[11] RTCA DO-178C, Software Considerations [23] K. Wiegers, Peer Reviews in Software: A in Airborne Systems and Equipment Practical Guide, Addison-Wesley Certification, Radio Technical Commission Professional, 2001. for Aeronautics, 2011. [24] N.R. Tague, The Quality Toolbox, 2nd ed., [12] IEEE Std. 15026.1-2011 Trial-Use Standard ASQ Quality Press, 2010. Adoption of ISO/IEC TR 15026-1:2010 Systems and Software Engineering— Systems and Software Assurance—Part 1: Concepts and Vocabulary, IEEE, 2011. CHAPTER 11

SOFTWARE ENGINEERING PROFESSIONAL PRACTICE

ACRONYMS software with known characteristics and reliability. This requirement calls for software engineers Association for Computing ACM who possess a proper set of knowledge, skills, Machinery training, and experience in professional practice. BCS British Computer Society The term “professional practice” refers to a Certified Software Development way of conducting services so as to achieve cer- CSDA Associate tain standards or criteria in both the process of Certified Software Development performing a service and the end product result- CSDP Professional ing from the service. These standards and criteria can include both technical and nontechnical International Electrotechnical IEC aspects. The concept of professional practice can Commission be viewed as being more applicable within those IEEE CS IEEE Computer Society professions that have a generally accepted body International. Federation for of knowledge; codes of ethics and professional IFIP Information Processing conduct with penalties for violations; accepted IP Intellectual Property processes for accreditation, certification, and licensing; and professional societies to provide International Organization for ISO and administer all of these. Admission to these Standardization professional societies is often predicated on a pre- NDA Non-Disclosure Agreement scribed combination of education and experience. World Intellectual Property A software engineer maintains a professional WIPO Organization practice by performing all work in accordance WTO World Trade Organization with generally accepted practices, standards, and guidelines notably set forth by the applicable professional society. For example, the Association for INTRODUCTION Computing Machinery (ACM) and IEEE Com- puter Society (IEEE CS) have established a Soft- The Software Engineering Professional Prac- ware Engineering Code of Ethics and Professional tice knowledge area (KA) is concerned with the Practice. Both the British Computer Society (BCS) knowledge, skills, and attitudes that software and the International Federation for Information engineers must possess to practice software engi- Processing (IFIP) have established similar profes- neering in a professional, responsible, and ethi- sional practice standards. ISO/IEC and IEEE have cal manner. Because of the widespread applica- further provided internationally accepted software tions of software products in social and personal engineering standards (see Appendix B of this life, the quality of software products can have Guide). IEEE CS has established two international profound impact on our personal well-being certification programs (CSDA, CSDP) and a corre- and societal harmony. Software engineers must sponding Guide to the Software Engineering Body handle unique engineering problems, producing of Knowledge (SWEBOK Guide). All of these are

11-1 11-2 SWEBOK® Guide V3.0

Figure 11.1. Breakdown of Topics for the Software Engineering Professional Practice KA elements that lay the foundation for of the profes- 11.1. The subareas presented in this KA are pro- sional practice of software engineering. fessionalism, group dynamics and psychology, and communication skills. BREAKDOWN OF TOPICS FOR SOFTWARE ENGINEERING 1. Professionalism PROFESSIONAL PRACTICE A software engineer displays professionalism The Software Engineering Professional Practice notably through adherence to codes of ethics KA’s breakdown of topics is shown in Figure and professional conduct and to standards and Software Engineering Professional Practice 11-3

practices that are established by the engineer’s of certification is professional certification, where professional community. a person is certified as being able to complete an The professional community is often repre- activity in a certain discipline at a stated level sented by one or more professional societies; of competency. Professional certification also those societies publish codes of ethics and profes- can also verify the holder’s ability to meet pro- sional conduct as well as criteria for admittance fessional standards and to apply professional to the community. Those criteria form the basis judgment in solving or addressing problems. for accreditation and licensing activities and may Professional certification can also involve the be used as a measure to determine engineering verification of prescribed knowledge, the master- competence or negligence. ing of best practice and proven methodologies, and the amount of professional experience. 1.1. Accreditation, Certification, and Licensing An engineer usually obtains certification by [1*, c1s4.1, c1s5.1–c1s5.4] passing an examination in conjunction with other experience-based criteria. These examinations 1.1.1. Accreditation are often administered by nongovernmental organizations, such as professional societies. Accreditation is a process to certify the compe- In software engineering, certification testi- tency, authority, or credibility of an organization. fies to one’s qualification as a software engineer. Accredited schools or programs are assured to For example, the IEEE CS has enacted two cer- adhere to particular standards and maintain certification programs (CSDA and CSDP) designed tain qualities. In many countries, the basic means to confirm a software engineer’s knowledge of by which engineers acquire knowledge is through standard software engineering practices and to completion of an accredited course of study. advance one’s career. A lack of certification does Often, engineering accreditation is performed by not exclude the individual from working as a a government organization, such as the ministry software engineer. Currently certification in soft- of education. Such countries with government ware engineering is completely voluntary. In fact, accreditations include China, France, Germany, most software engineers are not certified under Israel, Italy, and Russia. any program. In other countries, however, the accreditation process is independent of government and 1.1.3. Licensing performed by private membership associations. For example, in the United States, engineer- “Licensing” is the action of giving a person the ing accreditation is performed by an organiza- authorization to perform certain kinds of activi- tion known as ABET. An organization known as ties and take responsibility for resultant engineer- CSAB serving as a participating body of ABET ing products. The noun “license” refers to both is the lead society within ABET for the accredita- that authorization and the document recording tion of degree programs in software engineering. that authorization. Governmental authorities or While the process of accreditation may be dif- statutory bodies usually issue licenses. ferent for each country and jurisdiction, the general Obtaining a license to practice requires not only meaning is the same. For an institution’s course of that an individual meets a certain standard, but study to be accredited means that “the accredita- also that they do so with a certain ability to prac- tion body recognizes an educational institution as tice or operate. Sometimes there is an entry-level maintaining standards that qualify the graduates requirement which sets the minimum skills and for admission to higher or more specialized insti- capabilities to practice, but as the professional tutions or for professional practice” [2]. moves through his or her career, the required skills and capabilities change and evolve. 1.1.2. Certification In general, engineers are licensed as a means of protecting the public from unqualified individuals. Certification refers to the confirmation of a per- In some countries, no one can practice as a pro- son’s particular characteristics. A common type fessional engineer unless licensed; or further, no 11-4 SWEBOK® Guide V3.0

company may offer “engineering services” unless Since standards and codes of ethics and pro- at least one licensed engineer is employed there. fessional conduct may be introduced, modified, or replaced at any time, individual software engi- 1.2. Codes of Ethics and Professional Conduct neers bear the responsibility for their own con- [1*, c1s6–c1s9] [3*, c8] [4*, c1s2] [5*, c33] tinuing study to stay current in their professional [6*] practice.

Codes of ethics and professional conduct com- 1.3. Nature and Role of Professional Societies prise the values and behavior that an engineer’s [1*, c1s1–c1s2] [4*, c1s2] [5*, c35s1] professional practice and decisions should embody. Professional societies are comprised of a mix The professional community establishes codes of practitioners and academics. These societies of ethics and professional conduct. They exist serve to define, advance, and regulate their cor- in the context of, and are adjusted to agree with, responding professions. Professional societies societal norms and local laws. Therefore, codes help to establish professional standards as well of ethics and professional conduct present guid- as codes of ethics and professional conduct. For ance in the face of conflicting imperatives. this reason, they also engage in related activities, Once established, codes of ethics and profes- which include sional conduct are enforced by the profession, as represented by professional societies or by a • establishing and promulgating a body of gen- statutory body. erally accepted knowledge; Violations may be acts of commission, such • accrediting, certifying, and licensing; as concealing inadequate work, disclosing con- • dispensing disciplinary actions; fidential information, falsifying information, or • advancing the profession through confer- misrepresenting one’s abilities. They may also ences, training, and publications. occur through omission, including failure to dis- close risks or to provide important information, Participation in professional societies assists failure to give proper credit or to acknowledge the individual engineer in maintaining and sharp- references, and failure to represent client inter- ening their professional knowledge and relevancy ests. Violations of codes of ethics and profes- and in expanding and maintaining their professional conduct may result in penalties and pos- sional network. sible expulsion from professional status. A code of ethics and professional conduct for 1.4. Nature and Role of Software Engineering software engineering was approved by the ACM Standards Council and the IEEE CS Board of Governors in [1*, c5s3.2, c10s2.1] [5*, c32s6] [7*, c1s2] 1999 [6*]. According to the short version of this code: Software engineering standards cover a remark- able variety of topics. They provide guidelines for Software engineers shall commit them- the practice of software engineering and processes selves to making the analysis, specifica- to be used during development, maintenance, and tion, design, development, testing and support of software. By establishing a consensual maintenance of software a beneficial and body of knowledge and experience, software engi- respected profession. In accordance with neering standards establish a basis upon which fur- their commitment to the health, safety and ther guidelines may be developed. Appendix B of welfare of the public, software engineers this Guide provides guidance on IEEE and ISO/ shall adhere to the eight principles con- IEC software engineering standards that support cerning the public, client and employer, the knowledge areas of this Guide. product, judgment, management, profes- The benefits of software engineering standards sion, colleagues, and self, respectively. are many and include improving software quality, Software Engineering Professional Practice 11-5

helping avoid errors, protecting both software consideration. Here, we are most concerned with producers and users, increasing professional dis- the engineer-to-customer arrangement and its cipline, and helping technology transition. attendant agreements or contracts, whether they are of the direct-hire or consultant variety, and 1.5. Economic Impact of Software the issues they typically address. [3*, c10s8] [4*, c1s1.1] [8*, c1] A common concern in software engineering contracts is confidentiality. Employers derive Software has economic effects at the individual, commercial advantage from intellectual property, business, and societal levels. Software “success” so they strive to protect that property from dis- may be determined by the suitability of a product closure. Therefore, software engineers are often for a recognized problem as well as by its effec- required to sign non-disclosure (NDA) or intel- tiveness when applied to that problem. lectual property (IP) agreements as a precondi- At the individual level, an engineer’s continu- tion to work. These agreements typically apply ing employment may depend on their ability to information the software engineer could only and willingness to interpret and execute tasks gain through association with the customer. The in meeting customers’ or employers’ needs and terms of these agreements may extend past termi- expectations. The customer or employer’s finan- nation of the association. cial situation may in turn be positively or nega- Another concern is IP ownership. Rights to tively affected by the purchase of software. software engineering assets—products, innova- At the business level, software properly applied tions, inventions, discoveries, and ideas—may to a problem can eliminate months of work reside with the employer or customer, either under and translate to elevated profits or more effec- explicit contract terms or relevant laws, if those tive organizations. Moreover, organizations that assets are obtained during the term of the soft- acquire or provide successful software may be a ware engineer’s relationship with that employer boon to the society in which they operate by pro- or customer. Contracts differ in the ownership of viding both employment and improved services. assets created using non-employer-owned equip- However, the development or acquisition costs of ment or information. software can also equate to those of any major Finally, contracts can also specify among acquisition. other elements the location at which work is to At the societal level, direct impacts of software be performed; standards to which that work will success or failure include or exclude accidents, be held; the system configuration to be used for interruptions, and loss of service. Indirect impacts development; limitations of the software engi- include the success or failure of the organization neer’s and employer’s liability; a communication that acquired or produced the software, increased matrix and/or escalation plan; and administrative or decreased societal productivity, harmonious details such as rates, frequency of compensation, or disruptive social order, and even the saving or working hours, and working conditions. loss of property and life. 1.7. Legal Issues 1.6. Employment Contracts [1*, c6, c11] [3*, c5s3–c5s4] [9*, c1s10] [1*, c7] Legal issues surrounding software engineering Software engineering services may be provided professional practice notably include matters under a variety of client-engineer relationships. related to standards, trademarks, patents, copy- The software engineering work may be solic- rights, trade secrets, professional liability, legal ited as company-to-customer supplier, engineer- requirements, trade compliance, and cybercrime. to-customer consultancy, direct hire, or even It is therefore beneficial to possess knowledge of volunteering. In all of these situations, the cus- these issues and their applicability. tomer and supplier agree that a product or ser- Legal issues are jurisdictionally based; soft- vice will be provided in return for some sort of ware engineers must consult attorneys who 11-6 SWEBOK® Guide V3.0

specialize in the type and jurisdiction of any iden- are an old form of idea-ownership protection and tified legal issues. date back to the 15th century. Application for a patent entails careful records 1.7.1. Standards of the process that led to the invention. Patent attorneys are helpful in writing patent disclosure Software engineering standards establish guide- claims in a manner most likely to protect the soft- lines for generally accepted practices and mini- ware engineer’s rights. mum requirements for products and services pro- Note that, if inventions are made during the vided by a software engineer. Appendix B of this course of a software engineering contract, owner- Guide provides guidance on software engineer- ship may belong to the employer or customer or ing standards that are applicable to each KA. be jointly held, rather than belong to the software Standards are valuable sources of requirements engineer. and assistance during the everyday conduct of There are rules concerning what is and is not software engineering activities. Adherence to patentable. In many countries, software code is standards facilitates discipline by enumerating not patentable, although software algorithms may minimal characteristics of products and practice. be. Existing and filed patent applications can be That discipline helps to mitigate subconscious searched at WIPO. assumptions or overconfidence in a design. For these reasons, organizations performing software 1.7.4. Copyrights engineering activities often include conformance to standards as part of their organizational poli- Most governments in the world give exclusive cies. Further, adherence to standards is a major rights of an original work to its creator, usually component of defense from legal action or from for a limited time, enacted as a copyright. Copy- allegations of malpractice. rights protect the way an idea is presented—not the idea itself. For example, they may protect the 1.7.2. Trademarks particular wording of an account of an historical event, whereas the event itself is not protected. A trademark relates to any word, name, symbol, Copyrights are long-term and renewable; they or device that is used in business transactions. date back to the 17th century. It is used “to indicate the source or origin of the goods” [2]. 1.7.5. Trade Secrets Trademark protection protects names, logos, images, and packaging. However, if a name, image, In many countries, an intellectual asset such as or other trademarked asset becomes a generic term, a formula, algorithm, process, design, method, then trademark protection is nullified. pattern, instrument, or compilation of informa- The World Intellectual Property Organization tion may be considered a “trade secret,” provided (WIPO) is the authority that frames the rules and that these assets are not generally known and may regulations on trademarks. WIPO is the United provide a business some economic advantage. Nations agency dedicated to the use of intellec- The designation of “trade secret” provides legal tual property as a means of stimulating innova- protection if the asset is stolen. This protection tion and creativity. is not subject to a time limit. However, if another party derives or discovers the same asset legally, 1.7.3. Patents then the asset is no longer protected and the other party will also possess all rights to use it. Patents protect an inventor’s right to manufacture and sell an idea. A patent consists of a set 1.7.6. Professional Liability of exclusive rights granted by a sovereign government to an individual, group of individuals, or It is common for software engineers to be con- organization for a limited period of time. Patents cerned with matters of professional liability. As Software Engineering Professional Practice 11-7

an individual provides services to a client or 1.7.8. Trade Compliance employer, it is vital to adhere to standards and generally accepted practices, thereby protecting All software professionals must be aware of against allegations or proceedings of or related to legal restrictions on import, export, or reexport malpractice, negligence, or incompetence. of goods, services, and technology in the juris- For engineers, including software engineers, dictions in which they work. The considerations professional liability is related to product liabil- include export controls and classification, transfer ity. Under the laws and rules governing in their of goods, acquisition of necessary governmental jurisdiction, engineers may be held to account licenses for foreign use of hardware and software, for failing to fully and conscientiously follow services and technology by sanctioned nation, recommended practice; this is known as “negli- enterprise or individual entities, and import gence.” They may also be subject to laws govern- restrictions and duties. Trade experts should be ing “strict liability” and either implied or express consulted for detailed compliance guidance. warranty, where, by selling the product, the engineer is held to warrant that the product is both 1.7.9. Cybercrime suitable and safe for use. In some countries (for example, in the US), “privity” (the idea that one Cybercrime refers to any crime that involves could only sue the person selling the product) is a computer, computer software, computer net- no longer a defense against liability actions. works, or embedded software controlling a sys- Legal suits for liability can be brought under tem. The computer or software may have been tort law in the US allowing anyone who is harmed used in the commission of a crime or it may have to recover their loss even if no guarantees were been the target. This category of crime includes made. Because it is difficult to measure the suit- fraud, unauthorized access, spam, obscene or ability or safety of software, failure to take due offensive content, threats, harassment, theft of care can be used to prove negligence on the part sensitive personal data or trade secrets, and use of software engineers. A defense against such an of one computer to damage or infiltrate other allegation is to show that standards and generally networked computers and automated system accepted practices were followed in the develop- controls. ment of the product. Computer and software users commit fraud by altering electronic data to facilitate illegal activ- 1.7.7. Legal Requirements ity. Forms of unauthorized access include hack- ing, eavesdropping, and using computer systems Software engineers must operate within the con- in a way that is concealed from their owners. fines of local, national, and international legal Many countries have separate laws to cover frameworks. Therefore, software engineers must cybercrimes, but it has sometimes been difficult be aware of legal requirements for to prosecute cybercrimes due to a lack of precisely framed statutes. The software engineer has • registration and licensing—including exami- a professional obligation to consider the threat of nation, education, experience, and training cybercrime and to understand how the software requirements; system will protect or endanger software and user • contractual agreements; information from accidental or malicious access, • noncontractual legalities, such as those gov- use, modification, destruction, or disclosure. erning liability; • Basic information on the international legal 1.8. Documentation framework can be accessed from the World [1*, c10s5.8] [3*, c1s5] [5*, c32] Trade Organization (WTO). Providing clear, thorough, and accurate documentation is the responsibility of each software engineer. The adequacy of documentation is 11-8 SWEBOK® Guide V3.0

judged by different criteria based on the needs of of the software source code or the right to modify the various stakeholder audiences. the code, the software engineer should provide Good documentation complies with accepted documentation of the functional specifications, standards and guidelines. In particular, software the software design, the test suite, and the neces- engineers should document sary operating environment for the software. The minimum length of time documents should • relevant facts, be kept is the duration of the software products’ • significant risks and tradeoffs, and life cycle or the time required by relevant organi- • warnings of undesirable or dangerous conse- zational or regulatory requirements. quences from use or misuse of the software. 1.9. Tradeoff Analysis Software engineers should avoid [3*, c1s2, c10] [9*, c9s5.10]

• certifying or approving unacceptable products, Within the practice of software engineering, a • disclosing confidential information, or software engineer often has to choose between • falsifying facts or data. alternative problem solutions. The outcome of these choices is determined by the software engi- In addition, software engineers and their man- neer’s professional evaluation of the risks, costs, agers should notably provide the following docu- and benefits of alternatives, in cooperation with mentation for use by other elements of the soft- stakeholders. The software engineer’s evaluation ware development organization: is called “tradeoff analysis.” Tradeoff analysis notably enables the identification of compet- • software requirements specifications, soft- ing and complementary software requirements ware design documents, details on the soft- in order to prioritize the final set of require- ware engineering tools used, software test ments defining the software to be constructed specifications and results, and details on the (see Requirements Negotiation in the Software adopted software engineering methods; Requirements KA and Determination and Nego- • problems encountered during the develop- tiation of Requirements in the Software Engi- ment process. neering Management KA). In the case of an ongoing software develop- For external stakeholders (customer, users, ment project that is late or over budget, tradeoff others) software documentation should notably analysis is often conducted to decide which soft- provide ware requirements can be relaxed or dropped given the effects thereof. • information needed to determine if the soft- A first step in a tradeoff analysis is establish- ware is likely to meet the customer’s and ing design goals (see Engineering Design in the users’ needs, Engineering Foundations KA) and setting the • description of the safe, and unsafe, use of the relative importance of those goals. This permits software, identification of the solution that most nearly • description of the protection of sensitive meets those goals; this means that the way the information created by or stored using the goals are stated is critically important. software, and Design goals may include minimization of • clear identification of warnings and critical monetary cost and maximization of reliability, procedures. performance, or some other criteria on a wide range of dimensions. However, it is difficult to Use of software may include installation, oper- formulate a tradeoff analysis of cost against risk, ation, administration, and performance of other especially where primary production and second- functions by various groups of users and support ary risk-based costs must be traded against each personnel. If the customer will acquire ownership other. Software Engineering Professional Practice 11-9

A software engineer must conduct a tradeoff One point to emphasize is that software engi- analysis in an ethical manner—notably by being neers must be able to work in multidisciplinary objective and impartial when selecting criteria for environments and in varied application domains. comparison of alternative problem solutions and Since today software is everywhere, from a phone when assigning weights or importance to these to a car, software is impacting people’s lives far criteria. Any conflict of interest must be disclosed beyond the more traditional concept of software up front. made for information management in a business environment. 2. Group Dynamics and Psychology 2.2. Individual Cognition Engineering work is very often conducted in the [3*, c1s6.5] [5*, c33] context of teamwork. A software engineer must be able to interact cooperatively and construc- Engineers desire to solve problems. The ability to tively with others to first determine and then solve problems effectively and efficiently is what meet both needs and expectations. Knowledge of every engineer strives for. However, the limits group dynamics and psychology is an asset when and processes of individual cognition affect prob- interacting with customers, coworkers, suppliers, lem solving. In software engineering, notably due and subordinates to solve software engineering to the highly abstract nature of software itself, problems. individual cognition plays a very prominent role in problem solving. 2.1. Dynamics of Working in Teams/Groups In general, an individual’s (in particular, a software [3*, c1s6] [9*, c1s3.5, c10] engineer’s) ability to decompose a problem and cre- atively develop a solution can be inhibited by Software engineers must work with others. On one hand, they work internally in engineering • need for more knowledge, teams; on the other hand, they work with cus- • subconscious assumptions, tomers, members of the public, regulators, and • volume of data, other stakeholders. Performing teams—those • fear of failure or consequence of failure, that demonstrate consistent quality of work and • culture, either application domain or progress toward goals—are cohesive and possess organizational, a cooperative, honest, and focused atmosphere. • lack of ability to express the problem, Individual and team goals are aligned so that the • perceived working atmosphere, and members naturally commit to and feel ownership • emotional status of the individual. of shared outcomes. Team members facilitate this atmosphere by The impact of these inhibiting factors can be being intellectually honest, making use of group reduced by cultivating good problem solving thinking, admitting ignorance, and acknowledg- habits that minimize the impact of misleading ing mistakes. They share responsibility, rewards, assumptions. The ability to focus is vital, as is and workload fairly. They take care to communi- intellectual humility: both allow a software engi- cate clearly, directly to each other and in docu- neer to suspend personal considerations and con- ments, as well as in source code, so that informa- sult with others freely, which is especially impor- tion is accessible to everyone. Peer reviews about tant when working in teams. work products are framed in a constructive and There is a set of basic methods engineers use nonpersonal way (see Reviews and Audits in the to facilitate problem solving (see Problem Solv- Software Quality KA). This allows all the mem- ing Techniques in the Computing Foundations bers to pursue a cycle of continuous improvement KA). Breaking down problems and solving them and growth without personal risk. In general, one piece at a time reduces cognitive overload. members of cohesive teams demonstrate respect Taking advantage of professional curiosity and for each other and their leader. pursuing continuous professional development 11-10 SWEBOK® Guide V3.0

through training and study add skills and knowl- Therefore, it is vital to maintain open and pro- edge to the software engineer’s portfolio; reading, ductive communication with stakeholders for the networking, and experimenting with new tools, duration of the software product’s lifetime. techniques, and methods are all valid means of professional development. 2.5. Dealing with Uncertainty and Ambiguity [4*, c24s4, c26s2] [9*, c9s4] 2.3. Dealing with Problem Complexity [3*, c3s2] [5*, c33] As with engineers of other fields, software engineers must often deal with and resolve uncer- Many, if not most, software engineering prob- tainty and ambiguities while providing services lems are too complex and difficult to address as and developing products. The software engineer a whole or to be tackled by individual software must attack and reduce or eliminate any lack of engineers. When such circumstances arise, the clarity that is an obstacle to performing work. usual means to adopt is teamwork and problem Often, uncertainty is simply a reflection of lack decomposition (see Problem Solving Techniques of knowledge. In this case, investigation through in the Computing Foundations KA). recourse to formal sources such as textbooks and Teams work together to deal with complex and professional journals, interviews with stakehold- large problems by sharing burdens and draw- ers, or consultation with teammates and peers can ing upon each other’s knowledge and creativity. overcome it. When software engineers work in teams, differ- When uncertainty or ambiguity cannot be over- ent views and abilities of the individual engineers come easily, software engineers or organizations complement each other and help build a solution may choose to regard it as a project risk. In this that is otherwise difficult to come by. Some spe- case, work estimates or pricing are adjusted to cific teamwork examples to software engineering mitigate the anticipated cost of addressing it (see are pair programming (see Agile Methods in the Risk Management in the Software Engineering Software Engineering Models and Methods KA) Management KA). and code review (see Reviews and Audits in the Software Quality KA). 2.6. Dealing with Multicultural Environments [9*, c10s7] 2.4. Interacting with Stakeholders [9*, c2s3.1] Multicultural environments can have an impact on the dynamics of a group. This is especially Success of a software engineering endeavor true when the group is geographically separated depends upon positive interactions with stake- or communication is infrequent, since such sepa- holders. They should provide support, informa- ration elevates the importance of each contact. tion, and feedback at all stages of the software Intercultural communication is even more dif- life cycle process. For example, during the early ficult if the difference in time zones make oral stages, it is critical to identify all stakeholders and communication less frequent. discover how the product will affect them, so that Multicultural environments are quite prevalent sufficient definition of the stakeholder require- in software engineering, perhaps more than in ments can be properly and completely captured. other fields of engineering, due to the strong trend During development, stakeholders may proof international outsourcing and the easy shipment vide feedback on specifications and/or early of software components instantaneously across versions of the software, change of priority, as the globe. For example, it is rather common for a well as clarification of detailed or new software software project to be divided into pieces across requirements. Last, during software maintenance national and cultural borders, and it is also quite and until the end of product life, stakeholders pro- common for a software project team to consist of vide feedback on evolving or new requirements people from diverse cultural backgrounds. as well problem reports so that the software may For a software project to be a success, team be extended and improved. members must achieve a level of tolerance, Software Engineering Professional Practice 11-11

acknowledging that some rules depend on soci- or rewriting software, it is critical to understand etal norms and that not all societies derive the both its implementation directly derived from the same solutions and expectations. presented code and its design, which must often This tolerance and accompanying understand- be inferred. ing can be facilitated by the support of leadership and management. More frequent communication, 3.2. Writing including face-to-face meetings, can help to miti- [3*, c1s5] gate geographical and cultural divisions, promote cohesiveness, and raise productivity. Also, being Software engineers are able to produce written able to communicate with teammates in their products as required by customer requests or gen- native language could be very beneficial. erally accepted practice. These written products may include source code, software project plans, 3. Communication Skills software requirement documents, risk analyses, software design documents, software test plans, It is vital that a software engineer communicate user manuals, technical reports and evaluations, well, both orally and in reading and writing. Suc- justifications, diagrams and charts, and so forth. cessful attainment of software requirements and Writing clearly and concisely is very important deadlines depends on developing clear under- because often it is the primary method of com- standing between the software engineer and munication among relevant parties. In all cases, customers, supervisors, coworkers, and suppli- written software engineering products must be ers. Optimal problem solving is made possible written so that they are accessible, understand- through the ability to investigate, comprehend, able and relevant for their intended audience(s). and summarize information. Customer product acceptance and safe product usage depend on the 3.3. Team and Group Communication provision of relevant training and documentation. [3*, c1s6.8] [4*, c22s3] [5*, c27s1] It follows that the software engineer’s own career [9*, c10s4] success is affected by the ability to consistently provide oral and written communication effec- Effective communication among team and group tively and on time. members is essential to a collaborative software engineering effort. Stakeholders must be con- 3.1. Reading, Understanding, and Summarizing sulted, decisions must be made, and plans must [5*, c33s3] be generated. The greater the number of team and group members, the greater the need to Software engineers are able to read and under- communicate. stand technical material. Technical material The number of communication paths, how- includes reference books, manuals, research ever, grows quadratically with the addition of papers, and program source code. each team member. Further, team members Reading is not only a primary way of improv- are unlikely to communicate with anyone per- ing skills, but also a way of gathering informa- ceived to be removed from them by more than tion necessary for the completion of engineering two degrees (levels). This problem can be more goals. A software engineer sifts through accu- serious when software engineering endeavors or mulated information, filtering out the pieces that organizations are spread across national and con- will be most helpful. Customers may request that tinental borders. a software engineer summarize the results of Some communication can be accomplished in such information gathering for them, simplifying writing. Software documentation is a common or explaining it so that they may make the final substitute for direct interaction. Email is another choice between competing solutions. but, although it is useful, it is not always enough; Reading and comprehending source code is also, if one sends too many messages, it becomes also a component of information gathering and difficult to identify the important information. problem solving. When modifying, extending, Increasingly, organizations are using enterprise 11-12 SWEBOK® Guide V3.0

collaboration tools to share information. In addi- phase, software engineers may walk customers tion, the use of electronic information stores, and teammates through software requirements accessible to all team members, for organiza- and conduct formal requirements reviews (see tional policies, standards, common engineering Requirement Reviews in the Software Require- procedures, and project-specific information, can ments KA). During and after software design, be most beneficial. software construction, and software maintenance, Some software engineering teams focus on software engineers lead reviews, product walk- face-to-face interaction and promote such inter- throughs (see Review and Audits in the Software action by office space arrangement. Although Quality KA), and training. All of these require the private offices improve individual productivity, ability to present technical information to groups colocating team members in physical or virtual and solicit ideas or feedback. forms and providing communal work areas is The software engineer’s ability to convey important to collaborative efforts. concepts effectively in a presentation therefore influences product acceptance, management, 3.4. Presentation Skills and customer support; it also influences the abil- [3*, c1s5] [4*, c22] [9*, c10s7–c10s8] ity of stakeholders to comprehend and assist in the product effort. This knowledge needs to be Software engineers rely on their presentation archived in the form of slides, knowledge write- skills during software life cycle processes. For up, technical whitepapers, and any other material example, during the software requirements utilized for knowledge creation. Software Engineering Professional Practice 11-13

MATRIX OF TOPICS VS. REFERENCE MATERIAL [1*] [4*] [6*] [3*] [5*] [7*] [9*] [8*] Moore 2006Moore Tockey 2004 Tockey Voland 2003 Voland Fairley 2009Fairley Bott et al. 2000 McConnell 2004 Sommerville 2011 IEEE-CS/ACM 1999

1. Professionalism 1.1. Accreditation, c1s4.1, Certification, and c1s5.1– Licensing c1s5.4 1.2. Codes of Ethics c1s6– and Professional c8 c1s2 c33 * c1s9 Conduct 1.3. Nature and c1s1– Role of Professional c1s2 c35s1 c1s2 Societies 1.4. Nature and Role of Software c5s3.2, c32s6 c1s2 Engineering c10s2.1 Standards 1.5. Economic c10s8 c1s1.1 c1 Impact of Software 1.6. Employment c7 Contracts c5s3– 1.7. Legal Issues c6, c11 c1s10 c5s4 1.8. Documentation c10s5.8 c1s5 c32 1.9. Tradeoff c1s2, c9s5.10 Analysis c10 2. Group Dynamics and Psychology 2.1. Dynamics of c1s3.5, Working in Teams/ c1s6 c10 Groups 2.2. Individual c1s6.5 c33 Cognition 2.3. 2.3 Dealing with c3s2 c33 Problem Complexity 2.4. Interacting with c2s3.1 Stakeholders 11-14 SWEBOK® Guide V3.0 [1*] [4*] [6*] [3*] [5*] [7*] [9*] [8*] Moore 2006Moore Tockey 2004 Tockey Voland 2003 Voland Fairley 2009Fairley Bott et al. 2000 McConnell 2004 Sommerville 2011 IEEE-CS/ACM 1999

2.5. Dealing with c24s4, Uncertainty and c9s4 c26s2 Ambiguity 2.6. Dealing with Multicultural c10s7 Environments 3. Communication Skills 3.1. Reading, Understanding, and c33s3 Summarizing 3.2. Writing c1s5 3.3. Team and Group c1s6.8 c22s3 c27s1 c10s4 Communication 3.4. Presentation c10s7– c1s5 c22 Skills c10s8 Software Engineering Professional Practice 11-15

FURTHER READINGS REFERENCES

Gerald M. Weinberg, The Psychology of [1*] F. Bott et al., Professional Issues in Computer Programming [10]. Software Engineering, 3rd ed., Taylor & Francis, 2000. This was the first major book to address programming as an individual and team effort and became [2] Merriam-Webster’s Collegiate Dictionary, a classic in the field. 11th ed., 2003.

Kinney and Lange, P.A., Intellectual Property [3*] G. Voland, Engineering by Design, 2nd ed., Law for Business Lawyers [11]. Prentice Hall, 2003.

This book covers IP laws in the US. It not only [4*] I. Sommerville, Software Engineering, 9th talks about what the IP law is; it also explains ed., Addison-Wesley, 2011. why it looks the way it does. [5*] S. McConnell, Code Complete, 2nd ed., Microsoft Press, 2004.

[6*] IEEE CS/ACM Joint Task Force on Software Engineering Ethics and Professional Practices, “Software Engineering Code of Ethics and Professional Practice (Version 5.2),” 1999; www.acm.org/serving/se/code.htm.

[7*] J.W. Moore, The Road Map to Software Engineering: A Standards-Based Guide, Wiley-IEEE Computer Society Press, 2006.

[8*] S. Tockey, Return on Software: Maximizing the Return on Your Software Investment, Addison-Wesley, 2004.

[9*] R.E. Fairley, Managing and Leading Software Projects, Wiley-IEEE Computer Society Press, 2009.

[10] G.M. Weinberg, The Psychology of Computer Programming: Silver Anniversary Edition, Dorset House, 1998.

[11] Kinney and Lange, P.A., Intellectual Property Law for Business Lawyers, Thomson West, 2013. CHAPTER 12

SOFTWARE ENGINEERING ECONOMICS

ACRONYMS the business goals of the organization. In all types of organizations—be it “for-profit,” “not- EVM Earned Value Management for-profit,” or governmental—this translates into IRR Internal Rate of Return sustainably staying in business. In “for-profit” Minimum Acceptable Rate of organizations this additionally relates to achiev- MARR Return ing a tangible return on the invested capital— SDLC Software Development Life Cycle both assets and capital employed. This KA has been formulated in a way to address all types of SPLC Software Product Life Cycle organizations independent of focus, product and ROI Return on Investment service portfolio, or capital ownership and taxa- ROCE Return on Capital Employed tion restrictions. TCO Total Cost of Ownership Decisions like “Should we use a specific component?” may look easy from a technical perspective, but can have serious implications on the business INTRODUCTION viability of a software project and the resulting product. Often engineers wonder whether such Software engineering economics is about mak- concerns apply at all, as they are “only engi- ing decisions related to software engineering in a neers.” Economic analysis and decision-making business context. The success of a software prod- are important engineering considerations because uct, service, and solution depends on good busi- engineers are capable of evaluating decisions both ness management. Yet, in many companies and technically and from a business perspective. The organizations, software business relationships to contents of this knowledge area are important top- software development and engineering remain ics for software engineers to be aware of even if vague. This knowledge area (KA) provides an they are never actually involved in concrete busi- overview on software engineering economics. ness decisions; they will have a well-rounded view Economics is the study of value, costs, of business issues and the role technical consid- resources, and their relationship in a given context erations play in making business decisions. Many or situation. In the discipline of software engi- engineering proposals and decisions, such as make neering, activities have costs, but the resulting versus buy, have deep intrinsic economic impacts software itself has economic attributes as well. that should be considered explicitly. Software engineering economics provides a way This KA first covers the foundations, key ter- to study the attributes of software and software minology, basic concepts, and common practices processes in a systematic way that relates them of software engineering economics to indicate to economic measures. These economic measures how decision-making in software engineering can be weighed and analyzed when making deci- includes, or should include a business perspec- sions that are within the scope of a software orga- tive. It then provides a life cycle perspective, nization and those within the integrated scope of highlights risk and uncertainty management, and an entire producing or acquiring business. shows how economic analysis methods are used. Software engineering economics is concerned Some practical considerations finalize the knowl- with aligning software technical decisions with edge area.

12-1 12-2 SWEBOK® Guide V3.0

Figure 12.1. Breakdown of Topics for the Software Engineering Economics KA Software Engineering Economics 12-3

BREAKDOWN OF TOPICS FOR to know the results of their investment: did they SOFTWARE ENGINEERING ECONOMICS get the profit they were expecting? In “for-profit” organizations, this relates to the tangible ROI The breakdown of topics for the Software Engi- (see section 4.3, Return on Investment), while in neering Economics KA is shown in Figure 12.1. “not-for-profit” and governmental organizations as well as “for-profit” organizations, it translates 1. Software Engineering Economics into sustainably staying in business. The primary Fundamentals role of accounting is to measure the organization’s actual financial performance and to com- 1.1. Finance municate financial information about a business [1*, c2] entity to stakeholders, such as shareholders, financial auditors, and investors. Communication Finance is the branch of economics concerned is generally in the form of financial statements with issues such as allocation, management, that show in money terms the economic resources acquisition, and investment of resources. Finance to be controlled. It is important to select the right is an element of every organization, including information that is both relevant and reliable to software engineering organizations. the user. Information and its timing are partially The field of finance deals with the concepts of governed by risk management and governance time, money, risk, and how they are interrelated. policies. Accounting systems are also a rich It also deals with how money is spent and bud- source of historical data for estimating. geted. Corporate finance is concerned with providing the funds for an organization’s activities. 1.3. Controlling Generally, this involves balancing risk and profit- [1*, c15] ability, while attempting to maximize an organization’s wealth and the value of its stock. This Controlling is an element of finance and account- holds primarily for “for-profit” organizations, ing. Controlling involves measuring and correct- but also applies to “not-for-profit” organizations. ing the performance of finance and accounting. The latter needs finances to ensure sustainability, It ensures that an organization’s objectives and while not targeting tangible profit. To do this, an plans are accomplished. Controlling cost is a spe- organization must cialized branch of controlling used to detect variances of actual costs from planned costs. • identify organizational goals, time horizons, risk factors, tax considerations, and financial 1.4. Cash Flow constraints; [1*, c3] • identify and implement the appropriate business strategy, such as which portfolio and Cash flow is the movement of money into or out investment decisions to take, how to manage of a business, project, or financial product over a cash flow, and where to get the funding; given period. The concepts of cash flow instances • measure financial performance, such as and cash flow streams are used to describe the cash flow and ROI (see section 4.3, Return business perspective of a proposal. To make a on Investment), and take corrective actions meaningful business decision about any specific in case of deviation from objectives and proposal, that proposal will need to be evaluated strategy. from a business perspective. In a proposal to develop and launch product X, the payment for 1.2. Accounting new software licenses is an example of an outgo- [1*, c15] ing cash flow instance. Money would need to be spent to carry out that proposal. The sales income Accounting is part of finance. It allows people from product X in the 11th month after market whose money is being used to run an organization launch is an example of an incoming cash flow 12-4 SWEBOK® Guide V3.0

Figure 12.2. A Cash Flow Diagram instance. Money would be coming in because of solutions. A commercial, off-the-shelf, object- carrying out the proposal. request broker product might cost a few thousand The term cash flow stream refers to the set of dollars, but the effort to develop a homegrown cash flow instances over time that are caused by service that gives the same functionality could carrying out some given proposal. The cash flow easily cost several hundred times that amount. stream is, in effect, the complete financial picture If the candidate solutions all adequately solve of that proposal. How much money goes out? the problem from a technical perspective, then When does it go out? How much money comes the selection of the most appropriate alternative in? When does it come in? Simply, if the cash should be based on commercial factors such as flow stream for Proposal A is more desirable than optimizing total cost of ownership (TCO) or the cash flow stream for Proposal B, then—all maximizing the short-term return on investment other things being equal—the organization is bet- (ROI). Life cycle costs such as defect correction, ter off carrying out Proposal A than Proposal B. field service, and support duration are also- rel Thus, the cash flow stream is an important input evant considerations. These costs need to be fac- for investment decision-making. A cash flow tored in when selecting among acceptable tech- instance is a specific amount of money flowing nical approaches, as they are part of the lifetime into or out of the organization at a specific time ROI (see section 4.3, Return on Investment). as a direct result of some activity. A systematic process for making decisions will A cash flow diagram is a picture of a cash flow achieve transparency and allow later justifica- stream. It gives the reader a quick overview of tion. Governance criteria in many organizations the financial picture of the subject organization or demand selection from at least two alternatives. project. Figure 12.2 shows an example of a cash A systematic process is shown in Figure 12.3. flow diagram for a proposal. It starts with a business challenge at hand and describes the steps to identify alternative solu- 1.5. Decision-Making Process tions, define selection criteria, evaluate the solu- [1*, c2, c4] tions, implement one selected solution, and monitor the performance of that solution. If we assume that candidate solutions solve a Figure 12.3 shows the process as mostly step- given technical problem equally well, why should wise and serial. The real process is more fluid. the organization care which one is chosen? The Sometimes the steps can be done in a different answer is that there is usually a large differ- order and often several of the steps can be done ence in the costs and incomes from the different in parallel. The important thing is to be sure that Software Engineering Economics 12-5

Figure 12.3. The Basic Business Decision-Making Process none of the steps are skipped or curtailed. It’s also 1.6. Valuation important to understand that this same process [1*, c5, c8] applies at all levels of decision making: from a decision as big as determining whether a software In an abstract sense, the decision-making pro- project should be done at all, to a deciding on an cess—be it financial decision making or other— algorithm or data structure to use in a software is about maximizing value. The alternative that module. The difference is how financially sig- maximizes total value should always be chosen. nificant the decision is and, therefore, how much A financial basis for value-based comparison is effort should be invested in making that deci- comparing two or more cash flows. Several bases sion. The project-level decision is financially sig- of comparison are available, including nificant and probably warrants a relatively high level of effort to make the decision. Selecting an • present worth algorithm is often much less financially signifi- • future worth cant and warrants a much lower level of effort to • annual equivalent make the decision, even though the same basic • internal rate of return decision-making process is being used. • (discounted) payback period. More often than not, an organization could carry out more than one proposal if it wanted Based on the time-value of money, two or more to, and usually there are important relationships cash flows are equivalent only when they equal among proposals. Maybe Proposal Y can only be the same amount of money at a common point carried out if Proposal X is also carried out. Or in time. Comparing cash flows only makes sense maybe Proposal P cannot be carried out if Pro- when they are expressed in the same time frame. posal Q is carried out, nor could Q be carried out Note that value can’t always be expressed in if P were. Choices are much easier to make when terms of money. For example, whether an item there are mutually exclusive paths—for example, is a brand name or not can significantly affect either A or B or C or whatever is chosen. In pre- its perceived value. Relevant values that can’t paring decisions, it is recommended to turn any be expressed in terms of money still need to be given set of proposals, along with their various expressed in similar terms so that they can be interrelationships, into a set of mutually exclu- evaluated objectively. sive alternatives. The choice can then be made among these alternatives. 12-6 SWEBOK® Guide V3.0

1.7. Inflation 1.10. Time-Value of Money [1*, c13] [1*, c5, c11]

Inflation describes long-term trends in prices. One of the most fundamental concepts in Inflation means that the same things cost more finance—and therefore, in business decisions— than they did before. If the planning horizon of is that money has time-value: its value changes a business decision is longer than a few years, or over time. A specific amount of money right now if the inflation rate is over a couple of percentage almost always has a different value than the same points annually, it can cause noticeable changes amount of money at some other time. This con- in the value of a proposal. The present time value cept has been around since the earliest recorded therefore needs to be adjusted for inflation rates human history and is commonly known as time- and also for exchange rate fluctuations. value. In order to compare proposals or portfolio elements, they should be normalized in cost, 1.8. Depreciation value, and risk to the net present value. Currency [1*, c14] exchange variations over time need to be taken into account based on historical data. This is par- Depreciation involves spreading the cost of a ticularly important in cross-border developments tangible asset across a number of time periods; of all kinds. it is used to determine how investments in capitalized assets are charged against income over 1.11. Efficiency several years. Depreciation is an important part [2*, c1] of determining after-tax cash flow, which is critical for accurately addressing profit and taxes. If Economic efficiency of a process, activity, or a software product is to be sold after the devel- task is the ratio of resources actually consumed to opment costs are incurred, those costs should be resources expected to be consumed or desired to capitalized and depreciated over subsequent time be consumed in accomplishing the process, activ- periods. The depreciation expense for each time ity, or task. Efficiency means “doing things right.” period is the capitalized cost of developing the An efficient behavior, like an effective behavior, software divided across the number of periods delivers results—but keeps the necessary effort to in which the software will be sold. A software a minimum. Factors that may affect efficiency in project proposal may be compared to other soft- software engineering include product complex- ware and nonsoftware proposals or to alternative ity, quality requirements, time pressure, process investment options, so it is important to deter- capability, team distribution, interrupts, feature mine how those other proposals would be depre- churn, tools, and programming language. ciated and how profits would be estimated. 1.12. Effectiveness 1.9. Taxation [2*, c1] [1*, c16, c17] Effectiveness is about having impact. It is the Governments charge taxes in order to finance relationship between achieved objectives to expenses that society needs but that no single orga- defined objectives. Effectiveness means “doing nization would invest in. Companies have to pay the right things.” Effectiveness looks only at income taxes, which can take a substantial portion whether defined objectives are reached—not at of a corporation’s gross profit. A decision analysis how they are reached. that does not account for taxation can lead to the wrong choice. A proposal with a high pretax profit 1.13. Productivity won’t look nearly as profitable in posttax terms. [2*, c23] Not accounting for taxation can also lead to unre- alistically high expectations about how profitable a Productivity is the ratio of output over input from proposed product might be. an economic perspective. Output is the value Software Engineering Economics 12-7

delivered. Input covers all resources (e.g., effort) from managing them individually.”2 Programs spent to generate the output. Productivity com- are often used to identify and manage different bines efficiency and effectiveness from a value- deliveries to a single customer or market over a oriented perspective: maximizing productivity time horizon of several years. is about generating highest value with lowest resource consumption. 2.4. Portfolio

2. Life Cycle Economics Portfolios are “projects, programs, subportfolios, and operations managed as a group to achieve 2.1. Product strategic objectives.”3 Portfolios are used to group [2*, c22] [3*, c6] and then manage simultaneously all assets within a business line or organization. Looking to an A product is an economic good (or output) that is entire portfolio makes sure that impacts of deci- created in a process that transforms product fac- sions are considered, such as resource allocation tors (or inputs) to an output. When sold, a prod- to a specific project—which means that the same uct is a deliverable that creates both a value and resources are not available for other projects. an experience for its users. A product can be a combination of systems, solutions, materials, 2.5. Product Life Cycle and services delivered internally (e.g., in-house [2*, c2] [3*, c2] IT solution) or externally (e.g., software application), either as-is or as a component for another A software product life cycle (SPLC) includes product (e.g., embedded software). all activities needed to define, build, operate, maintain, and retire a software product or service 2.2. Project and its variants. The SPLC activities of “oper- [2*, c22] [3*, c1] ate,” “maintain,” and “retire” typically occur in a much longer time frame than initial software A project is “a temporary endeavor undertaken development (the software development life to create a unique product, service, or result”.1 cycle—SDLC—see Software Life Cycle Mod- In software engineering, different project types els in the Software Engineering Process KA). are distinguished (e.g., product development, Also the operate-maintain-retire activities of an outsourced services, software maintenance, ser- SPLC typically consume more total effort and vice creation, and so on). During its life cycle, a other resources than the SDLC activities (see software product may require many projects. For Majority of Maintenance Costs in the Software example, during the product conception phase, Maintenance KA). The value contributed by a a project might be conducted to determine the software product or associated services can be customer need and market requirements; during objectively determined during the “operate and maintenance, a project might be conducted to maintain” time frame. Software engineering eco- produce a next version of a product. nomics should be concerned with all SPLC activities, including the activities after initial product 2.3. Program release.

A program is “a group of related projects, sub- 2.6. Project Life Cycle programs, and program activities managed in a [2*, c2] [3*, c2] coordinated way to obtain benefits not available Project life cycle activities typically involve five process groups—Initiating, Planning, Execut- 1 Project Management Institute, Inc., PMI Lexicon ing, Monitoring and Controlling, and Closing [4] of Project Management Terms, 2012, www.pmi.org/ PMBOK-Guide-and-Standards/~/media/Registered/ 2 Ibid. PMI_Lexicon_Final.ashx. 3 Ibid. 12-8 SWEBOK® Guide V3.0

(see the Software Engineering Management KA). 2.9. Planning Horizon The activities within a software project life cycle [1*, c11] are often interleaved, overlapped, and iterated in various ways [3*, c2] [5] (see the Software When an organization chooses to invest in a par- Engineering Process KA). For instance, agile ticular proposal, money gets tied up in that pro- product development within an SPLC involves posal—so-called “frozen assets.” The economic multiple iterations that produce increments of impact of frozen assets tends to start high and deliverable software. An SPLC should include decreases over time. On the other hand, operat- risk management and synchronization with dif- ing and maintenance costs of elements associated ferent suppliers (if any), while providing audit- with the proposal tend to start low but increase able decision-making information (e.g., comply- over time. The total cost of the proposal—that ing with product liability needs or governance is, owning and operating a product—is the sum regulations). The software project life cycle and of those two costs. Early on, frozen asset costs the software product life cycle are interrelated; an dominate; later, the operating and maintenance SPLC may include several SDLCs. costs dominate. There is a point in time where the sum of the costs is minimized; this is called the 2.7. Proposals minimum cost lifetime. [1*, c3] To properly compare a proposal with a four- year life span to a proposal with a six-year life Making a business decision begins with the span, the economic effects of either cutting the notion of a proposal. Proposals relate to reaching six-year proposal by two years or investing the a business objective—at the project, product, or profits from the four-year proposal for another portfolio level. A proposal is a single, separate two years need to be addressed. The planning option that is being considered, like carrying out horizon, sometimes known as the study period, a particular software development project or not. is the consistent time frame over which propos- Another proposal could be to enhance an exist- als are considered. Effects such as software life- ing software component, and still another might time will need to be factored into establishing a be to redevelop that same software from scratch. planning horizon. Once the planning horizon is Each proposal represents a unit of choice—either established, several techniques are available for you can choose to carry out that proposal or you putting proposals with different life spans into can choose not to. The whole purpose of business that planning horizon. decision-making is to figure out, given the current business circumstances, which proposals should 2.10. Price and Pricing be carried out and which shouldn’t. [1*, c13]

2.8. Investment Decisions A price is what is paid in exchange for a good or [1*, c4] service. Price is a fundamental aspect of financial modeling and is one of the four Ps of the marketing Investors make investment decisions to spend mix. The other three Ps are product, promotion, money and resources on achieving a target objec- and place. Price is the only revenue-generating ele- tive. Investors are either inside (e.g., finance, ment amongst the four Ps; the rest are costs. board) or outside (e.g., banks) the organization. Pricing is an element of finance and marketing. The target relates to some economic criteria, such It is the process of determining what a company as achieving a high return on the investment, will receive in exchange for its products. Pricing strengthening the capabilities of the organization, factors include manufacturing cost, market place- or improving the value of the company. Intangi- ment, competition, market condition, and quality ble aspects such as goodwill, culture, and compe- of product. Pricing applies prices to products and tences should be considered. services based on factors such as fixed amount, quantity break, promotion or sales campaign, Software Engineering Economics 12-9

specific vendor quote, shipment or invoice date, parameters used to determine whether programs, combination of multiple orders, service offerings, investments, and acquisitions are achieving the and many others. The needs of the consumer can desired results. It is used to evaluate whether be converted into demand only if the consumer performance objectives are actually achieved; to has the willingness and capacity to buy the prod- control budgets, resources, progress, and deci- uct. Thus, pricing is very important in marketing. sions; and to improve performance. Pricing is initially done during the project initiation phase and is a part of “go” decision making. 2.13. Earned Value Management [3*, c8] 2.11. Cost and Costing [1*, c15] Earned value management (EVM) is a project management technique for measuring progress A cost is the value of money that has been used up based on created value. At a given moment, the to produce something and, hence, is not available results achieved to date in a project are com- for use anymore. In economics, a cost is an alter- pared with the projected budget and the planned native that is given up as a result of a decision. schedule progress for that date. Progress relates A sunk cost is the expenses before a certain already-consumed resources and achieved time, typically used to abstract decisions from results at a given point in time with the respec- expenses in the past, which can cause emotional tive planned values for the same date. It helps hurdles in looking forward. From a traditional to identify possible performance problems at an economics point of view, sunk costs should not early stage. A key principle in EVM is tracking be considered in decision making. Opportunity cost and schedule variances via comparison of cost is the cost of an alternative that must be for- planned versus actual schedule and budget versus gone in order to pursue another alternative. actual cost. EVM tracking gives much earlier vis- Costing is part of finance and product manage- ibility to deviations and thus permits corrections ment. It is the process to determine the cost based earlier than classic cost and schedule tracking that on expenses (e.g., production, software engineer- only looks at delivered documents and products. ing, distribution, rework) and on the target cost to be competitive and successful in a market. 2.14. Termination Decisions The target cost can be below the actual estimated [1*, c11, c12] [2*, c9] cost. The planning and controlling of these costs (called cost management) is important and should Termination means to end a project or product. always be included in costing. Termination can be preplanned for the end of a An important concept in costing is the total cost long product lifetime (e.g., when foreseeing that a of ownership (TCO). This holds especially for product will reach its lifetime) or can come rather software, because there are many not-so-obvious spontaneously during product development costs related to SPLC activities after initial prod- (e.g., when project performance targets are not uct development. TCO for a software product is achieved). In both cases, the decision should be defined as the total cost for acquiring, activating, carefully prepared, considering always the alter- and keeping that product running. These costs natives of continuing versus terminating. Costs of can be grouped as direct and indirect costs. TCO different alternatives must be estimated—cover- is an accounting method that is crucial in making ing topics such as replacement, information col- sound economic decisions. lection, suppliers, alternatives, assets, and utiliz- ing resources for other opportunities. Sunk costs 2.12. Performance Measurement should not be considered in such decision making [3*, c7, c8] because they have been spent and will not reap- pear as a value. Performance measurement is the process whereby an organization establishes and measures the 12-10 SWEBOK® Guide V3.0

Figure 12.4. Goals, Estimates, and Plans

2.15. Replacement and Retirement Decisions A business goal relates business needs (such as [1*, c12] [2*, c9] increasing profitability) to investing resources (such as starting a project or launching a prod- A replacement decision is made when an organi- uct with a given budget, content, and timing). zation already has a particular asset and they are Goals apply to operational planning (for instance, considering replacing it with something else; for to reach a certain milestone at a given date or to example, deciding between maintaining and sup- extend software testing by some time to achieve a porting a legacy software product or redeveloping desired quality level—see Key Issues in the Soft- it from the ground up. Replacement decisions use ware Testing KA) and to the strategic level (such the same business decision process as described as reaching a certain profitability or market share above, but there are additional challenges: sunk in a stated time period). cost and salvage value. Retirement decisions are An estimate is a well-founded evaluation of also about getting out of an activity altogether, resources and time that will be needed to achieve such as when a software company considers not stated goals (see Effort, Schedule, and Cost Esti- selling a software product anymore or a hardware mation in the Software Engineering Management manufacturer considers not building and selling a KA and Maintenance Cost Estimation in the Soft- particular model of computer any longer. Retire- ware Maintenance KA). A software estimate is ment decision can be influenced by lock-in fac- used to determine whether the project goals can tors such as technology dependency and high exit be achieved within the constraints on schedule, costs. budget, features, and quality attributes. Estimates are typically internally generated and are not 3. Risk and Uncertainty necessarily visible externally. Estimates should not be driven exclusively by the project goals 3.1. Goals, Estimates, and Plans because this could make an estimate overly opti- [3*, c6] mistic. Estimation is a periodic activity; estimates should be continually revised during a project. Goals in software engineering economics are A plan describes the activities and milestones mostly business goals (or business objectives). that are necessary in order to reach the goals of Software Engineering Economics 12-11

a project (see Software Project Planning in the 3.3. Addressing Uncertainty Software Engineering Management KA). The [3*, c6] plan should be in line with the goal and the estimate, which is not necessarily easy and obvi- Because of the many unknown factors during ous—such as when a software project with given project initiation and planning, estimates are requirements would take longer than the target inherently uncertain; that uncertainty should be date foreseen by the client. In such cases, plans addressed in business decisions. Techniques for demand a review of initial goals as well as esti- addressing uncertainty include mates and the underlying uncertainties and inac- curacies. Creative solutions with the underlying • consider ranges of estimates rationale of achieving a win-win position are • analyze sensitivity to changes of assumptions applied to resolve conflicts. • delay final decisions. To be of value, planning should involve consideration of the project constraints and commit- 3.4. Prioritization ments to stakeholders. Figure 12.4 shows how [3*, c6] goals are initially defined. Estimates are done based on the initial goals. The plan tries to match Prioritization involves ranking alternatives based the goals and the estimates. This is an iterative on common criteria to deliver the best possible process, because an initial estimate typically does value. In software engineering projects, software not meet the initial goals. requirements are often prioritized in order to deliver the most value to the client within con- 3.2. Estimation Techniques straints of schedule, budget, resources, and tech- [3*, c6] nology, or to provide for building product increments, where the first increments provide the Estimations are used to analyze and forecast the highest value to the customer (see Requirements resources or time necessary to implement require- Classification and Requirements Negotiation in ments (see Effort, Schedule, and Cost Estimation the Software Requirements KA and Software in the Software Engineering Management KA Life Cycle Models in the Software Engineering and Maintenance Cost Estimation in the Software Process KA). Maintenance KA). Five families of estimation techniques exist: 3.5. Decisions under Risk [1*, c24] [3*, c9] • Expert judgment • Analogy Decisions under risk techniques are used when • Estimation by parts the decision maker can assign probabilities to the • Parametric methods different possible outcomes (see Risk Manage- • Statistical methods. ment in the Software Engineering Management KA). The specific techniques include No single estimation technique is perfect, so using multiple estimation technique is useful. • expected value decision making Convergence among the estimates produced by • expectation variance and decision making different techniques indicates that the estimates • Monte Carlo analysis are probably accurate. Spread among the esti- • decision trees mates indicates that certain factors might have • expected value of perfect information. been overlooked. Finding the factors that caused the spread and then reestimating again to produce results that converge could lead to a better estimate. 12-12 SWEBOK® Guide V3.0

Figure 12.5. The for-profit decision-making process

3.6. Decisions under Uncertainty 4. Economic Analysis Methods [1*, c25] [3*, c9] 4.1. For-Profit Decision Analysis Decisions under uncertainty techniques are used [1*, c10] when the decision maker cannot assign probabilities to the different possible outcomes because Figure 12.5 describes a process for identifying needed information is not available (see Risk the best alternative from a set of mutually exclu- Management in the Software Engineering Man- sive alternatives. Decision criteria depend on the agement KA). Specific techniques include business objectives and typically include ROI (see section 4.3, Return on Investment) or Return • Laplace Rule on Capital Employed (ROCE) (see section 4.4, • Maximin Rule Return on Capital Employed). • Maximax Rule For-profit decision techniques don’t apply for • Hurwicz Rule government and nonprofit organizations. In these • Minimax Regret Rule. cases, organizations have different goals—which means that a different set of decision techniques are needed, such as cost-benefit or cost-effectiveness analysis. Software Engineering Economics 12-13

4.2. Minimum Acceptable Rate of Return 4.5. Cost-Benefit Analysis [1*, c10] [1*, c18]

The minimum acceptable rate of return (MARR) Cost-benefit analysis is one of the most widely is the lowest internal rate of return the organi- used methods for evaluating individual propos- zation would consider to be a good investment. als. Any proposal with a benefit-cost ratio of less Generally speaking, it wouldn’t be smart to invest than 1.0 can usually be rejected without further in an activity with a return of 10% when there’s analysis because it would cost more than the ben- another activity that’s known to return 20%. efit. Proposals with a higher ratio need tocon- The MARR is a statement that an organization sider the associated risk of an investment and is confident it can achieve at least that rate of compare the benefits with the option of investing return. The MARR represents the organization’s the money at a guaranteed interest rate (see sec- opportunity cost for investments. By choosing tion 4.2, Minimum Acceptable Rate of Return). to invest in some activity, the organization is explicitly deciding to not invest that same money 4.6. Cost-Effectiveness Analysis somewhere else. If the organization is already [1*, c18] confident it can get some known rate of return, other alternatives should be chosen only if their Cost-effectiveness analysis is similar to cost- rate of return is at least that high. A simple way benefit analysis. There are two versions of cost- to account for that opportunity cost is to use the effectiveness analysis: the fixed-cost version MARR as the interest rate in business decisions. maximizes the benefit given some upper bound An alternative’s present worth evaluated at the on cost; the fixed-effectiveness version minimizes MARR shows how much more or less (in pres- the cost needed to achieve a fixed goal. ent-day cash terms) that alternative is worth than investing at the MARR. 4.7. Break-Even Analysis [1*, c19] 4.3. Return on Investment [1*, c10] Break-even analysis identifies the point where the costs of developing a product and the revenue Return on investment (ROI) is a measure of the to be generated are equal. Such an analysis can profitability of a company or business unit. It be used to choose between different proposals at is defined as the ratio of money gained or lost different estimated costs and revenue. Given esti- (whether realized or unrealized) on an investment mated costs and revenue of two or more propos- relative to the amount of money invested. The als, break-even analysis helps in choosing among purpose of ROI varies and includes, for instance, them. providing a rationale for future investments and acquisition decisions. 4.8. Business Case [1*, c3] 4.4. Return on Capital Employed The business case is the consolidated information The return on capital employed (ROCE) is a mea- summarizing and explaining a business proposal sure of the profitability of a company or business from different perspectives for a decision maker unit. It is defined as the ratio of a gross profit (cost, benefit, risk, and so on). It is often used before taxes and interest (EBIT) to the total assets to assess the potential value of a product, which minus current liabilities. It describes the return on can be used as a basis in the investment decision- the used capital. making process. As opposed to a mere profit- loss calculation, the business case is a “case” of plans and analyses that is owned by the product 12-14 SWEBOK® Guide V3.0

manager and used in support of achieving the find the point where overall performance is best. business objectives. Software’s classic space-time tradeoff is an example of optimization; an algorithm that runs 4.9. Multiple Attribute Evaluation faster will often use more memory. Optimization [1*, c26] balances the value of the faster runtime against the cost of the additional memory. The topics discussed so far are used to make deci- Real options analysis can be used to quantify sions based on a single decision criterion: money. the value of project choices, including the value The alternative with the best present worth, the of delaying a decision. Such options are difficult best ROI, and so forth is the one selected. Aside to compute with precision. However, awareness from technical feasibility, money is almost that choices have a monetary value provides always the most important decision criterion, but insight in the timing of decisions such as increas- it’s not always the only one. Quite often there are ing project staff or lengthening time to market to other criteria, other “attributes,” that need to be improve quality. considered, and those attributes can’t be cast in terms of money. Multiple attribute decision tech- 5. Practical Considerations niques allow other, nonfinancial criteria to be factored into the decision. 5.1. The “Good Enough” Principle There are two families of multiple attribute [1*, c21] decision techniques that differ in how they use the attributes in the decision. One family is the Often software engineering projects and products “compensatory,” or single-dimensioned, tech- are not precise about the targets that should be niques. This family collapses all of the attributes achieved. Software requirements are stated, but onto a single figure of merit. The family is called the marginal value of adding a bit more function- compensatory because, for any given alternative, ality cannot be measured. The result could be late a lower score in one attribute can be compensated delivery or too-high cost. The “good enough” by—or traded off against—a higher score in other principle relates marginal value to marginal cost attributes. The compensatory techniques include and provides guidance to determine criteria when a deliverable is “good enough” to be delivered. • nondimensional scaling These criteria depend on business objectives and • additive weighting on prioritization of different alternatives, such as • analytic hierarchy process. ranking software requirements, measurable quality attributes, or relating schedule to product con- In contrast, the other family is the “noncom- tent and cost. pensatory,” or fully dimensioned, techniques. The RACE principle (reduce accidents and This family does not allow tradeoffs among the control essence) is a popular rule towards good attributes. Each attribute is treated as a separate enough software. Accidents imply unnecessary entity in the decision process. The noncompensa- overheads such as gold-plating and rework due tory techniques include to late defect removal or too many requirements changes. Essence is what customers pay for. Soft- • dominance ware engineering economics provides the mech- • satisficing anisms to define criteria that determine when a • lexicography. deliverable is “good enough” to be delivered. It also highlights that both words are relevant: 4.10. Optimization Analysis “good” and “enough.” Insufficient quality or [1*, c20] insufficient quantity is not good enough. Agile methods are examples of “good enough” The typical use of optimization analysis is to that try to optimize value by reducing the over- study a cost function over a range of values to head of delayed rework and the gold plating that Software Engineering Economics 12-15

results from adding features that have low mar- In a typical ecosystem, there are producers and ginal value for the users (see Agile Methods in consumers, where the consumers add value to the Software Engineering Models and Methods the consumed resources. Note that a consumer is KA and Software Life Cycle Models in the Soft- not the end user but an organization that uses the ware Engineering Process KA). In agile meth- product to enhance it. A software ecosystem is, ods, detailed planning and lengthy development for instance, a supplier of an application working phases are replaced by incremental planning and with companies doing the installation and sup- frequent delivery of small increments of a deliv- port in different regions. Neither one could exist erable product that is tested and evaluated by user without the other. Ecosystems can be permanent representatives. or temporary. Software engineering economics provides the mechanisms to evaluate alternatives 5.2. Friction-Free Economy in establishing or extending an ecosystem—for instance, assessing whether to work with a spe- Economic friction is everything that keeps mar- cific distributor or have the distribution done by a kets from having perfect competition. It involves company doing service in an area. distance, cost of delivery, restrictive regulations, and/or imperfect information. In high-friction 5.4. Offshoring and Outsourcing markets, customers don’t have many suppliers from which to choose. Having been in a business Offshoring means executing a business activity for a while or owning a store in a good location beyond sales and marketing outside the home determines the economic position. It’s hard for country of an enterprise. Enterprises typically new competitors to start business and compete. either have their offshoring branches in low- The marketplace moves slowly and predictably. cost countries or they ask specialized companies Friction-free markets are just the reverse. New abroad to execute the respective activity. Offshor- competitors emerge and customers are quick to ing should therefore not be confused with out- respond. The marketplace is anything but predict- sourcing. Offshoring within a company is called able. Theoretically, software and IT are friction- captive offshoring. Outsourcing is the result-ori- free. New companies can easily create products ented relationship with a supplier who executes and often do so at a much lower cost than estab- business activities for an enterprise when, tra- lished companies, since they need not consider ditionally, those activities were executed inside any legacies. Marketing and sales can be done the enterprise. Outsourcing is site-independent. via the Internet and social networks, and basi- The supplier can reside in the neighborhood of cally free distribution mechanisms can enable a the enterprise or offshore (outsourced offshor- ramp up to a global business. Software engineering). Software engineering economics provides ing economics aims to provide foundations to the basic criteria and business tools to evaluate judge how a software business performs and how different sourcing mechanisms and control their friction-free a market actually is. For instance, performance. For instance, using an outsourcing competition among software app developers is supplier for software development and mainte- inhibited when apps must be sold through an app nance might reduce the cost per hour of software store and comply with that store’s rules. development, but increase the number of hours and capital expenses due to an increased need for 5.3. Ecosystems monitoring and communication. (For more information on offshoring and outsourcing, see “Out- An ecosystem is an environment consisting of all sourcing” in Management Issues in the Software the mutually dependent stakeholders, business Maintenance KA.) units, and companies working in a particular area. 12-16 SWEBOK® Guide V3.0

MATRIX OF TOPICS VS. REFERENCE MATERIAL [1*] [2*] [3*] Tockey 2005 Tockey Fairley 2009Fairley Sommerville 2011

1. Software Engineering Economics Fundamentals 1.1. Finance c2 1.2. Accounting c15 1.3. Controlling c15 1.4. Cash Flow c3 1.5. Decision-Making Process c2, c4 1.6. Valuation c5, c8 1.7. Inflation c13 1.8. Depreciation c14 1.9. Taxation c16, c17 1.10. Time-Value of Money c5, c11 1.11. Efficiency c1 1.12. Effectiveness c1 1.13. Productivity c23 2. Life Cycle Economics 2.1. Product c22 c6 2.2. Project c22 c1 2.3. Program 2.4. Portfolio 2.5. Product Life Cycle c2 c2 2.6. Project Life Cycle c2 c2 2.7. Proposals c3 2.8. Investment Decisions c4 2.9. Planning Horizon c11 2.10. Price and Pricing c13 2.11. Cost and Costing c15 2.12. Performance Measurement c7, c8 2.13. Earned Value Management c8 2.14. Termination Decisions c11, c12 c9 2.15. Replacement and Retirement Decisions c12 c9 Software Engineering Economics 12-17 [1*] [2*] [3*] Tockey 2005 Tockey Fairley 2009Fairley Sommerville 2011

3. Risk and Uncertainty 3.1. Goals, Estimates, and Plans c6 3.2. Estimation Techniques c6 3.3. Addressing Uncertainty c6 3.4. Prioritization c6 3.5. Decisions under Risk c24 c9 3.6. Decisions under Uncertainty c25 c9 4. Economic Analysis Methods 4.1. For-Profit Decision Analysis c10 4.2. Minimum Acceptable Rate of Return c10 4.3. Return on Investment c10 4.4. Return on Capital Employed 4.5. Cost-Benefit Analysis c18 4.6. Cost-Effectiveness Analysis c18 4.7. Break-Even Analysis c19 4.8. Business Case c3 4.9. Multiple Attribute Evaluation c26 4.10. Optimization Analysis c20 5. Practical Considerations 5.1. The “Good Enough” Principle c21 5.2. Friction-Free Economy 5.3. Ecosystems 5.4. Offshoring and Outsourcing 12-18 SWEBOK® Guide V3.0

FURTHER READINGS REFERENCES

A Guide to the Project Management Body of [1*] S. Tockey, Return on Software: Maximizing Knowledge (PMBOK® Guide) [4]. the Return on Your Software Investment, Addison-Wesley, 2004. The PMBOK® Guide provides guidelines for managing individual projects and defines project [2*] J.H. Allen et al., Software Security management related concepts. It also describes Engineering: A Guide for Project the project management life cycle and its related Managers, Addison-Wesley, 2008. processes, as well as the project life cycle. It is a globally recognized guide for the project man- [3*] R.E. Fairley, Managing and Leading agement profession. Software Projects, Wiley-IEEE Computer Society Press, 2009. Software Extension to the Guide to the Project Management Body of Knowledge (SWX) [5]. [4] Project Management Institute, A Guide to the Project Management Body of SWX provides adaptations and extensions to the Knowledge (PMBOK(R) Guide), 5th ed., generic practices of project management docu- Project Management Institute, 2013. mented in the PMBOK® Guide for managing software projects. The primary contribution of [5] Project Management Institute and IEEE this extension to the PMBOK® Guide is descrip- Computer Society, Software Extension tion of processes that are applicable for managing to the PMBOK® Guide Fifth Edition, ed: adaptive life cycle software projects. Project Management Institute, 2013.

B.W. Boehm, Software Engineering Economics [6] B.W. Boehm, Software Engineering [6]. Economics, Prentice-Hall, 1981.

This book is the classic reading on software [7] C. Ebert and R. Dumke, Software engineering economics. It provides an overview Measurement, Springer, 2007. of business thinking in software engineering. Although the examples and figures are dated, it [8] D.J. Reifer, Making the Software Business still is worth reading. Case: Improvement by the Numbers, Addison Wesley, 2002. C. Ebert and R. Dumke, Software Measurement [7].

This book provides an overview on quantitative methods in software engineering, starting with measurement theory and proceeding to performance management and business decision making.

D.J. Reifer, Making the Software Business Case: Improvement by the Numbers [8].

This book is a classic reading on making a business case in the software and IT businesses. Many useful examples illustrate how the business case is formulated and quantified. CHAPTER 13

COMPUTING FOUNDATIONS

ACRONYMS

AOP Aspect-Oriented Programming SCSI Small Computer System Interface ALU Arithmetic and Logic Unit SQL Structured Query Language Application Programming TCP Transport Control Protocol API Interface UDP User Datagram Protocol ATM Asynchronous Transfer Mode VPN Virtual Private Network B/S Browser-Server WAN Wide Area Network Computer Emergency Response CERT Team COTS Commercial Off-The-Shelf INTRODUCTION CRUD Create, Read, Update, Delete The scope of the Computing Foundations knowl- C/S Client-Server edge area (KA) encompasses the development CS Computer Science and operational environment in which software DBMS Database Management System evolves and executes. Because no software can FPU Float Point Unit exist in a vacuum or run without a computer, the core of such an environment is the computer and I/O Input and Output its various components. Knowledge about the ISA Instruction Set Architecture computer and its underlying principles of hard- International Organization for ware and software serves as a framework on ISO Standardization which software engineering is anchored. Thus, all ISP Internet Service Provider software engineers must have good understanding of the Computing Foundations KA. LAN Local Area Network It is generally accepted that software engi- MUX Multiplexer neering builds on top of computer science. For NIC Network Interface Card example, “Software Engineering 2004: Cur- OOP Object-Oriented Programming riculum Guidelines for Undergraduate Degree Programs in Software Engineering” [1] clearly OS Operating System states, “One particularly important aspect is that OSI Open Systems Interconnection software engineering builds on computer science PC Personal Computer and mathematics” (italics added). PDA Personal Digital Assistant Steve Tockey wrote in his book Return on Software: PPP Point-to-Point Protocol RFID Radio Frequency Identification Both computer science and software engi- RAM Random Access Memory neering deal with computers, computing, ROM Read Only Memory and software. The science of computing, as a body of knowledge, is at the core of both.

13-1 13-2 SWEBOK® Guide V3.0

Figure 13.1. Breakdown of Topics for the Computing Foundations KA

… Software engineering is concerned with KA. For example, computer graphics—while an the application of computers, computing, important course in a computer science degree and software to practical purposes, specifi- program—is not included in this KA. cally the design, construction, and opera- Second, some topics discussed in this guide- tion of efficient and economical software line do not exist as standalone courses in under- systems. graduate or graduate computer science programs. Consequently, such topics may not be adequately Thus, at the core of software engineering is an covered in a purely course-based breakdown. For understanding of computer science. example, abstraction is a topic incorporated into While few people will deny the role computer several different computer science courses; it is science plays in the development of software unclear which course abstraction should belong engineering both as a discipline and as a body of to in a course-based breakdown of topics. knowledge, the importance of computer science The Computing Foundations KA is divided into to software engineering cannot be overempha- seventeen different topics. A topic’s direct useful- sized; thus, this Computing Foundations KA is ness to software engineers is the criterion used for being written. selecting topics for inclusion in this KA (see Figure The majority of topics discussed in the Com- 13.1). The advantage of this topic-based breakdown puting Foundations KA are also topics of discus- is its foundation on the belief that Computing Foun- sion in basic courses given in computer science dations—if it is to be grasped firmly—must be con- undergraduate and graduate programs. Such sidered as a collection of logically connected topics courses include programming, data structure, undergirding software engineering in general and algorithms, computer organization, operating software construction in particular. systems, compilers, databases, networking, dis- The Computing Foundations KA is related tributed systems, and so forth. Thus, when break- closely to the Software Design, Software Con- ing down topics, it can be tempting to decompose struction, Software Testing, Software Main- the Computing Foundations KA according to tenance, Software Quality, and Mathematical these often-found divisions in relevant courses. Foundations KAs. However, a purely course-based division of topics suffers serious drawbacks. For one, not BREAKDOWN OF TOPICS FOR all courses in computer science are related or COMPUTING FOUNDATIONS equally important to software engineering. Thus, some topics that would otherwise be covered in a The breakdown of topics for the Computing computer science course are not covered in this Foundations KA is shown in Figure 13.1. Computing Foundations 13-3

1. Problem Solving Techniques 1.3. Analyze the Problem [2*, s3.2, c4] [3*, c5] Once the problem statement is available, the next The concepts, notions, and terminology introduced step is to analyze the problem statement or situ- here form an underlying basis for understanding ation to help structure our search for a solution. the role and scope of problem solving techniques. Four types of analysis include situation analysis, in which the most urgent or critical aspects of a 1.1. Definition of Problem Solving situation are identified first; problem analysis, in which the cause of the problem must be deter- Problem solving refers to the thinking and activi- mined; decision analysis, in which the action(s) ties conducted to answer or derive a solution to needed to correct the problem or eliminate its a problem. There are many ways to approach a cause must be determined; and potential problem problem, and each way employs different tools analysis, in which the action(s) needed to prevent and uses different processes. These different any reoccurrences of the problem or the develop- ways of approaching problems gradually expand ment of new problems must be determined. and define themselves and finally give rise to different disciplines. For example, software engi- 1.4. Design a Solution Search Strategy neering focuses on solving problems using computers and software. Once the problem analysis is complete, we can While different problems warrant different focus on structuring a search strategy to find the solutions and may require different tools and solution. In order to find the “best” solution (here, processes, the methodology and techniques used “best” could mean different things to different in solving problems do follow some guidelines people, such as faster, cheaper, more usable, dif- and can often be generalized as problem solving ferent capabilities, etc.), we need to eliminate techniques. For example, a general guideline for paths that do not lead to viable solutions, design solving a generic engineering problem is to use tasks in a way that provides the most guidance in the three-step process given below [2*]. searching for a solution, and use various attributes of the final solution state to guide our choices in • Formulate the real problem. the problem solving process. • Analyze the problem. • Design a solution search strategy. 1.5. Problem Solving Using Programs

1.2. Formulating the Real Problem The uniqueness of computer software gives problem solving a flavor that is distinct from general Gerard Voland writes, “It is important to recog- engineering problem solving. To solve a problem nize that a specific problem should be formulated using computers, we must answer the following if one is to develop a specific solution” [2*]. questions. This formulation is called the problem statement, which explicitly specifies what both the problem • How do we figure out what to tell the com- and the desired outcome are. puter to do? Although there is no universal way of stat- • How do we convert the problem statement ing a problem, in general a problem should be into an algorithm? expressed in such a way as to facilitate the devel- • How do we convert the algorithm into opment of solutions. Some general techniques machine instructions? to help one formulate the real problem include statement-restatement, determining the source The first task in solving a problem using a com- and the cause, revising the statement, analyzing puter is to determine what to tell the computer to present and desired state, and using the fresh eye do. There may be many ways to tell the story, but approach. all should take the perspective of a computer such 13-4 SWEBOK® Guide V3.0

that the computer can eventually solve the prob- “Through abstraction,” according to Voland, lem. In general, a problem should be expressed “we view the problem and its possible solution in such a way as to facilitate the development of paths from a higher level of conceptual under- algorithms and data structures for solving it. standing. As a result, we may become better pre- The result of the first task is a problem state- pared to recognize possible relationships between ment. The next step is to convert the problem state- different aspects of the problem and thereby gen- ment into algorithms that solve the problem. Once erate more creative design solutions” [2*]. This an algorithm is found, the final step converts the is particularly true in computer science in general algorithm into machine instructions that form the (such as hardware vs. software) and in software final solution: software that solves the problem. engineering in particular (data structure vs. data Abstractly speaking, problem solving using a flow, and so forth). computer can be considered as a process of problem transformation—in other words, the step-by- 2.1. Levels of Abstraction step transformation of a problem statement into a problem solution. To the discipline of software When abstracting, we concentrate on one “level” engineering, the ultimate objective of problem of the big picture at a time with confidence that solving is to transform a problem expressed in we can then connect effectively with levels above natural language into electrons running around and below. Although we focus on one level, a circuit. In general, this transformation can be abstraction does not mean knowing nothing about broken into three phases: the neighboring levels. Abstraction levels do not necessarily correspond to discrete components a) Development of algorithms from the prob- in reality or in the problem domain, but to well- lem statement. defined standard interfaces such as programming b) Application of algorithms to the problem. APIs. The advantages that standard interfaces c) Transformation of algorithms to program provide include portability, easier software/hard- code. ware integration and wider usage.

The conversion of a problem statement into 2.2. Encapsulation algorithms and algorithms into program codes usually follows a “stepwise refinement” (a.k.a. Encapsulation is a mechanism used to imple- systematic decomposition) in which we start ment abstraction. When we are dealing with one with a problem statement, rewrite it as a task, level of abstraction, the information concerning and recursively decompose the task into a few the levels below and above that level is encapsu- simpler subtasks until the task is so simple that lated. This information can be the concept, prob- solutions to it are straightforward. There are three lem, or observable phenomenon; or it may be the basic ways of decomposing: sequential, condi- permissible operations on these relevant entities. tional, and iterative. Encapsulation usually comes with some degree of information hiding in which some or all of 2. Abstraction the underlying details are hidden from the level [3*, s5.2–5.4] above the interface provided by the abstraction. To an object, information hiding means we don’t Abstraction is an indispensible technique associ- need to know the details of how the object is rep- ated with problem solving. It refers to both the resented or how the operations on those objects process and result of generalization by reducing are implemented. the information of a concept, a problem, or an observable phenomenon so that one can focus 2.3. Hierarchy on the “big picture.” One of the most important skills in any engineering undertaking is framing When we use abstraction in our problem formula- the levels of abstraction appropriately. tion and solution, we may use different abstractions Computing Foundations 13-5

at different times—in other words, we work on dif- perform a desired function. It is an indispensible ferent levels of abstraction as the situation calls. part in software construction. In general, pro- Most of the time, these different levels of abstrac- gramming can be considered as the process of tion are organized in a hierarchy. There are many designing, writing, testing, debugging, and main- ways to structure a particular hierarchy and the taining the source code. This source code is writ- criteria used in determining the specific content of ten in a programming language. each layer in the hierarchy varies depending on the The process of writing source code often individuals performing the work. requires expertise in many different subject Sometimes, a hierarchy of abstraction is sequen- areas—including knowledge of the application tial, which means that each layer has one and only domain, appropriate data structures, special- one predecessor (lower) layer and one and only ized algorithms, various language constructs, one successor (upper) layer—except the upmost good programming techniques, and software layer (which has no successor) and the bottommost engineering. layer (which has no predecessor). Sometimes, however, the hierarchy is organized in a tree-like 3.1. The Programming Process structure, which means each layer can have more than one predecessor layer but only one successor Programming involves design, writing, testing, layer. Occasionally, a hierarchy can have a many- debugging, and maintenance. Design is the con- to-many structure, in which each layer can have ception or invention of a scheme for turning a multiple predecessors and successors. At no time, customer requirement for computer software into shall there be any loop in a hierarchy. operational software. It is the activity that links A hierarchy often forms naturally in task decom- application requirements to coding and debug- position. Often, a task analysis can be decomposed ging. Writing is the actual coding of the design in a hierarchical fashion, starting with the larger in an appropriate programming language. Testing tasks and goals of the organization and breaking is the activity to verify that the code one writes each of them down into smaller subtasks that can actually does what it is supposed to do. Debug- again be further subdivided This continuous divi- ging is the activity to find and fix bugs (faults) in sion of tasks into smaller ones would produce a the source code (or design). Maintenance is the hierarchical structure of tasks-subtasks. activity to update, correct, and enhance existing programs. Each of these activities is a huge topic 2.4. Alternate Abstractions and often warrants the explanation of an entire KA in the SWEBOK Guide and many books. Sometimes it is useful to have multiple alternate abstractions for the same problem so that one can 3.2. Programming Paradigms keep different perspectives in mind. For example, we can have a class diagram, a state chart, Programming is highly creative and thus some- and a sequence diagram for the same software what personal. Different people often write dif- at the same level of abstraction. These alternate ferent programs for the same requirements. This abstractions do not form a hierarchy but rather diversity of programming causes much difficulty complement each other in helping understanding in the construction and maintenance of large the problem and its solution. Though beneficial, it complex software. Various programming para- is as times difficult to keep alternate abstractions digms have been developed over the years to put in sync. some standardization into this highly creative and personal activity. When one programs, he or she 3. Programming Fundamentals can use one of several programming paradigms to [3*, c6–19] write the code. The major types of programming paradigms are discussed below. Programming is composed of the methodologies Unstructured Programming: In unstructured or activities for creating computer programs that programming, a programmer follows his/her 13-6 SWEBOK® Guide V3.0

hunch to write the code in whatever way he/she problems. In functional programming, all com- likes as long as the function is operational. Often, putations are treated as the evaluation of math- the practice is to write code to fulfill a specific ematical functions. In contrast to the imperative utility without regard to anything else. Programs programming that emphasizes changes in state, written this way exhibit no particular structure— functional programming emphasizes the applica- thus the name “unstructured programming.” tion of functions, avoids state and mutable data, Unstructured programming is also sometimes and provides referential transparency. called ad hoc programming. Structured/Procedural/ Imperative Program- 4. Programming Language Basics ming: A hallmark of structured programming is [4*, c6] the use of well-defined control structures, including procedures (and/or functions) with each pro- Using computers to solve problems involves cedure (or function) performing a specific task. programming—which is writing and organiz- Interfaces exist between procedures to facilitate ing instructions telling the computer what to do correct and smooth calling operations of the pro- at each step. Programs must be written in some grams. Under structured programming, program- programming language with which and through mers often follow established protocols and rules which we describe necessary computations. In of thumb when writing code. These protocols other words, we use the facilities provided by a and rules can be numerous and cover almost the programming language to describe problems, entire scope of programming—ranging from the develop algorithms, and reason about problem simplest issue (such as how to name variables, solutions. To write any program, one must under- functions, procedures, and so forth) to more com- stand at least one programming language. plex issues (such as how to structure an interface, how to handle exceptions, and so forth). 4.1. Programming Language Overview Object-Oriented Programming: While procedural programming organizes programs around A programming language is designed to express procedures, object-oriented programming (OOP) computations that can be performed by a com- organize a program around objects, which are puter. In a practical sense, a programming lan- abstract data structures that combine both data guage is a notation for writing programs and thus and methods used to access or manipulate the should be able to express most data structures and data. The primary features of OOP are that objects algorithms. Some, but not all, people restrict the representing various abstract and concrete entities term “programming language” to those languages are created and these objects interact with each that can express all possible algorithms. other to collectively fulfill the desired functions. Not all languages have the same importance Aspect-Oriented Programming: Aspect-ori- and popularity. The most popular ones are often ented programming (AOP) is a programming defined by a specification document established paradigm that is built on top of OOP. AOP aims by a well-known and respected organization. For to isolate secondary or supporting functions from example, the C programming language is speci- the main program’s business logic by focusing fied by an ISO standard named ISO/IEC 9899. on the cross sections (concerns) of the objects. Other languages, such as Perl and Python, do not The primary motivation for AOP is to resolve enjoy such treatment and often have a dominant the object tangling and scattering associated with implementation that is used as a reference. OOP, in which the interactions among objects become very complex. The essence of AOP is 4.2. Syntax and Semantics of Programming the greatly emphasized separation of concerns, Languages which separates noncore functional concerns or logic into various aspects. Just like natural languages, many programming Functional Programming: Though less popu- languages have some form of written specifica- lar, functional programming is as viable as tion of their syntax (form) and semantics (mean- the other paradigms in solving programming ing). Such specifications include, for example, Computing Foundations 13-7

specific requirements for the definition -of vari 4.4. High-Level Programming Languages ables and constants (in other words, declaration and types) and format requirements for the A high-level programming language has a strong instructions themselves. abstraction from the details of the computer’s In general, a programming language supports ISA. In comparison to low-level programming such constructs as variables, data types, con- languages, it often uses natural-language ele- stants, literals, assignment statements, control ments and is thus much easier for humans to statements, procedures, functions, and comments. understand. Such languages allow symbolic nam- The syntax and semantics of each construct must ing of variables, provide expressiveness, and be clearly specified. enable abstraction of the underlying hardware. For example, while each microprocessor has its 4.3. Low-Level Programming Languages own ISA, code written in a high-level programming language is usually portable between many Programming language can be classified into two different hardware platforms. For these reasons, classes: low-level languages and high-level lan- most programmers use and most software are guages. Low-level languages can be understood written in high-level programming languages. by a computer with no or minimal assistance and Examples of high-level programming languages typically include machine languages and assem- include C, C++, C#, and Java. bly languages. A machine language uses ones and zeros to represent instructions and variables, 4.5. Declarative vs. Imperative Programming and is directly understandable by a computer. An Languages assembly language contains the same instructions as a machine language but the instructions and Most programming languages (high-level or low- variables have symbolic names that are easier for level) allow programmers to specify the indi- humans to remember. vidual instructions that a computer is to execute. Assembly languages cannot be directly under- Such programming languages are called impera- stood by a computer and must be translated into a tive programming languages because one has to machine language by a utility program called an specify every step clearly to the computer. But assembler. There often exists a correspondence some programming languages allow program- between the instructions of an assembly language mers to only describe the function to be per- and a machine language, and the translation from formed without specifying the exact instruction assembly code to machine code is straightfor- sequences to be executed. Such programming ward. For example, “add r1, r2, r3” is an assem- languages are called declarative programming bly instruction for adding the content of register languages. Declarative languages are high-level r2 and r3 and storing the sum into register r1. This languages. The actual implementation of the instruction can be easily translated into machine computation written in such a language is hidden code “0001 0001 0010 0011.” (Assume the oper- from the programmers and thus is not a concern ation code for addition is 0001, see Figure 13.2). for them. The key point to note is that declarative pro- add r1, r2, r3 gramming only describes what the program 0001 0001 0010 0011 should accomplish without describing how to accomplish it. For this reason, many people Figure 13.2. Assembly-to-Binary Translations believe declarative programming facilitates easier software development. Declarative pro- One common trait shared by these two types gramming languages include Lisp (also a func- of language is their close association with the tional programming language) and Prolog, while specifics of a type of computer or instruction set imperative programming languages include C, architecture (ISA). C++, and JAVA. 13-8 SWEBOK® Guide V3.0

5. Debugging Tools and Techniques 5.2. Debugging Techniques [3*, c23] Debugging involves many activities and can be Once a program is coded and compiled (compila- static, dynamic, or postmortem. Static debug- tion will be discussed in section 10), the next step ging usually takes the form of code review, while is debugging, which is a methodical process of dynamic debugging usually takes the form of finding and reducing the number of bugs or faults tracing and is closely associated with testing. in a program. The purpose of debugging is to find Postmortem debugging is the act of debugging out why a program doesn’t work or produces a the core dump (memory dump) of a process. Core wrong result or output. Except for very simple dumps are often generated after a process has ter- programs, debugging is always necessary. minated due to an unhandled exception. All three techniques are used at various stages of program 5.1. Types of Errors development. The main activity of dynamic debugging is When a program does not work, it is often because tracing, which is executing the program one piece the program contains bugs or errors that can be at a time, examining the contents of registers and either syntactic errors, logical errors, or data errors. memory, in order to examine the results at each Logical errors and data errors are also known as step. There are three ways to trace a program. two categories of “faults” in software engineering terminology (see topic 1.1, Testing-Related Ter- • Single-stepping: execute one instruction at minology, in the Software Testing KA). a time to make sure each instruction is exe- Syntax errors are simply any error that pre- cuted correctly. This method is tedious but vents the translator (compiler/interpreter) from useful in verifying each step of a program. successfully parsing the statement. Every state- • Breakpoints: tell the program to stop execut- ment in a program must be parse-able before its ing when it reaches a specific instruction. meaning can be understood and interpreted (and, This technique lets one quickly execute therefore, executed). In high-level programming selected code sequences to get a high-level languages, syntax errors are caught during the overview of the execution behavior. compilation or translation from the high-level • Watch points: tell the program to stop when a language into machine code. For example, in the register or memory location changes or when C/C++ programming language, the statement it equals to a specific value. This technique “123=constant;” contains a syntax error that will is useful when one doesn’t know where or be caught by the compiler during compilation. when a value is changed and when this value Logic errors are semantic errors that result in change likely causes the error. incorrect computations or program behaviors. Your program is legal, but wrong! So the results 5.3. Debugging Tools do not match the problem statement or user expectations. For example, in the C/C++ programming Debugging can be complex, difficult, and tedious. language, the inline function “int f(int x) {return Like programming, debugging is also highly cre- f(x-1);}” for computing factorial x! is legal but ative (sometimes more creative than program- logically incorrect. This type of error cannot be ming). Thus some help from tools is in order. For caught by a compiler during compilation and is dynamic debugging, debuggers are widely used often discovered through tracing the execution of and enable the programmer to monitor the execu- the program (Modern static checkers do identify tion of a program, stop the execution, restart the some of these errors. However, the point remains execution, set breakpoints, change values in mem- that these are not machine checkable in general). ory, and even, in some cases, go back in time. Data errors are input errors that result either in For static debugging, there are many static input data that is different from what the program code analysis tools, which look for a specific expects or in the processing of wrong data. set of known problems within the source code. Computing Foundations 13-9

Both commercial and free tools exist in various 6.2. Types of Data Structure languages. These tools can be extremely useful when checking very large source trees, where it is As mentioned above, different perspectives can impractical to do code walkthroughs. The UNIX be used to classify data structures. However, the lint program is an early example. predominant perspective used in classification centers on physical and logical ordering between 6. Data Structure and Representation data items. This classification divides data struc- [5*, s2.1–2.6] tures into linear and nonlinear structures. Linear structures organize data items in a single dimen- Programs work on data. But data must be sion in which each data entry has one (physical expressed and organized within computers before or logical) predecessor and one successor with being processed by programs. This organization the exception of the first and last entry. The first and expression of data for programs’ use is the entry has no predecessor and the last entry has subject of data structure and representation. Sim- no successor. Nonlinear structures organize data ply put, a data structure tries to store and organize items in two or more dimensions, in which case data in a computer in such a way that the data can one entry can have multiple predecessors and be used efficiently. There are many types of data successors. Examples of linear structures include structures and each type of structure is suitable lists, stacks, and queues. Examples of nonlinear for some kinds of applications. For example, B/ structures include heaps, hash tables, and trees B+ trees are well suited for implementing mas- (such as binary trees, balance trees, B-trees, and sive file systems and databases. so forth). Another type of data structure that is often 6.1. Data Structure Overview encountered in programming is the compound structure. A compound data structure builds on Data structures are computer representations of top of other (more primitive) data structures and, data. Data structures are used in almost every pro- in some way, can be viewed as the same structure gram. In a sense, no meaningful program can be as the underlying structure. Examples of com- constructed without the use of some sort of data pound structures include sets, graphs, and parti- structure. Some design methods and program- tions. For example, a partition can be viewed as ming languages even organize an entire software a set of sets. system around data structures. Fundamentally, data structures are abstractions defined on a col- 6.3. Operations on Data Structures lection of data and its associated operations. Often, data structures are designed for improv- All data structures support some operations that ing program or algorithm efficiency. Examples of produce a specific structure and ordering, or such data structures include stacks, queues, and retrieve relevant data from the structure, store data heaps. At other times, data structures are used for into the structure, or delete data from the structure. conceptual unity (abstract data type), such as the Basic operations supported by all data structures name and address of a person. Often, a data struc- include create, read, update, and delete (CRUD). ture can determine whether a program runs in a few seconds or in a few hours or even a few days. • Create: Insert a new data entry into the From the perspective of physical and logi- structure. cal ordering, a data structure is either linear or • Read: Retrieve a data entry from the structure. nonlinear. Other perspectives give rise to dif- • Update: Modify an existing data entry. ferent classifications that include homogeneous • Delete: Remove a data entry from the vs. heterogeneous, static vs. dynamic, persistent structure. vs. transient, external vs. internal, primitive vs. aggregate, recursive vs. nonrecursive; passive vs. Some data structures also support additional active; and stateful vs. stateless structures. operations: 13-10 SWEBOK® Guide V3.0

• Find a particular element in the structure. 7.2. Attributes of Algorithms • Sort all elements according to some ordering. • Traverse all elements in some specific order. The attributes of algorithms are many and often • Reorganize or rebalance the structure. include modularity, correctness, maintainability, functionality, robustness, user-friendliness Different structures support different opera- (i.e. easy to be understood by people), program- tions with different efficiencies. The difference mer time, simplicity, and extensibility. A com- between operation efficiency can be significant. monly emphasized attribute is “performance” For example, it is easy to retrieve the last item or “efficiency” by which we mean both time inserted into a stack, but finding a particular ele- and resource-usage efficiency while generally ment within a stack is rather slow and tedious. emphasizing the time axis. To some degree, efficiency determines if an algorithm is feasible or 7. Algorithms and Complexity impractical. For example, an algorithm that takes [5*, s1.1–1.3, s3.3–3.6, s4.1–4.8, s5.1–5.7, one hundred years to terminate is virtually use- s6.1–6.3, s7.1–7.6, s11.1, s12.1] less and is even considered incorrect.

Programs are not random pieces of code: they are 7.3. Algorithmic Analysis meticulously written to perform user-expected actions. The guide one uses to compose programs Analysis of algorithms is the theoretical study are algorithms, which organize various functions of computer-program performance and resource into a series of steps and take into consideration usage; to some extent it determines the goodness the application domain, the solution strategy, and of an algorithm. Such analysis usually abstracts the data structures being used. An algorithm can away the particular details of a specific computer be very simple or very complex. and focuses on the asymptotic, machine-independent analysis. 7.1. Overview of Algorithms There are three basic types of analysis. In worst-case analysis, one determines the maxi- Abstractly speaking, algorithms guide the opera- mum time or resources required by the algorithm tions of computers and consist of a sequence of on any input of size n. In average-case analysis, actions composed to solve a problem. Alternative one determines the expected time or resources definitions include but are not limited to: required by the algorithm over all inputs of size n; in performing average-case analysis, one often • An algorithm is any well-defined computa- needs to make assumptions on the statistical dis- tional procedure that takes some value or set tribution of inputs. The third type of analysis is of values as input and produces some value the best-case analysis, in which one determines or set of values as output. the minimum time or resources required by the • An algorithm is a sequence of computational algorithm on any input of size n. Among the steps that transform the input into the output. three types of analysis, average-case analysis is • An algorithm is a tool for solving a well- the most relevant but also the most difficult to specified computation problem. perform. Besides the basic analysis methods, there are Of course, different definitions are favored also the amortized analysis, in which one deter- by different people. Though there is no univer- mines the maximum time required by an algo- sally accepted definition, some agreement exists rithm over a sequence of operations; and the that an algorithm needs to be correct, finite (in competitive analysis, in which one determines other words, terminate eventually or one must be the relative performance merit of an algorithm able to write it in a finite number of steps), and against the optimal algorithm (which may not unambiguous. be known) in the same category (for the same operations). Computing Foundations 13-11

7.4. Algorithmic Design Strategies aggregation, potential, and accounting to analyze the worst performance of an algorithm on a The design of algorithms generally follows one sequence of operations; and competitive analysis, of the following strategies: brute force, divide in which one uses methods such as potential and and conquer, dynamic programming, and greedy accounting to analyze the relative performance of selection. The brute force strategy is actually a an algorithm to the optimal algorithm. no-strategy. It exhaustively tries every possible For complex problems and algorithms, one way to tackle a problem. If a problem has a solu- may need to use a combination of the aforemen- tion, this strategy is guaranteed to find it; however, tioned analysis strategies. the time expense may be too high. The divide and conquer strategy improves on the brute force 8. Basic Concept of a System strategy by dividing a big problem into smaller, [6*, c10] homogeneous problems. It solves the big problem by recursively solving the smaller problems Ian Sommerville writes, “a system is a purposeful and combing the solutions to the smaller prob- collection of interrelated components that work lems to form the solution to the big problem. The together to achieve some objective” [6*]. A sys- underlying assumption for divide and conquer is tem can be very simple and include only a few that smaller problems are easier to solve. components, like an ink pen, or rather complex, The dynamic programming strategy improves like an aircraft. Depending on whether humans on the divide and conquer strategy by recogniz- are part of the system, systems can be divided ing that some of the sub-problems produced by into technical computer-based systems and socio- division may be the same and thus avoids solving technical systems. A technical computer-based the same problems again and again. This elimina- system functions without human involvement, tion of redundant subproblems can dramatically such as televisions, mobile phones, thermostat, improve efficiency. and some software; a sociotechnical system The greedy selection strategy further improves will not function without human involvement. on dynamic programming by recognizing that Examples of such system include manned space not all of the sub-problems contribute to the solu- vehicles, chips embedded inside a human, and so tion of the big problem. By eliminating all but forth. one sub-problem, the greedy selection strategy achieves the highest efficiency among all -algo 8.1. Emergent System Properties rithm design strategies. Sometimes the use of randomization can improve on the greedy selec- A system is more than simply the sum of its parts. tion strategy by eliminating the complexity in Thus, the properties of a system are not simply the determining the greedy choice through coin flip- sum of the properties of its components. Instead, ping or randomization. a system often exhibits properties that are properties of the system as a whole. These properties are 7.5. Algorithmic Analysis Strategies called emergent properties because they develop only after the integration of constituent parts in The analysis strategies of algorithms include the system. Emergent system properties can be basic counting analysis, in which one actually either functional or nonfunctional. Functional counts the number of steps an algorithm takes to properties describe the things that a system does. complete its task; asymptotic analysis, in which For example, an aircraft’s functional properties one only considers the order of magnitude of include flotation on air, carrying people or cargo, the number of steps an algorithm takes to com- and use as a weapon of mass destruction. Non- plete its task; probabilistic analysis, in which functional properties describe how the system one makes use of probabilities in analyzing the behaves in its operational environment. These average performance of an algorithm; amor- can include such qualities as consistency, capac- tized analysis, in which one uses the methods of ity, weight, security, etc. 13-12 SWEBOK® Guide V3.0

Figure 13.3. Basic Components of a Computer System Based on the von Neumann Model

8.2. Systems Engineering and electronic components with each component performing a preset function. Jointly, these com- “Systems engineering is the interdisciplinary ponents are able to execute the instructions that approach governing the total technical and mana- are given by the program. gerial effort required to transform a set of cus- Abstractly speaking, a computer receives some tomer needs, expectations, and constraints into input, stores and manipulates some data, and a solution and to support that solution through- provides some output. The most distinct feature out its life.” [7]. The life cycle stages of systems of a computer is its ability to store and execute engineering vary depending on the system being sequences of instructions called programs. An built but, in general, include system requirements interesting phenomenon concerning the computer definition, system design, sub-system develop- is the universal equivalence in functionality. ment, system integration, system testing, sys- According to Turing, all computers with a certain tem installation, system evolution, and system minimum capability are equivalent in their abil- decommissioning. ity to perform computation tasks. In other words, Many practical guidelines have been produced given enough time and memory, all computers— in the past to aid people in performing the activi- ranging from a netbook to a supercomputer—are ties of each phase. For example, system design capable of computing exactly the same things, can be broken into smaller tasks of identification irrespective of speed, size, cost, or anything else. of subsystems, assignment of system require- Most computer systems have a structure that ments to subsystems, specification of subsystem is known as the “von Neumann model,” which functionality, definition of sub-system interfaces, consists of five components: amemory for storing and so forth. instructions and data, a central processing unit for performing arithmetic and logical operations, 8.3. Overview of a Computer System a control unit for sequencing and interpreting instructions, input for getting external informa- Among all the systems, one that is obviously rel- tion into the memory, and output for producing evant to the software engineering community is results for the user. The basic components of a the computer system. A computer is a machine computer system based on the von Neumann that executes programs or software. It consists of model are depicted in Figure 13.3. a purposeful collection of mechanical, electrical, Computing Foundations 13-13

9. Computer Organization the ISA, which specifies such things as the native [8*, c1–c4] data types, instructions, registers, addressing modes, the memory architecture, interrupt and From the perspective of a computer, a wide exception handling, and the I/Os. Overall, the semantic gap exists between its intended behav- ISA specifies the ability of a computer and what ior and the workings of the underlying electronic can be done on the computer with programming. devices that actually do the work within the computer. This gap is bridged through computer orga- 9.2. Digital Systems nization, which meshes various electrical, electronic, and mechanical devices into one device At the lowest level, computations are carried out that forms a computer. The objects that computer by the electrical and electronic devices within a organization deals with are the devices, connec- computer. The computer uses circuits and mem- tions, and controls. The abstraction built in com- ory to hold charges that represents the presence puter organization is the computer. or absence of voltage. The presence of voltage is equal to a 1 while the absence of voltage is a 9.1. Computer Organization Overview zero. On disk the polarity of the voltage is represented by 0s and 1s that in turn represents the data A computer generally consists of a CPU, mem- stored. Everything—including instruction and ory, input devices, and output devices. Abstractly data—is expressed or encoded using digital zeros speaking, the organization of a computer can be and ones. In this sense, a computer becomes a divided into four levels (Figure 13.4). The macro digital system. For example, decimal value 6 can architecture level is the formal specification of all be encoded as 110, the addition instruction may the functions a particular machine can carry out be encoded as 0001, and so forth. The component and is known as the instruction set architecture of the computer such as the control unit, ALU, (ISA). The micro architecture level is the imple- memory and I/O use the information to compute mentation of the ISA in a specific CPU—in other the instructions. words, the way in which the ISA’s specifications are actually carried out. The logic circuits level 9.3. Digital Logic is the level where each functional component of the micro architecture is built up of circuits Obviously, logics are needed to manipulate data that make decisions based on simple rules. The and to control the operation of computers. This devices level is the level where, finally, each logic logic, which is behind a computer’s proper func- circuit is actually built of electronic devices such tion, is called digital logic because it deals with as complementary metal-oxide semiconductors the operations of digital zeros and ones. Digital (CMOS), n-channel metal oxide semiconductors logic specifies the rules both for building various (NMOS), or gallium arsenide (GaAs) transistors, digital devices from the simplest elements (such and so forth. as transistors) and for governing the operation of digital devices. For example, digital logic spells Macro Architecture Level (ISA) out what the value will be if a zero and one is Micro Architecture Level ANDed, ORed, or exclusively ORed together. It also specifies how to build decoders, multiplex- Logic Circuits Level ers (MUX), memory, and adders that are used to Devices Level assemble the computer.

Figure 13.4. Machine Architecture Levels 9.4. Computer Expression of Data

Each level provides an abstraction to the level As mentioned before, a computer expresses data above and is dependent on the level below. To a with electrical signals or digital zeros and ones. programmer, the most important abstraction is Since there are only two different digits used in 13-14 SWEBOK® Guide V3.0

data expression, such a system is called a binary • Memory cells and chips expression system. Due to the inherent nature of • Memory boards and modules a binary system, the maximum numerical value • Memory hierarchy and cache expressible by an n-bits binary code is 2n − 1. • Memory as a subsystem of the computer.

Specifically, binary number anan−1…a1a0 corre- n n−1 1 sponds to an × 2 + an−1 × 2 + … + a1 × 2 + Memory cells and chips deal with single-digital 0 a0 × 2 . Thus, the numerical value of the binary storage and the assembling of single-digit units expression of 1011 is 1 × 8 + 0 × 4 + 1 × 2 + 1 into one-dimensional memory arrays as well × 1 = 11. To express a nonnumerical value, we as the assembling of one-dimensional storage need to decide the number of zeros and ones to arrays into multi-dimensional storage memory use and the order in which those zeros and ones chips. Memory boards and modules concern the are arranged. assembling of memory chips into memory sys- Of course, there are different ways to do the tems, with the focus being on the organization, encoding, and this gives rise to different data operation, and management of the individual expression schemes and subschemes. For example, chips in the system. Memory hierarchy and cache integers can be expressed in the form of unsigned, are used to support efficient memory operations. one’s complement, or two’s complement. For Memory as a sub-system deals with the interface characters, there are ASCII, Unicode, and IBM’s between the memory system and other parts of EBCDIC standards. For floating point numbers, the computer. there are IEEE-754 FP 1, 2, and 3 standards. 9.7. Input and Output (I/O) 9.5. The Central Processing Unit (CPU) A computer is useless without I/O. Common The central processing unit is the place where input devices include the keyboard and mouse; instructions (or programs) are actually executed. common output devices include the disk, the The execution usually takes several steps, includ- screen, the printer, and speakers. Different I/O ing fetching the program instruction, decoding devices operate at different data rates and reli- the instruction, fetching operands, performing abilities. How computers connect and manage arithmetic and logical operations on the oper- various input and output devices to facilitate the ands, and storing the result. The main compo- interaction between computers and humans (or nents of a CPU consist of registers where instruc- other computers) is the focus of topics in I/O. tions and data are often read from and written to, The main issues that must be resolved in input the arithmetic and logic unit (ALU) that performs and output are the ways I/O can and should be the actual arithmetic (such as addition, subtrac- performed. tion, multiplication, and division) and logic (such In general, I/O is performed at both hard- as AND, OR, shift, and so forth) operations, the ware and software levels. Hardware I/O can be control unit that is responsible for producing performed in any of three ways. Dedicated I/O proper signals to control the operations, and vari- dedicates the CPU to the actual input and output ous (data, address, and control) buses that link the operations during I/O; memory-mapped I/O treats components together and transport data to and I/O operations as memory operations; and hybrid from these components. I/O combines dedicated I/O and memory-mapped I/O into a single holistic I/O operation mode. 9.6. Memory System Organization Coincidentally, software I/O can also be performed in one of three ways. Programmed I/O Memory is the storage unit of a computer. It con- lets the CPU wait while the I/O device is doing cerns the assembling of a large-scale memory I/O; interrupt-driven I/O lets the CPU’s handling system from smaller and single-digit storage of I/O be driven by the I/O device; and direct units. The main topics covered by memory sys- memory access (DMA) lets I/O be handled by a tem architecture include the following: secondary CPU embedded in a DMA device (or Computing Foundations 13-15

channel). (Except during the initial setup, the there are some important differences between the main CPU is not disturbed during a DMA I/O two methods. First, a compiler makes the conver- operation.) sion just once, while an interpreter typically con- Regardless of the types of I/O scheme being verts it every time a program is executed. Second, used, the main issues involved in I/O include I/O interpreting code is slower than running the com- addressing (which deals with the issue of how to piled code, because the interpreter must analyze identify the I/O device for a specific I/O opera- each statement in the program when it is executed tion), synchronization (which deals with the issue and then perform the desired action, whereas the of how to make the CPU and I/O device work compiled code just performs the action within in harmony during I/O), and error detection and a fixed context determined by the compilation. correction (which deals with the occurrence of Third, access to variables is also slower in an transmission errors). interpreter because the mapping of identifiers to storage locations must be done repeatedly at run- 10. Compiler Basics time rather than at compile time. [4*, s6.4] [8*, s8.4] The primary tasks of a compiler may include preprocessing, lexical analysis, parsing, semantic 10.1. Compiler/Interpreter Overview analysis, code generation, and code optimization. Program faults caused by incorrect compiler Programmers usually write programs in high behavior can be very difficult to track down. For level language code, which the CPU cannot exe- this reason, compiler implementers invest a lot of cute; so this source code has to be converted into time ensuring the correctness of their software. machine code to be understood by a computer. Due to the differences between different ISAs, 10.3. The Compilation Process the translation must be done for each ISA or specific machine language under consideration. Compilation is a complex task. Most compilers The translation is usually performed by a piece divide the compilation process into many phases. of software called a compiler or an interpreter. A typical breakdown is as follows: This process of translation from a high-level language to a machine language is called compila- • Lexical Analysis tion, or, sometimes, interpretation. • Syntax Analysis or Parsing • Semantic Analysis 10.2. Interpretation and Compilation • Code Generation

There are two ways to translate a program writ- Lexical analysis partitions the input text (the ten in a higher-level language into machine code: source code), which is a sequence of characters, interpretation and compilation. Interpretation into separate comments, which are to be ignored translates the source code one statement at a time in subsequent actions, and basic symbols, which into machine language, executes it on the spot, have lexical meanings. These basic symbols and then goes back for another statement. Both must correspond to some terminal symbols of the high-level-language source code and the inter- the grammar of the particular programming lan- preter are required every time the program is run. guage. Here terminal symbols refer to the ele- Compilation translates the high-level-language mentary symbols (or tokens) in the grammar that source code into an entire machine-language pro- cannot be changed. gram (an executable image) by a program called a Syntax analysis is based on the results of the compiler. After compilation, only the executable lexical analysis and discovers the structure in the image is needed to run the program. Most appli- program and determines whether or not a text cation software is sold in this form. conforms to an expected format. Is this a textu- While both compilation and interpretation con- ally correct C++ program? or Is this entry tex- vert high level language code into machine code, tually correct? are typical questions that can be 13-16 SWEBOK® Guide V3.0

answered by syntax analysis. Syntax analysis 11.1. Operating Systems Overview determines if the source code of a program is correct and converts it into a more structured rep- Operating systems is a collection of software and resentation (parse tree) for semantic analysis or firmware, that controls the execution of computer transformation. programs and provides such services as computer Semantic analysis adds semantic information resource allocation, job control, input/output con- to the parse tree built during the syntax analysis trol, and file management in a computer system. and builds the symbol table. It performs vari- Conceptually, an operating system is a computer ous semantic checks that include type checking, program that manages the hardware resources object binding (associating variable and function and makes it easier to use by applications by pre- references with their definitions), and definite senting nice abstractions. This nice abstraction assignment (requiring all local variables to be is often called the virtual machine and includes initialized before use). If mistakes are found, the such things as processes, virtual memory, and semantically incorrect program statements are file systems. An OS hides the complexity of the rejected and flagged as errors. underlying hardware and is found on all modern Once semantic analysis is complete, the phase computers. of code generation begins and transforms the The principal roles played by OSs are manage- intermediate code produced in the previous ment and illusion. Management refers to the OS’s phases into the native machine language of the management (allocation and recovery) of physi- computer under consideration. This involves cal resources among multiple competing users/ resource and storage decisions—such as deciding applications/tasks. Illusion refers to the nice which variables to fit into registers and memory abstractions the OS provides. and the selection and scheduling of appropriate machine instructions, along with their associated 11.2. Tasks of an Operating System addressing modes. It is often possible to combine multiple phases The tasks of an operating system differ signifi- into one pass over the code in a compiler imple- cantly depending on the machine and time of its mentation. Some compilers also have a prepro- invention. However, modern operating systems cessing phase at the beginning or after the lexical have come to agreement as to the tasks that must analysis that does necessary housekeeping work, be performed by an OS. These tasks include CPU such as processing the program instructions for management, memory management, disk man- the compiler (directives). Some compilers pro- agement (file system), I/O device management, vide an optional optimization phase at the end of and security and protection. Each OS task man- the entire compilation to optimize the code (such ages one type of physical resource. as the rearrangement of instruction sequence) Specifically, CPU management deals with the for efficiency and other desirable objectives allocation and releases of the CPU among com- requested by the users. peting programs (called processes/threads in OS jargon), including the operating system itself. The 11. Operating Systems Basics main abstraction provided by CPU management is [4*, c3] the process/thread model. Memory management deals with the allocation and release of memory Every system of meaningful complexity needs space among competing processes, and the main to be managed. A computer, as a rather complex abstraction provided by memory management electrical-mechanical system, needs its own man- is virtual memory. Disk management deals with ager for managing the resources and activities the sharing of magnetic or optical or solid state occurring on it. That manager is called an operat- disks among multiple programs/users and its main ing system (OS). abstraction is the file system. I/O device management deals with the allocation and releases of various I/O devices among competing processes. Computing Foundations 13-17

Security and protection deal with the protection of • Multiprogrammed batching OS: adds mul- computer resources from illegal use. titask capability into earlier simple batching OSs. An example of such an OS is IBM’s 11.3. Operating System Abstractions OS/360. • Time-sharing OS: adds multi-task and inter- The arsenal of OSs is abstraction. Corresponding active capabilities into the OS. Examples of to the five physical tasks, OSs use five abstrac- such OSs include UNIX, Linux, and NT. tions: process/thread, virtual memory, file sys- • Real-time OS: adds timing predictabil- tems, input/output, and protection domains. The ity into the OS by scheduling individual overall OS abstraction is the virtual machine. tasks according to each task’s completion For each task area of OS, there is both a physi- deadlines. Examples of such OS include cal reality and a conceptual abstraction. The phys- VxWorks (WindRiver) and DART (EMC). ical reality refers to the hardware resource under • Distributed OS: adds the capability of man- management; the conceptual abstraction refers aging a network of computers into the OS. to the interface the OS presents to the users/pro- • Embedded OS: has limited functionality and grams above. For example, in the thread model is used for embedded systems such as cars of the OS, the physical reality is the CPU and the and PDAs. Examples of such OSs include abstraction is multiple CPUs. Thus, a user doesn’t Palm OS, Windows CE, and TOPPER. have to worry about sharing the CPU with others when working on the abstraction provided by an Alternatively, an OS can be classified by its OS. In the virtual memory abstraction of an OS, applicable target machine/environment into the the physical reality is the physical RAM or ROM following. (whatever), the abstraction is multiple unlimited memory space. Thus, a user doesn’t have to • Mainframe OS: runs on the mainframe com- worry about sharing physical memory with others puters and include OS/360, OS/390, AS/400, or about limited physical memory size. MVS, and VM. Abstractions may be virtual or transparent; • Server OS: runs on workstations or servers in this context virtual applies to something that and includes such systems as UNIX, Win- appears to be there, but isn’t (like usable memory dows, Linux, and VMS. beyond physical), whereas transparent applies • Multicomputer OS: runs on multiple com- to something that is there, but appears not to be puters and include such examples as Novell there (like fetching memory contents from disk or Netware. physical memory). • Personal computers OS: runs on personal computers and include such examples as 11.4. Operating Systems Classification DOS, Windows, Mac OS, and Linux. • Mobile device OS: runs on personal devices Different operating systems can have different such as cell phones, IPAD and include such functionality implementation. In the early days examples of iOS, Android, Symbian, etc. of the computer era, operating systems were relatively simple. As time goes on, the complexity 12. Database Basics and Data Management and sophistication of operating systems increases [4*, c9] significantly. From a historical perspective, an operating system can be classified as one of the A database consists of an organized collection of following. data for one or more uses. In a sense, a database is a generalization and expansion of data structures. • Batching OS: organizes and processes work But the difference is that a database is usually in batches. Examples of such OSs include external to individual programs and permanent in IBM’s FMS, IBSYS, and University of existence compared to data structures. Databases Michigan’s UMES. are used when the data volume is large or logical 13-18 SWEBOK® Guide V3.0

relations between data items are important. The 12.3. Database Query Language factors considered in database design include performance, concurrency, integrity, and recovery Users/applications interact with a database from hardware failures. through a database query language, which is a specialized programming language tailored to data- 12.1. Entity and Schema base use. The database model tends to determine the query languages that are available to access The things a database tries to model and store are the database. One commonly used query lan- called entities. Entities can be real-world objects guage for the relational database is the structured such as persons, cars, houses, and so forth, or they query language, more commonly abbreviated as may be abstract concepts such as persons, salary, SQL. A common query language for object data- names, and so forth. An entity can be primitive bases is the object query language (abbreviated as such as a name or composite such as an employee OQL). There are three components of SQL: Data that consists of a name, identification number, Definition Language (DDL), Data Manipulation salary, address, and so forth. Language (DML), and Data Control Language The single most important concept in a database (DCL). An example of an DML query may look is the schema, which is a description of the entire like the following: database structure from which all other database activities are built. A schema defines the relation- SELECT Component_No, Quantity ships between the various entities that compose a FROM COMPONENT database. For example, a schema for a company WHERE Item_No = 100 payroll system would consist of such things as employee ID, name, salary rate, address, and so The above query selects all the Component_No forth. Database software maintains the database and its corresponding quantity from a database according to the schema. table called COMPONENT, where the Item_No Another important concept in database is the equals to 100. database model that describes the type of relationship among various entities. The commonly 12.4. Tasks of DBMS Packages used models include relational, network, and object models. A DBMS system provides the following capabilities: 12.2. Database Management Systems (DBMS) • Database development is used to define and Database Management System (DBMS) compo- organize the content, relationships, and struc- nents include database applications for the stor- ture of the data needed to build a database. age of structured and unstructured data and the • Database interrogation is used for accessing required database management functions needed the data in a database for information retrieval to view, collect, store, and retrieve data from the and report generation. End users can selec- databases. A DBMS controls the creation, main- tively retrieve and display information and tenance, and use of the database and is usually produce printed reports. This is the operation categorized according to the database model it that most users know about databases. supports—such as the relational, network, or • Database Maintenance is used to add, delete, object model. For example, a relational database update, and correct the data in a database. management system (RDBMS) implements fea- • Application Development is used to develop tures of the relational model. An object database prototypes of data entry screens, queries, management system (ODBMS) implements fea- forms, reports, tables, and labels for a proto- tures of the object model. typed application. It also refers to the use of 4th Generation Language or application generators to develop or generate program code. Computing Foundations 13-19

12.5. Data Management provided by computer networks. These paradigms include distributed computing, grid computing, A database must manage the data stored in it. Internet computing, and cloud computing. This management includes both organization and storage. 13.1. Types of Network The organization of the actual data in a database depends on the database model. In a relational Computer networks are not all the same and model, data are organized as tables with different may be classified according to a wide variety of tables representing different entities or relations characteristics, including the network’s connec- among a set of entities. The storage of data deals tion method, wired technologies, wireless tech- with the storage of these database tables on disks. nologies, scale, network topology, functions, and The common ways for achieving this is to use files. speed. But the classification that is familiar to Sequential, indexed, and hash files are all used in most is based on the scale of networking. this purpose with different file structures providing different access performance and convenience. • Personal Area Network/Home Network is a computer network used for communication 12.6. Data Mining among computer(s) and different information technological devices close to one per- One often has to know what to look for before son. The devices connected to such a net- querying a database. This type of “pinpointing” work may include PCs, faxes, PDAs, and access does not make full use of the vast amount TVs. This is the base on which the Internet of information stored in the database, and in fact of Things is built. reduces the database into a collection of discrete • Local Area Network (LAN) connects com- records. To take full advantage of a database, one puters and devices in a limited geographical can perform statistical analysis and pattern dis- area, such as a school campus, computer lab- covery on the content of a database using a tech- oratory, office building, or closely positioned nique called data mining. Such operations can be group of buildings. used to support a number of business activities • Campus Network is a computer network made that include, but are not limited to, marketing, up of an interconnection of local area networks fraud detection, and trend analysis. (LANs) within a limited geographical area. Numerous ways for performing data mining • Wide area network (WAN) is a computer have been invented in the past decade and include network that covers a large geographic area, such common techniques as class description, such as a city or country or even across inter- class discrimination, cluster analysis, association continental distances. A WAN limited to a analysis, and outlier analysis. city is sometimes called a Metropolitan Area Network. 13. Network Communication Basics • Internet is the global network that connects [8*, c12] computers located in many (perhaps all) countries. A computer network connects a collection of computers and allows users of different comput- Other classifications may divide networks into ers to share resources with other users. A network control networks, storage networks, virtual pri- facilitates the communications between all the vate networks (VPN), wireless networks, point- connected computers and may give the illusion to-point networks, and Internet of Things. of a single, omnipresent computer. Every computer or device connected to a network is called 13.2. Basic Network Components a network node. A number of computing paradigms have emerged All networks are made up of the same basic hard- to benefit from the functions and capabilities ware components, including computers, network 13-20 SWEBOK® Guide V3.0

interface cards (NICs), bridges, hubs, switches, link layer protocols include frame-relay, asyn- and routers. All these components are called nodes chronous transfer mode (ATM), and Point-to- in the jargon of networking. Each component per- Point Protocol (PPP). Application layer protocols forms a distinctive function that is essential for include Fibre channel, Small Computer System the packaging, connection, transmission, amplifi- Interface (SCSI), and Bluetooth. For each layer cation, controlling, unpacking, and interpretation or even each individual protocol, there may be of the data. For example, a repeater amplifies the standards established by national or international signals, a switch performs many-to-many connec- organizations to guide the design and develop- tions, a hub performs one-to-many connections, ment of the corresponding protocols. an interface card is attached to the computer and performs data packing and transmission, a bridge Application Layer connects one network with another, and a router is Presentation Layer a computer itself and performs data analysis and Session Layer flow control to regulate the data from the network. The functions performed by various network Transport Layer components correspond to the functions specified Network Layer by one or more levels of the seven-layer Open Data link Layer Systems Interconnect (OSI) networking model, Physical Layer which is discussed below.

13.3. Networking Protocols and Standards Figure 13.5. The Seven-Layer OSI Networking Model

Computers communicate with each other using protocols, which specify the format and regula- 13.4. The Internet tions used to pack and un-pack data. To facilitate easier communication and better structure, net- The Internet is a global system of interconnected work protocols are divided into different layers governmental, academic, corporate, public, and with each layer dealing with one aspect of the private computer networks. In the public domain communication. For example, the physical lay- access to the internet is through organizations ers deal with the physical connection between known as internet service providers (ISP). The the parties that are to communicate, the data link ISP maintains one or more switching centers layer deals with the raw data transmission and called a point of presence, which actually con- flow control, and the network layer deals with the nects the users to the Internet. packing and un-packing of data into a particular format that is understandable by the relevant par- 13.5. Internet of Things ties. The most commonly used OSI networking model organizes network protocols into seven The Internet of Things refers to the networking layers, as depicted in Figure 13.5. of everyday objects—such as cars, cell phones, One thing to note is that not all network proto- PDAs, TVs, refrigerators, and even buildings— cols implement all layers of the OSI model. For using wired or wireless networking technologies. example, the TCP/IP protocol implements neither The function and purpose of Internet of Things the presentation layer nor the session layer. is to interconnect all things to facilitate autono- There can be more than one protocol for each mous and better living. Technologies used in the layer. For example, UDP and TCP both work on Internet of Things include RFID, wireless and the transport layer above IP’s network layer, pro- wired networking, sensor technology, and much viding best-effort, unreliable transport (UDP) vs. software of course. As the paradigm of Internet reliable transport function (TCP). Physical layer of Things is still taking shape, much work is protocols include token ring, Ethernet, fast Ether- needed for Internet of Things to gain wide spread net, gigabit Ethernet, and wireless Ethernet. Data acceptance. Computing Foundations 13-21

13.6. Virtual Private Network (VPN) Fundamentally, distributed computing is another form of parallel computing, albeit on a A virtual private network is a preplanned virtual grander scale. In distributed computing, the func- connection between nodes in a LAN/WAN or on tional units are not ALU, FPU, or separate cores, the internet. It allows the network administrator but individual computers. For this reason, some to separate network traffic into user groups that people regard distributed computing as being the have a common affinity for each other such as same as parallel computing. Because both distrib- all users in the same organization, or workgroup. uted and parallel computing involve some form This circuit type may improve performance of concurrency, they are both also called concur- and security between nodes and allows for eas- rent computing. ier maintenance of circuits when troubleshooting. 14.2. Difference between Parallel and Distrib- 14. Parallel and Distributed Computing uted Computing [8*, c9] Though parallel and distributed computing resem- Parallel computing is a computing paradigm that ble each other on the surface, there is a subtle but emerges with the development of multi-func- real distinction between them: parallel comput- tional units within a computer. The main objec- ing does not necessarily refer to the execution of tive of parallel computing is to execute several programs on different computers— instead, they tasks simultaneously on different functional units can be run on different processors within a single and thus improve throughput or response or both. computer. In fact, consensus among computing Distributed computing, on the other hand, is a professionals limits the scope of parallel comput- computing paradigm that emerges with the devel- ing to the case where a shared memory is used by opment of computer networks. Its main objective all processors involved in the computing, while is to either make use of multiple computers in the distributed computing refers to computations network to accomplish things otherwise not pos- where private memory exists for each processor sible within a single computer or improve com- involved in the computations. putation efficiency by harnessing the power of Another subtle difference between parallel and multiple computers. distributed computing is that parallel computing necessitates concurrent execution of several tasks 14.1. Parallel and Distributed Computing while distributed computing does not have this Overview necessity. Based on the above discussion, it is possible Traditionally, parallel computing investigates to classify concurrent systems as being “parallel” ways to maximize concurrency (the simultaneous or “distributed” based on the existence or nonex- execution of multiple tasks) within the bound- istence of shared memory among all the proces- ary of a computer. Distributed computing studies sor: parallel computing deals with computations distributed systems, which consists of multiple within a single computer; distributed computing autonomous computers that communicate through deals with computations within a set of comput- a computer network. Alternatively, distributed ers. According to this view, multicore computing computing can also refer to the use of distributed is a form of parallel computing. systems to solve computational or transactional problems. In the former definition, distributed 14.3. Parallel and Distributed Computing computing investigates the protocols, mecha- Models nisms, and strategies that provide the foundation for distributed computation; in the latter definition, Since multiple computers/processors/cores are distributed computing studies the ways of dividing involved in distributed/parallel computing, some a problem into many tasks and assigning such tasks coordination among the involved parties is nec- to various computers involved in the computation. essary to ensure correct behavior of the system. 13-22 SWEBOK® Guide V3.0

Different ways of coordination give rise to differ- 15. Basic User Human Factors ent computing models. The most common mod- [3*, c8] [9*, c5] els in this regard are the shared memory (parallel) model and the message-passing (distributed) Software is developed to meet human desires or model. needs. Thus, all software design and develop- In a shared memory (parallel) model, all comment must take into consideration human-user puters have access to a shared central memory factors such as how people use software, how where local caches are used to speed up the people view software, and what humans expect processing power. These caches use a protocol from software. There are numerous factors in the to insure the localized data is fresh and up to human-machine interaction, and ISO 9241 docu- date, typically the MESI protocol. The algorithm ment series define all the detailed standards of designer chooses the program for execution by such interactions.[10] But the basic human-user each computer. Access to the central memory can factors considered here include input/output, the be synchronous or asynchronous, and must be handling of error messages, and the robustness of coordinated such that coherency is maintained. the software in general. Different access models have been invented for such a purpose. 15.1. Input and Output In a message-passing (distributed) model, all computers run some programs that collectively Input and output are the interfaces between users achieve some purpose. The system must work and software. Software is useless without input correctly regardless of the structure of the net- and output. Humans design software to process work. This model can be further classified into some input and produce desirable output. All client-server (C/S), browser-server (B/S), and software engineers must consider input and out- n-tier models. In the C/S model, the server pro- put as an integral part of the software product vides services and the client requests services they engineer or develop. Issues considered for from the server. In the B/S model, the server pro- input include (but are not limited to): vides services and the client is the browser. In the n-tier model, each tier (i.e. layer) provides ser- • What input is required? vices to the tier immediately above it and requests • How is the input passed from users to services from the tier immediately below it. In computers? fact, the n-tier model can be seen as a chain of • What is the most convenient way for users to client-server models. Often, the tiers between the enter input? bottommost tier and the topmost tier are called • What format does the computer require of middleware, which is a distinct subject of study the input data? in its own right. The designer should request the minimum 14.4. Main Issues in Distributed Computing data from human input, only when the data is not already stored in the system. The designer should Coordination among all the components in a dis- format and edit the data at the time of entry to tributed computing environment is often complex reduce errors arising from incorrect or malicious and time-consuming. As the number of cores/ data entry. CPUs/computers increases, the complexity of For output, we need to consider what the users distributed computing also increases. Among wish to see: the many issues faced, memory coherency and consensus among all computers are the most dif- • In what format would users like to see ficult ones. Many computation paradigms have output? been invented to solve these problems and are • What is the most pleasing way to display the main discussion issues in distributed/parallel output? computing. Computing Foundations 13-23

If the party interacting with the software isn’t 15.3. Software Robustness human but another software or computer or control system, then we need to consider the input/ Software robustness refers to the ability of soft- output type and format that the software should ware to tolerate erroneous inputs. Software is said produce to ensure proper data exchange between to be robust if it continues to function even when systems. erroneous inputs are given. Thus, it is unaccept- There are many rules of thumb for developers able for software to simply crash when encoun- to follow to produce good input/output for a soft- tering an input problem as this may cause unex- ware. These rules of thumb include simple and pected consequences, such as the loss of valuable natural dialogue, speaking users’ language, mini- data. Software that exhibits such behavior is con- mizing user memory load, consistency, minimal sidered to lack robustness. surprise, conformance to standards (whether Nielsen gives a simpler description of software agreed to or not: e.g., automobiles have a stan- robustness: “The software should have a low dard interface for accelerator, brake, steering). error rate, so that users make few errors during the use of the system and so that if they do make 15.2. Error Messages errors they can easily recover from them. Further, catastrophic errors must not occur” [9*]. It is understandable that most software con- There are many ways to evaluate the robust- tains faults and fails from time to time. But ness of software and just as many ways to make users should be notified if there is anything that software more robust. For example, to improve impedes the smooth execution of the program. robustness, one should always check the validity Nothing is more frustrating than an unexpected of the inputs and return values before progress- termination or behavioral deviation of software ing further; one should always throw an excep- without any warning or explanation. To be user tion when something unexpected occurs, and friendly, the software should report all error con- one should never quit a program without first ditions to the users or upper-level applications giving users/applications a chance to correct the so that some measure can be taken to rectify the condition. situation or to exit gracefully. There are several guidelines that define what constitutes a good 16. Basic Developer Human Factors error message: error messages should be clear, to [3*, c31–32] the point, and timely. First, error messages should clearly explain Developer human factors refer to the consider- what is happening so that users know what is ations of human factors taken when developing going on in the software. Second, error mes- software. Software is developed by humans, read sages should pinpoint the cause of the error, if at by humans, and maintained by humans. If any- all possible, so that proper actions can be taken. thing is wrong, humans are responsible for cor- Third, error messages should be displayed right recting those wrongs. Thus, it is essential to write when the error condition occurs. According to software in a way that is easily understandable Jakob Nielsen, “Good error messages should be by humans or, at the very least, by other software expressed in plain language (no codes), precisely developers. A program that is easy to read and indicate the problem, and constructively suggest understand exhibits readability. a solution” [9*]. Fourth, error messages should The means to ensure that software meet this not overload the users with too much informa- objective are numerous and range from proper tion and cause them to ignore the messages all architecture at the macro level to the particular together. coding style and variable usage at the micro level. However, messages relating to security access But the two prominent factors are structure (or errors should not provide extra information that program layouts) and comments (documentation). would help unauthorized persons break in. 13-24 SWEBOK® Guide V3.0

16.1. Structure • Within a function, comments should be given for each logical section of coding to Well-structured programs are easier to understand explain the meaning and purpose (intention) and modify. If a program is poorly structured, then of the section. no amount of explanation or comments is sufficient • Comments should stipulate what freedom to make it understandable. The ways to organize a does (or does not) the maintaining program- program are numerous and range from the proper mers have with respect to making changes to use of white space, indentation, and parentheses to that code. nice arrangements of groupings, blank lines, and • Comments are seldom required for indi- braces. Whatever style one chooses, it should be vidual statements. If a statement needs com- consistent across the entire program. ments, one should reconsider the statement.

16.2. Comments 17. Secure Software Development and To most people, programming is coding. These Maintenance people do not realize that programming also [11*, c29] includes writing comments and that comments are an integral part of programming. True, comments Due to increasing malicious activities targeted are not used by the computer and certainly do not at computer systems, security has become a sig- constitute final instructions for the computer, but nificant issue in the development of software. In they improve the readability of the programs by addition to the usual correctness and reliability, explaining the meaning and logic of the statements software developers must also pay attention to or sections of code. It should be remembered that the security of the software they develop. Secure programs are not only meant for computers, they software development builds security in software are also read, written, and modified by humans. by following a set of established and/or recom- The types of comments include repeat of the mended rules and practices in software develop- code, explanation of the code, marker of the ment. Secure software maintenance complements code, summary of the code, description of the secure software development by ensuring the no code’s intent, and information that cannot possi- security problems are introduced during software bly be expressed by the code itself. Some com- maintenance. ments are good, some are not. The good ones A generally accepted view concerning software are those that explain the intent of the code and security is that it is much better to design security justify why this code looks the way it does. The into software than to patch it in after software is bad ones are repeat of the code and stating irrel- developed. To design security into software, one evant information. The best comments are self- must take into consideration every stage of the soft- documenting code. If the code is written in such a ware development lifecycle. In particular, secure clear and precise manner that its meaning is self- software development involves software require- proclaimed, then no comment is needed. But this ments security, software design security, software is easier said than done. Most programs are not construction security, and software testing secu- self-explanatory and are often hard to read and rity. In addition, security must also be taken into understand if no comments are given. consideration when performing software mainte- Here are some general guidelines for writing nance as security faults and loopholes can be and good comments: often are introduced during maintenance.

• Comments should be consistent across the 17.1. Software Requirements Security entire program. • Each function should be associated with Software requirements security deals with the comments that explain the purpose of the clarification and specification of security policy function and its role in the overall program. and objectives into software requirements, which Computing Foundations 13-25

lays the foundation for security considerations in • Structure the process so that all sections the software development. Factors to consider requiring extra privileges are modules. The in this phase include software requirements and modules should be as small as possible and threats/risks. The former refers to the specific should perform only those tasks that require functions that are required for the sake of secu- those privileges. rity; the latter refers to the possible ways that the • Ensure that any assumptions in the program security of software is threatened. are validated. If this is not possible, document them for the installers and maintainers 17.2. Software Design Security so they know the assumptions that attackers will try to invalidate. Software Design security deals with the design • Ensure that the program does not share of software modules that fit together to meet objects in memory with any other program. the security objectives specified in the security • The error status of every function must be requirements. This step clarifies the details of checked. Do not try to recover unless neither security considerations and develops the specific the cause of the error nor its effects affect steps for implementation. Factors considered any security considerations. The program may include frameworks and access modes that should restore the state of the software to set up the overall security monitoring/enforce- the state it had before the process began, and ment strategies, as well as the individual policy then terminate. enforcement mechanisms. 17.4. Software Testing Security 17.3. Software Construction Security Software testing security determines that soft- Software construction security concerns the ques- ware protects data and maintains security speci- tion of how to write actual programming code for fication as given. For more information, please specific situations such that security considerations refer to the Software Testing KA. are taken care of. The term “Software Construction Security” could mean different things for different 17.5. Build Security into Software Engineering people. It can mean the way a specific function is Process coded, such that the coding itself is secure, or it can mean the coding of security into software. Software is only as secure as its development Most people entangle the two together without process goes. To ensure the security of software, distinction. One reason for such entanglement is security must be built into the software engineer- that it is not clear how one can make sure that a ing process. One trend that emerges in this regard specific coding is secure. For example, in C pro- is the Secure Development Lifecycle (SDL) con- gramming language, the expression of i<<1 (shift cept, which is a classical spiral model that takes the binary representation of i’s value to the left by a holistic view of security from the perspective one bit) and 2*i (multiply the value of variable i of software lifecycle and ensures that security is by constant 2) mean the same thing semantically, inherent in software design and development, not but do they have the same security ramification? an afterthought later in production. The SDL pro- The answer could be different for different com- cess is claimed to reduce software maintenance binations of ISAs and compilers. Due to this lack costs and increase reliability of software concern- of understanding, software construction secu- ing software security related faults. rity—in its current state of existence—mostly refers to the second aspect mentioned above: the 17.6. Software Security Guidelines coding of security into software. Coding of security into software can be Although there are no bulletproof ways for secure achieved by following recommended rules. A few software development, some general guidelines such rules follow: do exist that can be used to aid such effort. These 13-26 SWEBOK® Guide V3.0

guidelines span every phase of the software 1. Validate input. development lifecycle. Some reputable guide- 2. Heed compiler warnings. lines are published by the Computer Emergency 3. Architect and design for security policies. Response Team (CERT) and below are its top 4. Keep it simple. 10 software security practices (the details can be 5. Default deny. found in [12]: 6. Adhere to the principle of least privilege. 7. Sanitize data sent to other software. 8. Practice defense in depth. 9. Use effective quality assurance techniques. 10. Adopt a software construction security standard. Computing Foundations 13-27

MATRIX OF TOPICS VS. REFERENCE MATERIAL [4*] [6*] [2*] [3*] [5*] [9*] [8*] [11*] Bishop 2002 Voland 2003 Voland Nielsen 1993 McConnell 2004 Brookshear 2008 Sommerville 2011 Horowitz et al. 2007 Null and Lobur 2006

1. Problem Solving s3.2, Techniques s4.2 1.1. Definition of s3.2 Problem Solving 1.2. Formulating the s3.2 Real Problem 1.3. Analyze the s3.2 Problem 1.4. Design a Solution Search s4.2 Strategy 1.5. Problem Solving c5 Using Programs s5.2– 2. Abstraction 5.4 2.1. Levels of s5.2– Abstraction 5.3 2.2. Encapsulation s5.3 2.3. Hierarchy s5.2 3. Programming c6–19 Fundamentals 3.1. The Programming c6–c19 Process 3.2. Programming c6–c19 Paradigms 3.3. Defensive c8 Programming 4. Programming c6 Language Basics 4.1. Programming s6.1 Language Overview 4.2. Syntax and Semantics of s6.2 Programming Language 13-28 SWEBOK® Guide V3.0 [4*] [6*] [2*] [3*] [5*] [9*] [8*] [11*] Bishop 2002 Voland 2003 Voland Nielsen 1993 McConnell 2004 Brookshear 2008 Sommerville 2011 Horowitz et al. 2007 Null and Lobur 2006

4.3. Low Level s6.5– Programming 6.7 Language 4.4. High Level s6.5– Programing 6.7 Language 4.5. Declarative vs. Imperative s6.5– Programming 6.7 Language 5. Debugging Tools c23 and Techniques 5.1. Types of Errors s23.1 5.2. Debugging s23.2 Techniques: 5.3. Debugging s23.5 Tools 6. Data Structure and s2.1– Representation 2.6 6.1. Data Structure s2.1– Overview 2.6 6.2. Types of Data s2.1– Structure 2.6 6.3. Operations on s2.1– Data Structures 2.6 s1.1– 1.3, s3.3– 3.6, s4.1– 4.8, 7. Algorithms and s5.1– Complexity 5.7, s6.1– 6.3, s7.1– 7.6, s11.1, s12.1 Computing Foundations 13-29 [4*] [6*] [2*] [3*] [5*] [9*] [8*] [11*] Bishop 2002 Voland 2003 Voland Nielsen 1993 McConnell 2004 Brookshear 2008 Sommerville 2011 Horowitz et al. 2007 Null and Lobur 2006

7.1. Overview of s1.1–1.2 Algorithms 7.2. Attributes of s1.3 Algorithms 7.3. Algorithmic s1.3 Analysis s3.3– 3.6, s4.1– 4.8, s5.1– 7.4. Algorithmic 5.7, Design Strategies s6.1– 6.3, s7.1– 7.6, s11.1, s12.1 s3.3– 3.6, s4.1– 4.8, s5.1– 7.5. Algorithmic 5.7, Analysis Strategies s6.1– 6.3, s7.1– 7.6, s11.1, s12.1 8. Basic Concept of a c10 System 8.1. Emergent s10.1 System Properties 8.2. System s10.2 Engineering 8.3. Overview of a Computer System 13-30 SWEBOK® Guide V3.0 [4*] [6*] [2*] [3*] [5*] [9*] [8*] [11*] Bishop 2002 Voland 2003 Voland Nielsen 1993 McConnell 2004 Brookshear 2008 Sommerville 2011 Horowitz et al. 2007 Null and Lobur 2006

9. Computer c1–4 Organization 9.1. Computer Organization s1.1–1.2 Overview 9.2. Digital Systems c3 9.3. Digital Logic c3 9.4. Computer c2 Expression of Data 9.5. The Central s4.1– Processing Unit 4.2 (CPU) 9.6. Memory System s4.6 Organization 9.7. Input and Output s4.5 (I/O) 10. Compiler Basics s6.4 s8.4 10.1. Compiler s8.4 Overview 10.2. Interpretation s8.4 and Compilation 10.3. The s6.4 s8.4 Compilation Process 11. Operating c3 Systems Basics 11.1. Operating s3.2 Systems Overview 11.2. Tasks of s3.3 Operating System 11.3. Operating s3.2 System Abstractions 11.4. Operating Systems s3.1 Classification Computing Foundations 13-31 [4*] [6*] [2*] [3*] [5*] [9*] [8*] [11*] Bishop 2002 Voland 2003 Voland Nielsen 1993 McConnell 2004 Brookshear 2008 Sommerville 2011 Horowitz et al. 2007 Null and Lobur 2006

12. Database Basics and Data c9 Management 12.1. Entity and s9.1 Schema 12.2. Database Management s9.1 Systems (DBMS) 12.3. Database s9.2 Query Language 12.4. Tasks of s9.2 DBMS Packages 12.5. Data s9.5 Management 12.6. Data Mining s9.6 13. Network Communication c12 Basics 13.1. Types of s12.2– Network 12.3 13.2. Basic Network s12.6 Components 13.3. Networking s12.4– Protocols and 12.5 Standards 13.4. The Internet 13.5. Internet of s12.8 Things 13.6. Virtual Private Network 14. Parallel and Distributed c9 Computing 14.1. Parallel and Distributed s9.4.1– Computing 9.4.3 Overview 13-32 SWEBOK® Guide V3.0 [4*] [6*] [2*] [3*] [5*] [9*] [8*] [11*] Bishop 2002 Voland 2003 Voland Nielsen 1993 McConnell 2004 Brookshear 2008 Sommerville 2011 Horowitz et al. 2007 Null and Lobur 2006

14.2. Differences between Parallel s9.4.4– and Distributed 9.4.5 Computing 14.3. Parallel s9.4.4– and Distributed 9.4.5 Computing Models 14.4. Main Issues in Distributed Computing 15. Basic User c8 c5 Human Factors 15.1. Input and s5.1, Output s5.3 s5.2, 15.2. Error Messages s5.8 15.3. Software s5.5– Robustness 5.6 16. Basic Developer c31–32 Human Factors 16.1. Structure c31 16.2. Comments c32 17. Secure Software Development and c29 Maintenance 17.1. Two Aspects of s29.1 Secure Coding 17.2. Coding Security into s29.4 Software 17.3. Requirement s29.2 Security 17.4. Design s29.3 Security 17.5. Implementation s29.5 Security Computing Foundations 13-33

REFERENCES [1] Joint Task Force on Computing Curricula, [7] ISO/IEC/IEEE 24765:2010 Systems and IEEE Computer Society and Association Software Engineering—Vocabulary, ISO/ for Computing Machinery, Software IEC/IEEE, 2010. Engineering 2004: Curriculum Guidelines for Undergraduate Degree Programs in [8*] L. Null and J. Lobur, The Essentials of Software Engineering, 2004; http://sites. Computer Organization and Architecture, computer.org/ccse/SE2004Volume.pdf. 2nd ed., Jones and Bartlett Publishers, 2006. [2*] G. Voland, Engineering by Design, 2nd ed., Prentice Hall, 2003. [9*] J. Nielsen, Usability Engineering, Morgan Kaufmann, 1993. [3*] S. McConnell, Code Complete, 2nd ed., Microsoft Press, 2004. [10] ISO 9241-420:2011 Ergonomics of Human- System Interaction, ISO, 2011. [4*] J.G. Brookshear, Computer Science: An Overview, 10th ed., Addison-Wesley, 2008. [11*] M. Bishop, Computer Security: Art and Science, Addison-Wesley, 2002. [5*] E. Horowitz et al., Computer Algorithms, 2nd ed., Silicon Press, 2007. [12] R.C. Seacord, The CERT C Secure Coding Standard, Addison-Wesley Professional, [6*] I. Sommerville, Software Engineering, 9th 2008. ed., Addison-Wesley, 2011. CHAPTER 14

MATHEMATICAL FOUNDATIONS

INTRODUCTION short, you can write a program for a problem only if it follows some logic. The objective of this KA Software professionals live with programs. In a is to help you develop the skill to identify and very simple language, one can program only for describe such logic. The emphasis is on helping something that follows a well-understood, non- you understand the basic concepts rather than on ambiguous logic. The Mathematical Foundations challenging your arithmetic abilities. knowledge area (KA) helps software engineers comprehend this logic, which in turn is translated BREAKDOWN OF TOPICS FOR into programming language code. The mathemat- MATHEMATICAL FOUNDATIONS ics that is the primary focus in this KA is quite different from typical arithmetic, where numbers The breakdown of topics for the Mathematical are dealt with and discussed. Logic and reason- Foundations KA is shown in Figure 14.1. ing are the essence of mathematics that a software engineer must address. 1. Set, Relations, Functions Mathematics, in a sense, is the study of formal [1*, c2] systems. The word “formal” is associated with preciseness, so there cannot be any ambiguous or Set. A set is a collection of objects, called elements erroneous interpretation of the fact. Mathemat- of the set. A set can be represented by listing its ics is therefore the study of any and all certain elements between braces, e.g., S = {1, 2, 3}. truths about any concept. This concept can be The symbol ∈ is used to express that an ele- about numbers as well as about symbols, images, ment belongs to a set, or—in other words—is a sounds, video—almost anything. In short, not member of the set. Its negation is represented by only numbers and numeric equations are sub- ∉, e.g., 1 ∈ S, but 4 ∉ S. ject to preciseness. On the contrary, a software In a more compact representation of set using engineer needs to have a precise abstraction on a set builder notation, {x | P(x)} is the set of all x diverse application domain. such that P(x) for any proposition P(x) over any The SWEBOK Guide’s Mathematical Founda- universe of discourse. Examples for some impor- tions KA covers basic techniques to identify a set tant sets include the following: of rules for reasoning in the context of the system under study. Anything that one can deduce fol- N = {0, 1, 2, 3, …} = the set of nonnegative lowing these rules is an absolute certainty within integers. the context of that system. In this KA, techniques Z = {…, −3, −2, −1, 0, 1, 2, 3, …} = the set of that can represent and take forward the reasoning integers. and judgment of a software engineer in a precise (and therefore mathematical) manner are defined Finite and Infinite Set. A set with a finite num- and discussed. The language and methods of logic ber of elements is called a finite set. Conversely, that are discussed here allow us to describe math- any set that does not have a finite number of ele- ematical proofs to infer conclusively the absolute ments in it is an infinite set. The set of all natural truth of certain concepts beyond the numbers. In numbers, for example, is an infinite set.

14-1 14-2 SWEBOK® Guide V3.0

Figure 14.1. Breakdown of Topics for the Mathematical Foundations KA

Cardinality. The cardinality of a finite set S is Empty Set. A set with no elements is called an the number of elements in S. This is represented empty set. An empty set, denoted by ∅, is also |S|, e.g., if S = {1, 2, 3}, then |S| = 3. referred to as a null or void set. Universal Set. In general S = {x ∈ U | p(x)}, Power Set. The set of all subsets of a set X is where U is the universe of discourse in which called the power set of X. It is represented as the predicate P(x) must be interpreted. The “uni- ℘(X). verse of discourse” for a given predicate is often For example, if X = {a, b, c}, then ℘(X) = {∅, referred to as the universal set. Alternately, one {a}, {b}, {c}, {a, b}, {a, c}, {b, c}, {a, b, c}}. If may define universal set as the set of all elements. |X| = n, then |℘(X)| = 2n. Set Equality. Two sets are equal if and only if Venn Diagrams. Venn diagrams are graphic rep- they have the same elements, i.e.: resentations of sets as enclosed areas in the plane. For example, in Figure 14.2, the rectangle rep- X = Y ≡ ∀p (p ∈ X ↔ p ∈ Y). resents the universal set and the shaded region represents a set X. Subset. X is a subset of set Y, or X is contained in Y, if all elements of X are included in Y. This is denoted by X ⊆ Y. In other words, X ⊆ Y if and only if ∀p (p ∈ X → p ∈ Y). For example, if X = {1, 2, 3} and Y = {1, 2, 3, 4, 5}, then X ⊆ Y. If X is not a subset of Y, it is denoted as X Y. Proper Subset. X is a proper subset of Y (denoted by X ⊂ Y) if X is a subset of Y but not equal to Y, i.e., there is some element in Y that is not in X. In other words, X ⊂ Y if (X ⊆ Y) ∧ (X ≠ Y). Figure 14.2. Venn Diagram for Set X For example, if X = {1, 2, 3}, Y = {1, 2, 3, 4}, and Z = {1, 2, 3}, then X ⊂ Y, but X is not a proper subset of Z. Sets X and Z are equal sets. 1.1. Set Operations If X is not a proper subset of Y, it is denoted as X ⊄ Y. Intersection. The intersection of two sets X and Y, denoted by X ∩ Y, is the set of common ele- Superset. If X is a subset of Y, then Y is called ments in both X and Y. a superset of X. This is denoted by Y ⊇ X, i.e., Y In other words, X ∩ Y = {p | (p ∈ X) ∧ (p ∈ Y)}. ⊇ X if and only if X ⊆ Y. As, for example, {1, 2, 3} ∩ {3, 4, 6} = {3} For example, if X = {1, 2, 3} and Y = {1, 2, 3, If X ∩ Y = f, then the two sets X and Y are said 4, 5}, then Y ⊇ X. to be a disjoint pair of sets. Mathematical Foundations 14-3

A Venn diagram for set intersection is shown in The shaded portion of the Venn diagram in Fig- Figure 14.3. The common portion of the two sets ure 14.5 represents the complement set of X. represents the set intersection. Set Difference or Relative Complement. The set of elements that belong to set X but not to set Y builds the set difference of Y from X. This is represented by X − Y. In other words, X − Y = {p | (p ∈ X) ∧ (p ∉ Y)}. As, for example, {1, 2, 3} − {3, 4, 6} = {1, 2}. It may be proved that X − Y = X ∩ Y’. Set difference X – Y is illustrated by the shaded region in Figure 14.6 using a Venn diagram. Figure 14.3. Intersection of Sets X and Y

Union. The union of two sets X and Y, denoted by X ∪ Y, is the set of all elements either in X, or in Y, or in both. In other words, X ∪ Y = {p | (p ∈ X) ∨ (p ∈ Y)}. As, for example, {1, 2, 3} ∪ {3, 4, 6} = {1, 2, 3, 4, 6}.

Figure 14.6. Venn Diagram for X − Y

Cartesian Product. An ordinary pair {p, q} is Figure 14.4. Union of Sets X and Y a set with two elements. In a set, the order of the elements is irrelevant, so {p, q} = {q, p}. It may be noted that |X ∪ Y| = |X| + |Y| − |X In an ordered pair (p, q), the order of occur- ∩ Y|. rences of the elements is relevant. Thus, (p, q) ≠ A Venn diagram illustrating the union of two (q, p) unless p = q. In general (p, q) = (s, t) if and sets is represented by the shaded region in Figure only if p = s and q = t. 14.4. Given two sets X and Y, their Cartesian product Complement. The set of elements in the univer- X × Y is the set of all ordered pairs (p, q) such that sal set that do not belong to a given set X is called p ∈ X and q ∈ Y. its complement set X'. In other words, X × Y = {(p, q) | (p ∈ X) ∧ (q In other words, X' ={p | (p ∈ U) ∧ (p ∉ X)}. ∈ Y)}. As for example, {a, b} × {1, 2} = {(a, 1), (a, 2), (b, 1), (b, 2)}

1.2. Properties of Set

Some of the important properties and laws of sets are mentioned below.

1. Associative Laws: X ∪ (Y ∪ Z) = (X ∪ Y) ∪ Z Figure 14.5. Venn Diagram for Complement Set of X X ∩ (Y ∩ Z) = (X ∩ Y) ∩ Z 14-4 SWEBOK® Guide V3.0

2. Commutative Laws: this becomes a well-behaved relation and hence a X ∪ Y = Y ∪ X X ∩ Y = Y ∩ X function. This means that, while all functions are relations, not all relations are functions. In case 3. Distributive Laws: of a function given an x, one gets one and exactly X ∪ (Y ∩ Z) = (X ∪ Y) ∩ (X ∪ Z) one y for each ordered pair (x, y). X ∩ (Y ∪ Z) = (X ∩ Y) ∪ (X ∩ Z) For example, let’s consider the following two relations. 4. Identity Laws: X ∪ ∅ = X X ∩ U = X A: {(3, –9), (5, 8), (7, –6), (3, 9), (6, 3)}. B: {(5, 8), (7, 8), (3, 8), (6, 8)}. 5. Complement Laws: X ∪ X' = U X ∩ X' = ∅ Are these functions as well? In case of relation A, the domain is all the 6. Idempotent Laws: x-values, i.e., {3, 5, 6, 7}, and the range is all the X ∪ X = X X ∩ X = X y-values, i.e., {–9, –6, 3, 8, 9}. Relation A is not a function, as there are two 7. Bound Laws: different range values, –9 and 9, for the same X ∪ U = U X ∩ ∅ = ∅ x-value of 3. In case of relation B, the domain is same as that 8. Absorption Laws: for A, i.e., {3, 5, 6, 7}. However, the range is a X ∪ (X ∩ Y) = X X ∩ (X ∪ Y) = X single element {8}. This qualifies as an example of a function even if all the x-values are mapped 9. De Morgan’s Laws: to the same y-value. Here, each x-value is distinct (X ∪ Y)' = X' ∩ Y' (X ∩ Y)' = X' ∪ Y' and hence the function is well behaved. Relation B may be represented by the equation y = 8. 1.3. Relation and Function The characteristic of a function may be verified using a vertical line test, which is stated below: A relation is an association between two sets of Given the graph of a relation, if one can draw information. For example, let’s consider a set a vertical line that crosses the graph in more than of residents of a city and their phone numbers. one place, then the relation is not a function. The pairing of names with corresponding phone numbers is a relation. This pairing is ordered for the entire relation. In the example being considered, for each pair, either the name comes first followed by the phone number or the reverse. The set from which the first element is drawn is called the domain set and the other set is called the range set. The domain is what you start with and the range is what you end up with. A function is a well-behaved relation. A relation R(X, Y) is well behaved if the function maps Figure 14.7. Vertical Line Test for Function every element of the domain set X to a single element of the range set Y. Let’s consider domain set In this example, both lines L1 and L2 cut the X as a set of persons and let range set Y store their graph for the relation thrice. This signifies that phone numbers. Assuming that a person may have for the same x-value, there are three different more than one phone number, the relation being y-values for each of case. Thus, the relation is not considered is not a function. However, if we draw a function. a relation between names of residents and their date of births with the name set as domain, then Mathematical Foundations 14-5

2. Basic Logic Idempotent laws: [1*, c1] p ∨ p ≡ p p ∧ p ≡ p

2.1. Propositional Logic Double negation law: ¬ (¬ p) ≡ p A proposition is a statement that is either true or false, but not both. Let’s consider declarative Commutative laws: sentences for which it is meaningful to assign p ∨ q ≡ q ∨ p p ∧ q ≡ q ∧ p either of the two status values: true or false. Some examples of propositions are given below. Associative laws: (p ∨ q) ∨ r ≡ p ∨ (q ∨ r) 1. The sun is a star (p ∧ q) ∧ r ≡ p ∧ (q ∧ r) 2. Elephants are mammals. 3. 2 + 3 = 5. Distributive laws: p ∨ (q ∧ r) ≡ (p ∨ q) ∧ (p ∨ r) However, a + 3 = b is not a proposition, as it is p ∧ (q ∨ r) ≡ (p ∧ q) ∨ (p ∧ r) neither true nor false. It depends on the values of the variables a and b. De Morgan’s laws: The Law of Excluded Middle: For every propo- ¬ (p ∧ q) ≡ ¬ p ∨ ¬ q ¬ (p ∨ q) ≡ ¬ p ∧ ¬ q sition p, either p is true or p is false. The Law of Contradiction: For every proposi- 2.2. Predicate Logic tion p, it is not the case that p is both true and false. Propositional logic is the area of logic that A predicate is a verb phrase template that deals with propositions. A truth table displays describes a property of objects or a relationship the relationships between the truth values of among objects represented by the variables. For propositions. example, in the sentence, The flower is red, the A Boolean variable is one whose value is either template is red is a predicate. It describes the true or false. Computer bit operations correspond property of a flower. The same predicate may be to logical operations of Boolean variables. used in other sentences too. The basic logical operators including negation Predicates are often given a name, e.g., “Red” (¬ p), conjunction (p ∧ q), disjunction (p ∨ q), or simply “R” can be used to represent the predi- exclusive or (p ⊕ q), and implication (p → q) are cate is red. Assuming R as the name for the predi- to be studied. Compound propositions may be cate is red, sentences that assert an object is of the formed using various logical operators. color red can be represented as R(x), where x rep- A compound proposition that is always true is a resents an arbitrary object. R(x) reads as x is red. tautology. A compound proposition that is always Quantifiers allow statements about entire col- false is a contradiction. A compound proposition lections of objects rather than having to enumer- that is neither a tautology nor a contradiction is a ate the objects by name. contingency. The Universal quantifier ∀x asserts that a sen- Compound propositions that always have the tence is true for all values of variable x. same truth value are called logically equivalent For example, ∀x Tiger(x) → Mammal(x) (denoted by ≡). Some of the common equiva- means all tigers are mammals. lences are: The Existential quantifier ∃x asserts that a sentence is true for at least one value of variable x. Identity laws: For example, ∃x Tiger(x) → Man-eater(x) means p ∧ T ≡ p p ∨ F ≡ p there exists at least one tiger that is a man-eater. Thus, while universal quantification uses Domination laws: implication, the existential quantification natu- p ∨ T ≡ T p ∧ F ≡ F rally uses conjunction. 14-6 SWEBOK® Guide V3.0

A variable x that is introduced into a logical Statements used in a proof include axioms expression by a quantifier is bound to the closest and postulates that are essentially the underlying enclosing quantifier. assumptions about mathematical structures, the A variable is said to be a free variable if it is not hypotheses of the theorem to be proved, and pre- bound to a quantifier. viously proved theorems. Similarly, in a block-structured programming A theorem is a statement that can be shown to language, a variable in a logical expression refers be true. to the closest quantifier within whose scope it A lemma is a simple theorem used in the proof appears. of other theorems. For example, in ∃x (Cat(x) ∧ ∀x (Black(x))), x A corollary is a proposition that can be estab- in Black(x) is universally quantified. The expres- lished directly from a theorem that has been sion implies that cats exist and everything is proved. black. A conjecture is a statement whose truth value Propositional logic falls short in representing is unknown. many assertions that are used in computer sci- When a conjecture’s proof is found, the conjec- ence and mathematics. It also fails to compare ture becomes a theorem. Many times conjectures equivalence and some other types of relationship are shown to be false and, hence, are not theorems. between propositions. For example, the assertion a is greater than 3.1. Methods of Proving Theorems 1 is not a proposition because one cannot infer whether it is true or false without knowing the Direct Proof. Direct proof is a technique to estab- value of a. Thus, propositional logic cannot deal lish that the implication p → q is true by showing with such sentences. However, such assertions that q must be true when p is true. appear quite often in mathematics and we want For example, to show that if n is odd then n2−1 to infer on those assertions. Also, the pattern is even, suppose n is odd, i.e., n = 2k + 1 for some involved in the following two logical equiva- integer k: lences cannot be captured by propositional logic: “Not all men are smokers” and “Some men ∴ n2 = (2k + 1)2 = 4k2 + 4k + 1. don’t smoke.” Each of these two propositions is treated independently in propositional logic. As the first two terms of the Right Hand Side There is no mechanism in propositional logic to (RHS) are even numbers irrespective of the value find out whether or not the two are equivalent to of k, the Left Hand Side (LHS) (i.e., n2) is an odd one another. Hence, in propositional logic, each number. Therefore, n2−1 is even. equivalent proposition is treated individually Proof by Contradiction. A proposition p is true rather than dealing with a general formula that by contradiction if proved based on the truth of covers all equivalences collectively. the implication ¬ p → q where q is a contradiction. Predicate logic is supposed to be a more pow- For example, to show that the sum of 2x + 1 erful logic that addresses these issues. In a sense, and 2y − 1 is even, assume that the sum of 2x + 1 predicate logic (also known as first-order logic and 2y − 1is odd. In other words, 2(x + y), which or predicate calculus) is an extension of propo- is a multiple of 2, is odd. This is a contradiction. sitional logic to formulas involving terms and Hence, the sum of 2x + 1 and 2y − 1 is even. predicates. An inference rule is a pattern establishing that if a set of premises are all true, then it can be 3. Proof Techniques deduced that a certain conclusion statement is [1*, c1] true. The reference rules of addition, simplification, and conjunction need to be studied. A proof is an argument that rigorously establishes Proof by Induction. Proof by induction is done the truth of a statement. Proofs can themselves be in two phases. First, the proposition is estab- represented formally as discrete structures. lished to be true for a base case—typically for the Mathematical Foundations 14-7

positive integer 1. In the second phase, it is estab- n2 ways, and if these tasks cannot be done at the lished that if the proposition holds for an arbitrary same time, then there are n1+ n2 ways to do either positive integer k, then it must also hold for the task. next greater integer, k + 1. In other words, proof by induction is based on the rule of inference that • If A and B are disjoint sets, then |A ∪ B|=|A| tells us that the truth of an infinite sequence of + |B|. propositions P(n), ∀n ∈ [1 … ∞] is established • In general if A1, A2, …. , An are disjoint if P(1) is true, and secondly, ∀k ∈ [2 ... n] if P(k) sets, then |A1 ∪ A2 ∪ … ∪ An| = |A1| + |A2| → P(k + 1). + … + |An|. It may be noted here that, for a proof by mathematical induction, it is not assumed that P(k) is For example, if there are 200 athletes doing true for all positive integers k. Proving a theo- sprint events and 30 athletes who participate in rem or proposition only requires us to establish the long jump event, then how many ways are that if it is assumed P(k) is true for any arbitrary there to pick one athlete who is either a sprinter positive integer k, then P(k + 1) is also true. The or a long jumper? correctness of mathematical induction as a valid Using the sum rule, the answer would be 200 proof technique is beyond discussion of the cur- + 30 = 230. rent text. Let us prove the following proposition The product rule states that if a task t1 can be using induction. done in n1 ways and a second task t2 can be done

Proposition: The sum of the first n positive odd in n2 ways after the first task has been done, then 2 integers P(n) is n . there are n1 * n2 ways to do the procedure. Basis Step: The proposition is true for n = 1 as P(1) = 12 = 1. The basis step is complete. • If A and B are disjoint sets, then |A × B| = Inductive Step: The induction hypothesis (IH) |A| * |B|. is that the proposition is true for n = k, k being an • In general if A1, A2, …, An are disjoint sets, arbitrary positive integer k. then |A1 × A2 × … × An| = |A1| * |A2| * …. * |An|. ∴ 1 + 3 + 5+ … + (2k − 1) = k2 For example, if there are 200 athletes doing Now, it’s to be shown that P(k) → P(k + 1). sprint events and 30 athletes who participate in the long jump event, then how many ways are P(k + 1) = 1 + 3 + 5+ … +(2k − 1) + (2k + 1) there to pick two athletes so that one is a sprinter = P(k) + (2k + 1) and the other is a long jumper? = k2 + (2k + 1) [using IH] Using the product rule, the answer would be = k2 + 2k + 1 200 * 30 = 6000. = (k + 1)2 The principle of inclusion-exclusion states that

if a task t1 can be done in n1 ways and a second

Thus, it is shown that if the proposition is true task t2 can be done in n2 ways at the same time for n = k, then it is also true for n = k + 1. with t1, then to find the total number of ways the The basis step together with the inductive step of two tasks can be done, subtract the number of the proof show that P(1) is true and the conditional ways to do both tasks from n1 + n2. statement P(k) → P(k + 1) is true for all positive integers k. Hence, the proposition is proved. • If A and B are not disjoint, |A ∪ B| = |A| + |B| − |A ∩ B|. 4. Basics of Counting [1*c6] In other words, the principle of inclusion- exclusion aims to ensure that the objects in the

The sum rule states that if a task t1 can be done intersection of two sets are not counted more than in n1 ways and a second task t2 can be done in once. 14-8 SWEBOK® Guide V3.0

Recursion is the general term for the practice 5. Graphs and Trees of defining an object in terms of itself. There are [1*, c10, c11] recursive algorithms, recursively defined functions, relations, sets, etc. 5.1. Graphs A recursive function is a function that calls itself. For example, we define f(n) = 3 * f(n − 1) A graph G = (V, E) where V is the set of vertices for all n ∈ N and n ≠ 0 and f(0) = 5. (nodes) and E is the set of edges. Edges are also An algorithm is recursive if it solves a problem referred to as arcs or links. by reducing it to an instance of the same problem with a smaller input. A phenomenon is said to be random if individual outcomes are uncertain but the long-term pattern of many individual outcomes is predictable. The probability of any outcome for a random phenomenon is the proportion of times the outcome would occur in a very long series of repetitions. The probability P(A) of any event A satisfies 0 ≤ P(A) ≤ 1. Any probability is a number between 0 and 1. If S is the sample space in a probability model, the P(S) = 1. All possible outcomes together must have probability of 1. Figure 14.8. Example of a Graph Two events A and B are disjoint if they have no outcomes in common and so can never occur F is a function that maps the set of edges E to together. If A and B are two disjoint events, P(A a set of ordered or unordered pairs of elements V. or B) = P(A) + P(B). This is known as the addi- For example, in Figure 14.8, G = (V, E) where V tion rule for disjoint events. = {A, B, C}, E = {e1, e2, e3}, and F = {(e1, (A, If two events have no outcomes in common, C)), (e2, (C, B)), (e3, (B, A))}. the probability that one or the other occurs is the The graph in Figure 14.8 is a simple graph that sum of their individual probabilities. consists of a set of vertices or nodes and a set of Permutation is an arrangement of objects in edges connecting unordered pairs. which the order matters without repetition. One The edges in simple graphs are undirected. can choose r objects in a particular order from a Such graphs are also referred to as undirected n n total of n objects by using Pr ways, where, pr = graphs. n n! / (n − r)!. Various notations like Pr and P(n, r) For example, in Figure 14.8, (e1, (A, C)) may are used to represent the number of permutations be replaced by (e1, (C, A)) as the pair between of a set of n objects taken r at a time. vertices A and C is unordered. This holds good Combination is a selection of objects in which for the other two edges too. the order does not matter without repetition. This In a multigraph, more than one edge may con- is different from a permutation because the order nect the same two vertices. Two or more connect- does not matter. If the order is only changed (and ing edges between the same pair of vertices may not the members) then no new combination is reflect multiple associations between the same formed. One can choose r objects in any order two vertices. Such edges are called parallel or n from a total of n objects by using Cr ways, where, multiple edges. n Cr = n! / [r! * (n − r)!]. For example, in Figure 14.9, the edges e3 and e4 are both between A and B. Figure 14.9 is a multigraph where edges e3 and e4 are multiple edges. Mathematical Foundations 14-9

A directed graph G = (V, E) consists of a set of vertices V and a set of edges E that are ordered pairs of elements of V. A directed graph may contain loops. For example, in Figure 14.11, G = (V, E) where V = {A, B, C}, E = {e1, e2, e3}, and F = {(e1, (A, C)), (e2, (B, C)), (e3, (B, A))}.

Figure 14.9. Example of a Multigraph

In a pseudograph, edges connecting a node to itself are allowed. Such edges are called loops.

Figure 14.12. Example of a Weighted Graph

In a weighted graph G = (V, E), each edge has a weight associated with it. The weight of an edge typically represents the numeric value associated with the relationship between the corresponding two vertices. For example, in Figure 14.12, the weights for the edges e1, e2, and e3 are taken to be 76, 93, Figure 14.10. Example of a Pseudograph and 15 respectively. If the vertices A, B, and C represent three cities in a state, the weights, for For example, in Figure 14.10, the edge e4 both example, could be the distances in miles between starts and ends at B. Figure 14.10 is a pseudo- these cities. graph in which e4 is a loop. Let G = (V, E) be an undirected graph with edge set E. Then, for an edge e ∈ E where e = {u, v}, the following terminologies are often used:

• u, v are said to be adjacent or neighbors or connected. • edge e is incident with vertices u and v. • edge e connects u and v. • vertices u and v are endpoints for edge e.

If vertex v ∈ V, the set of vertices in the undirected graph G(V, E), then:

• the degree of v, deg(v), is its number of inci- Figure 14.11. Example of a Directed Graph dent edges, except that any self-loops are counted twice. 14-10 SWEBOK® Guide V3.0

• a vertex with degree 0 is called an isolated vertex. • a vertex of degree 1 is called a pendant vertex.

Let G(V, E) be a directed graph. If e(u, v) is an edge of G, then the following terminologies are often used:

Figure 14.13. Example of Cycles C3 and C4 • u is adjacent to v, and v is adjacent from u. • e comes from u and goes to v. An adjacency list is a table with one row per • e connects u to v, or e goes from u to v. vertex, listing its adjacent vertices. The adjacency • the initial vertex of e is u. listing for a directed graph maintains a listing of • the terminal vertex of e is v. the terminal nodes for each of the vertex in the graph. If vertex v is in the set of vertices for the Adjacency Vertex directed graph G(V, E), then List • in-degree of v, deg−(v), is the number of A B, C edges going to v, i.e., for which v is the terminal vertex. B A, B, C + • out-degree of v, deg (v), is the number of C A, B edges coming from v, i.e., for which v is the initial vertex. Figure 14.14. Adjacency Lists for Graphs in Figures 14.10 • degree of v, deg(v) = deg−(v) + deg+(v), is the and 14.11 sum of vs in-degree and out-degree. • a loop at a vertex contributes 1 to both in- For example, Figure 14.14 illustrates the adja- degree and out-degree of this vertex. cency lists for the pseudograph in Figure 14.10 and the directed graph in Figure 14.11. As the It may be noted that, following the definitions out-degree of vertex C in Figure 14.11 is zero, above, the degree of a node is unchanged whether there is no entry against C in the adjacency list. we consider its edges to be directed or undirected. Different representations for a graph—like In an undirected graph, a path of length n from adjacency matrix, incidence matrix, and adja- u to v is a sequence of n adjacent edges from ver- cency lists—need to be studied. tex u to vertex v. 5.2. Trees • A path is a circuit if u=v. • A path traverses the vertices along it. A tree T(N, E) is a hierarchical data structure of n • A path is simple if it contains no edge more = |N| nodes with a specially designated root node than once. R while the remaining n − 1 nodes form subtrees under the root node R. The number of edges |E| in

A cycle on n vertices Cn for any n ≥ 3 is a sim- a tree would always be equal to |N| − 1. ple graph where V = {v1, v2, …, vn} and E = {{v1, The subtree at node X is the subgraph of the v2}, {v2, v3}, … , {vn−1, vn}, {vn, v1}}. tree consisting of node X and its descendants and For example, Figure 14.13 illustrates two all edges incident to those descendants. As an cycles of length 3 and 4. alternate to this recursive definition, a tree may be defined as a connected undirected graph with no simple circuits. Mathematical Foundations 14-11

at level 0. Alternately, the level of a node X is the length of the unique path from the root of the tree to node X. For example, root node A is at level 0 in Fig- ure 14.15. Nodes B, C, and D are at level 1. The remaining nodes in Figure 14.15 are all at level 2. The height of a tree is the maximum of the levels of nodes in the tree. For example, in Figure 14.15, the height of the tree is 2. A node is called a leaf if it has no children. The degree of a leaf node is 0. Figure 14.15. Example of a Tree For example, in Figure 14.15, nodes E through K are all leaf nodes with degree 0. However, one should remember that a tree is The ancestors or predecessors of a nonroot strictly hierarchical in nature as compared to a node X are all the nodes in the path from root to graph, which is flat. In case of a tree, an ordered node X. pair is built between two nodes as parent and For example, in Figure 14.15, nodes A and D child. Each child node in a tree is associated form the set of ancestors for J. with only one parent node, whereas this restric- The successors or descendents of a node X are tion becomes meaningless for a graph where no all the nodes that have X as its ancestor. For a tree parent-child association exists. with n nodes, all the remaining n − 1 nodes are An undirected graph is a tree if and only if successors of the root node. there is a unique simple path between any two of For example, in Figure 14.15, node B has suc- its vertices. cessors in E, F, and G. Figure 14.15 presents a tree T(N, E) where the If node X is an ancestor of node Y, then node Y set of nodes N = {A, B, C, D, E, F, G, H, I, J, K}. is a successor of X. The edge set E is {(A, B), (A, C), (A, D), (B, E), Two or more nodes sharing the same parent (B, F), (B, G), (C, H), (C, I), (D, J), (D, K)}. node are called sibling nodes. The parent of a nonroot node v is the unique For example, in Figure 14.15, nodes E and G node u with a directed edge from u to v. Each are siblings. However, nodes E and J, though node in the tree has a unique parent node except from the same level, are not sibling nodes. the root of the tree. Two sibling nodes are of the same level, but For example, in Figure 14.15, root node A is two nodes in the same level are not necessarily the parent node for nodes B, C, and D. Similarly, siblings. B is the parent of E, F, G, and so on. The root A tree is called an ordered tree if the rela- node A does not have any parent. tive position of occurrences of children nodes is A node that has children is called an internal significant. node. For example, a family tree is an ordered tree For example, in Figure 14.15, node A or node B if, as a rule, the name of an elder sibling appears are examples of internal nodes. always before (i.e., on the left of) the younger The degree of a node in a tree is the same as its sibling. number of children. In an unordered tree, the relative position of For example, in Figure 14.15, root node A and occurrences between the siblings does not bear its child B are both of degree 3. Nodes C and D any significance and may be altered arbitrarily. have degree 2. A binary tree is formed with zero or more nodes The distance of a node from the root node in where there is a root node R and all the remaining terms of number of hops is called its level. Nodes nodes form a pair of ordered subtrees under the in a tree are at different levels. The root node is root node. 14-12 SWEBOK® Guide V3.0

In a binary tree, no internal node can have more than two children. However, one must consider that besides this criterion in terms of the degree of internal nodes, a binary tree is always ordered. If the positions of the left and right subtrees for any node in the tree are swapped, then a new tree is derived.

Figure 14.18. Example of Complete Binary Trees

Figure 14.16. Examples of Binary Trees Interestingly, following the definitions above, the tree in Figure 14.18(b) is a complete but not For example, in Figure 14.16, the two binary full binary tree as node B has only one child in D. trees are different as the positions of occurrences On the contrary, the tree in Figure 14.17 is a full of the children of A are different in the two trees. —but not complete—binary tree, as the children of B occur in the tree while the children of C do not appear in the last level. A binary tree of height H is balanced if all its leaf nodes occur at levels H or H − 1. For example, all three binary trees in Figures 14.17 and 14.18 are balanced binary trees. There are at most 2H leaves in a binary tree of height H. In other words, if a binary tree with L leaves is full and balanced, then its height is H =

⎡log2L⎤. For example, this statement is true for the two trees in Figures 14.17 and 14.18(a) as both Figure 14.17. Example of a Full Binary Tree trees are full and balanced. However, the expression above does not match for the tree in Figure According to [1*], a binary tree is called a full 14.18(b) as it is not a full binary tree. binary tree if every internal node has exactly two A binary search tree (BST) is a special kind of children. binary tree in which each node contains a distinct For example, the binary tree in Figure 14.17 key value, and the key value of each node in the is a full binary tree, as both of the two internal tree is less than every key value in its right subtree nodes A and B are of degree 2. and greater than every key value in its left subtree. A full binary tree following the definition A traversal algorithm is a procedure for sys- above is also referred to as a strictly binary tree. tematically visiting every node of a binary tree. For example, both binary trees in Figure 14.18 Tree traversals may be defined recursively. are complete binary trees. The tree in Figure If T is binary tree with root R and the remain- 14.18(a) is a complete as well as a full binary ing nodes form an ordered pair of nonnull left tree. A complete binary tree has all its levels, subtree TL and nonnull right subtree TR below R, except possibly the last one, filled up to capacity. then the preorder traversal function PreOrder(T) In case the last level of a complete binary tree is is defined as: not full, nodes occur from the leftmost positions available. PreOrder(T) = R, PreOrder(TL), PreOrder(TR) … eqn. 1 Mathematical Foundations 14-13

The recursive process of finding the preorder randomness has been defined in section 4 of this traversal of the subtrees continues till the sub- KA. Here, let us start with the concepts behind trees are found to be Null. Here, commas have probability distribution and discrete probability. been used as delimiters for the sake of improved A probability model is a mathematical descrip- readability. tion of a random phenomenon consisting of two The postorder and in-order may be similarly parts: a sample space S and a way of assigning defined using eqn. 2 and eqn. 3 respectively. probabilities to events. The sample space defines the set of all possible outcomes, whereas an event

PostOrder(T) = PostOrder(TL), PostOrder(TR), is a subset of a sample space representing a pos- R … eqn 2 sible outcome or a set of outcomes.

InOrder(T) = InOrder(TL), R, InOrder(TR) … A random variable is a function or rule that eqn 3 assigns a number to each outcome. Basically, it is just a symbol that represents the outcome of an experiment. For example, let X be the number of heads when the experiment is flipping a coin n times. Similarly, let S be the speed of a car as registered on a radar detector. The values for a random variable could be discrete or continuous depending on the experiment. A discrete random variable can hold all possible outcomes without missing any, although it might take an infinite amount of time. A continuous random variable is used to measure an uncountable number of values even if an infinite amount of time is given. Figure 14.19. A Binary Search Tree For example, if a random variable X represents an outcome that is a real number between 1 and For example, the tree in Figure 14.19 is a binary 100, then X may have an infinite number of val- search tree (BST). The preorder, postorder, and ues. One can never list all possible outcomes for in-order traversal outputs for the BST are given X even if an infinite amount of time is allowed. below in their respective order. Here, X is a continuous random variable. On the contrary, for the same interval of 1 to 100, Preorder output: 9, 5, 2, 1, 4, 7, 6, 8, 13, 11, another random variable Y can be used to list all 10, 15 the integer values in the range. Here, Y is a dis- Postorder output: 1, 4, 2, 6, 8, 7, 5, 10, 11, 15, crete random variable. 13, 9 An upper-case letter, say X, will represent In-order output: 1, 2, 4, 5, 6, 7, 8, 9, 10, 11, the name of the random variable. Its lower-case 13, 15 counterpart, x, will represent the value of the random variable. Further discussion on trees and their usage has The probability that the random variable X will been included in section 6, Data Structure and Rep- equal x is: resentation, of the Computing Foundations KA. P(X = x) or, more simply, P(x). 6. Discrete Probability [1*, c7] A probability distribution (density) function is a table, formula, or graph that describes the val- Probability is the mathematical description of ues of a random variable and the probability asso- randomness. Basic definition of probability and ciated with these values. 14-14 SWEBOK® Guide V3.0

Probabilities associated with discrete random These numbers indeed aim to derive the aver- variables have the following properties: age value from repeated experiments. This is based on the single most important phenom- i. 0 ≤ P(x) ≤ 1 for all x enon of probability, i.e., the average value from ii. ΣP(x) = 1 repeated experiments is likely to be close to the expected value of one experiment. Moreover, A discrete probability distribution can be repre- the average value is more likely to be closer to sented as a discrete random variable. the expected value of any one experiment as the number of experiments increases. X 1 2 3 4 5 6 7. Finite State Machines P(x) 1/6 1/6 1/6 1/6 1/6 1/6 [1*, c13]

Figure 14.20. A Discrete Probability Function for a Rolling A computer system may be abstracted as a map- Die ping from state to state driven by inputs. In other words, a system may be considered as a transition The mean μ of a probability distribution model function T: S × I → S × O, where S is the set of is the sum of the product terms for individual states and I, O are the input and output functions. events and its outcome probability. In other If the state set S is finite (not infinite), the sys- words, for the possible outcomes x1, x2, … , xn tem is called a finite state machine (FSM). in a sample space S if pk is the probability of out- Alternately, a finite state machine (FSM) is a come xk, the mean of this probability would be μ mathematical abstraction composed of a finite

= x1p1 + x2p2 + … + xnpn. number of states and transitions between those For example, the mean of the probability den- states. If the domain S × I is reasonably small, sity for the distribution in Figure 14.20 would be then one can specify T explicitly using diagrams similar to a flow graph to illustrate the way logic 1 * (1/6) + 2 * (1/6) + 3 * (1/6) + 4 * (1/6) + 5 flows for different inputs. However, this is prac- * (1/6) + 6 * (1/6) tical only for machines that have a very small = 21 * (1/6) = 3.5 information capacity. An FSM has a finite internal memory, an input Here, the sample space refers to the set of all feature that reads symbols in a sequence and one possible outcomes. at a time, and an output feature. The variance s2 of a discrete probability model The operation of an FSM begins from a start 2 2 2 2 is: s = (x1 – μ) p1 + (x2 – μ) p2 + … + (xk – μ) pk. state, goes through transitions depending on input The standard deviations is the square root of the to different states, and can end in any valid state. variance. However, only a few of all the states mark a suc- For example, for the probability distribution in cessful flow of operation. These are called accept Figure 14.20, the variation σ2 would be states. The information capacity of an FSM is s2 = [(1 – 3.5)2 * (1/6) + (2 – 3.5)2 * (1/6) + C = log |S|. Thus, if we represent a machine having (3 – 3.5)2 * (1/6) + (4 – 3.5)2 * (1/6) + (5 – an information capacity of C bits as an FSM, then 3.5)2 * (1/6) + (6 – 3.5)2 * (1/6)] its state transition graph will have |S| = 2C nodes. = (6.25 + 2.25 + 0.25 + 0.5 + 2.25 + 6.25) * A finite state machine is formally defined as M

(1/6) = (S, I, O, f, g, s0). = 17.5 * (1/6) = 2.90 S is the state set; I is the set of input symbols; ∴ standard deviation s = O is the set of output symbols; f is the state transition function; Mathematical Foundations 14-15

g is the output function; The state transition and output values for differ-

and s0 is the initial state. ent inputs on different states may be represented using a state table. The state table for the FSM in

Given an input x ∈ I on state Sk, the FSM Figure 14.21 is shown in Figure 14.22. Each pair makes a transition to state Sh following state tran- against an input symbol represents the new state sition function f and produces an output y ∈ O and the output symbol. using the output function g. For example, Figures 14.22(a) and 14.22(b) are two alternate representations of the FSM in Fig- ure 14.21.

8. Grammars [1*, c13]

The grammar of a natural language tells us whether a combination of words makes a valid sentence. Unlike natural languages, a formal language is specified by a well-defined set of rules for syntaxes. The valid sentences of a formal language can be described by a grammar with the help of these rules, referred to as production rules. Figure 14.21. Example of an FSM A formal language is a set of finite-length words or strings over some finite alphabet, and For example, Figure 14.21 illustrates an FSM a grammar specifies the rules for formation of with S0 as the start state and S1 as the final state. these words or strings. The entire set of words

Here, S = {S0, S1, S2}; I = {0, 1}; O = {2, 3}; f(S0, that are valid for a grammar constitutes the lan-

0) = S2, f(S0, 1) = S1, f(S1, 0) = S2, f(S1, 1) = S2, f(S2, guage for the grammar. Thus, the grammar G is

0) = S2, f(S2, 1) = S0; g(S0, 0) = 3, g(S0, 1) = 2, g(S1, any compact, precise mathematical definition of a

0) = 3, g(S1, 1) = 2, g(S2, 0) = 2, g(S2, 1) = 3. language L as opposed to just a raw listing of all of the language’s legal sentences or examples of Current Input those sentences. State 0 1 A grammar implies an algorithm that would generate all legal sentences of the language. S S S 0 2 1 There are different types of grammars. S1 S2 S2 A phrase-structure or Type-0 grammar G = (V,

S2 S2 S0 T, S, P) is a 4-tuple in which:

(a) • V is the vocabulary, i.e., set of words. • T ⊆ V is a set of words called terminals. • S ∈ N is a special word called the start Output State symbol. Current Input Input • P is the set of productions rules for substitut- State 0 1 0 1 ing one sentence fragment for another. S 3 2 S S 0 2 1 There exists another set N = V − T of words S1 3 2 S2 S2 called nonterminals. The nonterminals represent

S2 2 3 S2 S0 concepts like noun. Production rules are applied on strings containing nonterminals until no more (b) nonterminal symbols are present in the string. The start symbol S is a nonterminal. Figure 14.22. Tabular Representation of an FSM 14-16 SWEBOK® Guide V3.0

The language generated by a formal grammar 3. Every CSG is a phrase-structure grammar G, denoted by L(G), is the set of all strings over (PSG). the set of alphabets V that can be generated, starting with the start symbol, by applying produc- Context-Sensitive Grammar: All fragments in tion rules until all the nonterminal symbols are the RHS are either longer than the corresponding replaced in the string. fragments in the LHS or empty, i.e., if b → a, then For example, let G = ({S, A, a, b}, {a, b}, S, {S |b| < |a| or a = ∅. → aA, S → b, A → aa}). Here, the set of termi- A formal language is context-sensitive if a con- nals are N = {S, A}, where S is the start symbol. text-sensitive grammar generates it. The three production rules for the grammar are Context-Free Grammar: All fragments in the given as P1: S → aA; P2: S → b; P3: A → aa. LHS are of length 1, i.e., if A → a, then |A| = 1 Applying the production rules in all possible for all A ∈ N. ways, the following words may be generated The term context-free derives from the fact that from the start symbol. A can always be replaced by a, regardless of the context in which it occurs. S → aA (using P1 on start symbol) A formal language is context-free if a context- → aaa (using P3) free grammar generates it. Context-free lan- S → b (using P2 on start symbol) guages are the theoretical basis for the syntax of most programming languages. Nothing else can be derived for G. Thus, the Regular Grammar. All fragments in the RHS language of the grammar G consists of only two are either single terminals or a pair built by a words: L(G) = {aaa, b}. terminal and a nonterminal; i.e., if A → a, then either a ∈ T, or a = cD, or a = Dc for c ∈ T, D ∈ N. 8.1. Language Recognition If a = cD, then the grammar is called a right linear grammar. On the other hand, if a = Dc, then Formal grammars can be classified according to the the grammar is called a left linear grammar. Both types of productions that are allowed. The Chom- the right linear and left linear grammars are regu- sky hierarchy (introduced by Noam Chomsky in lar or Type-3 grammar. 1956) describes such a classification scheme. The language L(G) generated by a regular grammar G is called a regular language. A regular expression A is a string (or pattern) formed from the following six pieces of information: a ∈ S, the set of alphabets, e, 0 and the operations, OR (+), PRODUCT (.), CONCATE- NATION (*). The language of G, L(G) is equal to all those strings that match G, L(G) = {x ∈ S*|x matches G}.

For any a ∈ S, L(a) = a; L(e) = {ε}; L(0) = 0. + functions as an or, L(A + B) = L(A) ∪ L(B). Figure 14.23. Chomsky Hierarchy of Grammars . creates a product structure, L(AB) = L(A) . L(B).

As illustrated in Figure 14.23, we infer the fol- * denotes concatenation, L(A*) = {x1x2…xn | lowing on different types of grammars: xi ∈ L(A) and n ³ 0}

1. Every regular grammar is a context-free For example, the regular expression (ab)* grammar (CFG). matches the set of strings: {e, ab, abab, ababab, 2. Every CFG is a context-sensitive grammar abababab, …}. (CSG). Mathematical Foundations 14-17

For example, the regular expression (aa)* or chopping (meaning the exact representative matches the set of strings on one letter a that have immediately below —or above, if negative—the even length. number). For example, the regular expression (aaa)* + Numbers lying beyond the range must be repre- (aaaaa)* matches the set of strings of length equal sented by the largest (or largest negative) number to a multiple of 3 or 5. that can be represented. This becomes a symbol for overflow. Overflow occurs when a computa- 9. Numerical Precision, Accuracy, and Errors tion produces a value larger than the maximum [2*, c2] value in the range. When processing speed is a significant bottle- The main goal of numerical analysis is to neck, the use of the fixed-point representations develop efficient algorithms for computing pre- is an attractive and faster alternative to the more cise numerical values of functions, solutions of cumbersome floating-point arithmetic most com- algebraic and differential equations, optimization monly used in practice. problems, etc. Let’s define a couple of very important terms: A matter of fact is that all digital computers can accuracy and precision as associated with numer- only store finite numbers. In other words, there ical analysis. is no way that a computer can represent an infi- Accuracy is the closeness with which a mea- nitely large number—be it an integer, rational sured or computed value agrees with the true value. number, or any real or all complex numbers (see Precision, on the other hand, is the closeness section 10, Number Theory). So the mathematics with which two or more measured or computed of approximation becomes very critical to handle values for the same physical substance agree with all the numbers in the finite range that a computer each other. In other words, precision is the close- can handle. ness with which a number represents an exact Each number in a computer is assigned a loca- value. tion or word, consisting of a specified number of Let x be a real number and let x* be an approxi- binary digits or bits. A k bit word can store a total mation. The absolute error in the approximation of N = 2k different numbers. x* ≈ x is defined as | x* − x |. The relative error For example, a computer that uses 32 bit arith- is defined as the ratio of the absolute error to the metic can store a total of N = 232 ≈ 4.3 × 109 dif- size of x, i.e., |x* − x| / | x |, which assumes x ¹ 0; ferent numbers, while another one that uses 64 otherwise, relative error is not defined. bits can handle N’ = 264 ≈ 1.84 × 1019 different For example, 1000000 is an approximation to numbers. The question is how to distribute these 1000001 with an absolute error of 1 and a relative N numbers over the real line for maximum effi- error of 10−6, while 10 is an approximation of 11 ciency and accuracy in practical computations. with an absolute error of 1 and a relative error of One evident choice is to distribute them evenly, 0.1. Typically, relative error is more intuitive and leading to fixed-point arithmetic. In this system, the preferred determiner of the size of the error. the first bit in a word is used to represent a sign The present convention is that errors are always and the remaining bits are treated for integer val- ≥ 0, and are = 0 if and only if the approximation ues. This allows representation of the integers is exact. from 1 − ½N, i.e., = 1 − 2k−1 to 1. As an approxi- An approximation x* has k significant deci- mating method, this is not good for noninteger mal digits if its relative error is < 5 × 10−k−1. This numbers. means that the first k digits of x* following its Another option is to space the numbers closely first nonzero digit are the same as those of x. together—say with a uniform gap of 2−n—and so Significant digits are the digits of a number that distribute the total N numbers uniformly over the are known to be correct. In a measurement, one interval −2−n−1N < x ≤ 2−n−1N. Real numbers lying uncertain digit is included. between the gaps are represented by either round- For example, measurement of length with ing (meaning the closest exact representative) a ruler of 15.5 mm with ±0.5 mm maximum 14-18 SWEBOK® Guide V3.0

allowable error has 2 significant digits, whereas decimals either do not exist, e.g., 15, or, when a measurement of the same length using a caliper decimals do exist, they may terminate, as in 15.6, and recorded as 15.47 mm with ±0.01 mm maxi- or they may repeat with a pattern, as in 1.666..., mum allowable error has 3 significant digits. (which is 5/3). Irrational Numbers. These are numbers that 10. Number Theory cannot be expressed as an integer divided by an [1*, c4] integer. These numbers have decimals that never terminate and never repeat with a pattern, e.g., PI Number theory is one of the oldest branches or √2. of pure mathematics and one of the largest. Of Real Numbers. This group is made up of all the course, it concerns questions about numbers, rational and irrational numbers. The numbers that usually meaning whole numbers and fractional or are encountered when studying algebra are real rational numbers. The different types of numbers numbers. The common mathematical symbol for include integer, real number, natural number, the set of all real numbers is R. complex number, rational number, etc. Imaginary Numbers. These are all based on the imaginary number i. This imaginary number is 10.1. Divisibility equal to the square root of −1. Any real number multiple of i is an imaginary number, e.g., i, 5i, Let’s start this section with a brief description of 3.2i, −2.6i, etc. each of the above types of numbers, starting with Complex Numbers. A complex number is a the natural numbers. combination of a real number and an imaginary Natural Numbers. This group of numbers starts number in the form a + bi. The real part is a, and at 1 and continues: 1, 2, 3, 4, 5, and so on. Zero b is called the imaginary part. The common math- is not in this group. There are no negative or frac- ematical symbol for the set of all complex num- tional numbers in the group of natural numbers. bers is C. The common mathematical symbol for the set of For example, 2 + 3i, 3−5i, 7.3 + 0i, and 0 + 5i. all natural numbers is N. Consider the last two examples: Whole Numbers. This group has all of the natu- 7.3 + 0i is the same as the real number 7.3. ral numbers in it plus the number 0. Thus, all real numbers are complex numbers with Unfortunately, not everyone accepts the above zero for the imaginary part. definitions of natural and whole numbers. There Similarly, 0 + 5i is just the imaginary number seems to be no general agreement about whether 5i. Thus, all imaginary numbers are complex to include 0 in the set of natural numbers. numbers with zero for the real part. Many mathematicians consider that, in Europe, Elementary number theory involves divisibility the sequence of natural numbers traditionally among integers. Let a, b ∈ Z with a ≠ 0.The expres- started with 1 (0 was not even considered to be sion a|b, i.e., a divides b if ∃c ∈ Z: b = ac, i.e., there a number by the Greeks). In the 19th century, set is an integer c such that c times a equals b. theoreticians and other mathematicians started For example, 3|−12 is true, but 3|7 is false. the convention of including 0 in the set of natural If a divides b, then we say that a is a factor of numbers. b or a is a divisor of b, and b is a multiple of a. Integers. This group has all the whole numbers b is even if and only if 2|b. in it and their negatives. The common mathemati- Let a, d ∈ Z with d > 1. Then a mod d denotes cal symbol for the set of all integers is Z, i.e., Z = that the remainder r from the division algorithm {…, −3, −2, −1, 0, 1, 2, 3, …}. with dividend a and divisor d, i.e., the remainder Rational Numbers. These are any numbers that when a is divided by d. We can compute (a mod can be expressed as a ratio of two integers. The d) by: a − d * ⎣a/d⎦, where ⎣a/d⎦ represents the common symbol for the set of all rational num- floor of the real number. bers is Q. Let Z+ = {n ∈ Z | n > 0} and a, b ∈ Z, m ∈ Z+, Rational numbers may be classified into then a is congruent to b modulo m, written as a ≡ three types, based on how the decimals act. The b (mod m), if and only if m | a−b. Mathematical Foundations 14-19

Alternately, a is congruent to b modulo m if and 11.1. Group only if (a−b) mod m = 0. A set S closed under a binary operation • forms a 10.2. Prime Number, GCD group if the binary operation satisfies the following four criteria: An integer p > 1 is prime if and only if it is not the product of any two integers greater than 1, • Associative: ∀a, b, c ∈ S, the equation (a • b) i.e., p is prime if p > 1 ∧ ∃ ¬ a, b ∈ N: a > 1, b > • c = a • (b • c) holds. 1, a * b = p. • Identity: There exists an identity element I ∈ The only positive factors of a prime p are 1 S such that for all a ∈ S, I • a = a • I = a. and p itself. For example, the numbers 2, 13, 29, • Inverse: Every element a ∈ S, has an inverse 61, etc. are prime numbers. Nonprime integers a' ∈ S with respect to the binary operation, greater than 1 are called composite numbers. A i.e., a • a' = I; for example, the set of integers composite number may be composed by multi- Z with respect to the addition operation is a plying two integers greater than 1. group. The identity element of the set is 0 for There are many interesting applications of the addition operation. ∀x ∈ Z, the inverse prime numbers; among them are the public- of x would be –x, which is also included in Z. key cryptography scheme, which involves the • Closure property: ∀a, b ∈ S, the result of the exchange of public keys containing the product operation a • b ∈ S. p*q of two random large primes p and q (a private • A group that is commutative, i.e., a • b = b • a, key) that must be kept secret by a given party. is known as a commutative or Abelian group. The greatest common divisor gcd(a, b) of integers a, b is the greatest integer d that is a divisor The set of natural numbers N (with the opera- both of a and of b, i.e., tion of addition) is not a group, since there is no inverse for any x > 0 in the set of natural numbers. d = gcd(a, b) for max(d: d|a ∧ d|b) Thus, the third rule (of inverse) for our operation is violated. However, the set of natural number For example, gcd(24, 36) = 12. has some structure. Integers a and b are called relatively prime or Sets with an associative operation (the first coprime if and only if their GCD is 1. condition above) are called semigroups; if they For example, neither 35 nor 6 are prime, but also have an identity element (the second condi- they are coprime as these two numbers have no tion), then they are called monoids. common factors greater than 1, so their GCD is 1. Our set of natural numbers under addition is

A set of integers X = {i1, i2, …} is relatively then an example of a monoid, a structure that prime if all possible pairs ih, ik, h ≠ k drawn from is not quite a group because it is missing the the set X are relatively prime. requirement that every element have an inverse under the operation. 11. Algebraic Structures A monoid is a set S that is closed under a single associative binary operation • and has an identity This section introduces a few representations element I ∈ S such that for all a ∈ S, I • a = a • I used in higher algebra. An algebraic structure = a. A monoid must contain at least one element. consists of one or two sets closed under some For example, the set of natural numbers N operations and satisfying a number of axioms, forms a commutative monoid under addition with including none. identity element 0. The same set of natural num- For example, group, monoid, ring, and lattice bers N also forms a monoid under multiplication are examples of algebraic structures. Each of with identity element 1. The set of positive inte- these is defined in this section. gers P forms a commutative monoid under multiplication with identity element 1. It may be noted that, unlike those in a group, elements of a monoid need not have inverses. A 14-20 SWEBOK® Guide V3.0

monoid can also be thought of as a semigroup 11.2. Rings with an identity element. A subgroup is a group H contained within a If we take an Abelian group and define a second bigger one, G, such that the identity element of operation on it, a new structure is found that is

G is contained in H, and whenever h1 and h2 are different from just a group. If this second opera- −1. in H, then so are h1 • h2 and h1 Thus, the ele- tion is associative and is distributive over the ments of H, equipped with the group operation on first, then we have a ring. G restricted to H, indeed form a group. A ring is a triple of the form (S, +, •), where (S, Given any subset S of a group G, the subgroup +) is an Abelian group, (S, •) is a semigroup, and generated by S consists of products of elements • is distributive over +; i.e., “ a, b, c ∈ S, the equa- of S and their inverses. It is the smallest subgroup tion a • (b + c) = (a • b) + (a • c) holds. Further, if of G containing S. • is commutative, then the ring is said to be com- For example, let G be the Abelian group whose mutative. If there is an identity element for the • elements are G = {0, 2, 4, 6, 1, 3, 5, 7} and whose operation, then the ring is said to have an identity. group operation is addition modulo 8. This group For example, (Z, +, *), i.e., the set of integers Z, has a pair of nontrivial subgroups: J = {0, 4} and with the usual addition and multiplication opera- H = {0, 2, 4, 6}, where J is also a subgroup of H. tions, is a ring. As (Z, *) is commutative, this ring In group theory, a cyclic group is a group that is a commutative or Abelian ring. The ring has 1 can be generated by a single element, in the as its identity element. sense that the group has an element a (called the Let’s note that the second operation may not generator of the group) such that, when written have an identity element, nor do we need to find multiplicatively, every element of the group is a an inverse for every element with respect to this power of a. second operation. As for what distributive means, A group G is cyclic if G = {an for any integer n}. intuitively it is what we do in elementary math- Since any group generated by an element in a ematics when performing the following change: a group is a subgroup of that group, showing that * (b + c) = (a * b) + (a * c). the only subgroup of a group G that contains a is A field is a ring for which the elements of the G itself suffices to show that G is cyclic. set, excluding 0, form an Abelian group with the For example, the group G = {0, 2, 4, 6, 1, 3, 5, second operation. 7}, with respect to addition modulo 8 operation, A simple example of a field is the field of ratio- is cyclic. The subgroups J = {0, 4} and H = {0, 2, nal numbers (R, +, *) with the usual addition 4, 6} are also cyclic. and multiplication operations. The numbers of the format a/b ∈ R, where a, b are integers and b ≠ 0. The additive inverse of such a fraction is simply −a/b, and the multiplicative inverse is b/a provided that a ≠ 0. Mathematical Foundations 14-21

MATRIX OF TOPICS VS. REFERENCE MATERIAL [1*] [2*] Rosen 2011 Rosen 2011 Cheney and KincaidCheney 2007

1. Sets, Relations, Functions c2 2. Basic Logic c1 3. Proof Techniques c1 4. Basic Counting c6 5. Graphs and Trees c10, c11 6. Discrete Probability c7 7. Finite State Machines c13 8. Grammars c13 9. Numerical Precision, Accuracy, and Errors c2 10. Number Theory c4 11. Algebraic Structures 14-22 SWEBOK® Guide V3.0

REFERENCES ACKNOWLEDGMENTS

[1*] K. Rosen, Discrete Mathematics and Its The author thankfully acknowledges the contri- Applications, 7th ed., McGraw-Hill, 2011. bution of Prof. Arun Kumar Chatterjee, Ex-Head, Department of Mathematics, Manipur Univer- [2*] E.W. Cheney and D.R. Kincaid, Numerical sity, India, and Prof. Devadatta Sinha, Ex-Head, Mathematics and Computing, 6th ed., Department of Computer Science and Engineer- Brooks/Cole, 2007. ing, University of Calcutta, India, in preparing this chapter on Mathematical Foundations. CHAPTER 15

ENGINEERING FOUNDATIONS

ACRONYMS effectively is a goal of all engineers in all engineering disciplines. CAD Computer-Aided Design Capability Maturity Model BREAKDOWN OF TOPICS FOR CMMI Integration ENGINEERING FOUNDATIONS pdf Probability Density Function pmf Probability Mass Function The breakdown of topics for the Engineering Foundations KA is shown in Figure 15.1. RCA Root Cause Analysis SDLC Software Development Life Cycle 1. Empirical Methods and Experimental Techniques [2*, c1] INTRODUCTION An engineering method for problem solving IEEE defines engineering as “the application of involves proposing solutions or models of solu- a systematic, disciplined, quantifiable approach tions and then conducting experiments or tests to structures, machines, products, systems or to study the proposed solutions or models. Thus, processes” [1]. This chapter outlines some of the engineers must understand how to create an exper- engineering foundational skills and techniques iment and then analyze the results of the experi- that are useful for a software engineer. The focus ment in order to evaluate the proposed solution. is on topics that support other KAs while mini- Empirical methods and experimental techniques mizing duplication of subjects covered elsewhere help the engineer to describe and understand vari- in this document. ability in their observations, to identify the sources As the theory and practice of software engi- of variability, and to make decisions. neering matures, it is increasingly apparent that Three different types of empirical studies com- software engineering is an engineering disci- monly used in engineering efforts are designed pline that is based on knowledge and skills com- experiments, observational studies, and retro- mon to all engineering disciplines. This Engi- spective studies. Brief descriptions of the com- neering Foundations knowledge area (KA) is monly used methods are given below. concerned with the engineering foundations that apply to software engineering and other engi- 1.1. Designed Experiment neering disciplines. Topics in this KA include empirical methods and experimental techniques; A designed or controlled experiment is an inves- statistical analysis; measurement; engineering tigation of a testable hypothesis where one or design; modeling, prototyping, and simulation; more independent variables are manipulated to standards; and root cause analysis. Application measure their effect on one or more dependent of this knowledge, as appropriate, will allow variables. A precondition for conducting an software engineers to develop and maintain experiment is the existence of a clear hypothesis. software more efficiently and effectively. Com- It is important for an engineer to understand how pleting their engineering work efficiently and to formulate clear hypotheses.

15-1 15-2 SWEBOK® Guide V3.0

Figure 15.1. Breakdown of Topics for the Engineering Foundations KA

Designed experiments allow engineers to 2. Statistical Analysis determine in precise terms how the variables are [2*, c9s1, c2s1] [3*, c10s3] related and, specifically, whether a cause-effect relationship exists between them. Each combi- In order to carry out their responsibilities, engi- nation of values of the independent variables is neers must understand how different product a treatment. The simplest experiments have just and process characteristics vary. Engineers often two treatments representing two levels of a sin- come across situations where the relationship gle independent variable (e.g., using a tool vs. between different variables needs to be studied. not using a tool). More complex experimental An important point to note is that most of the designs arise when more than two levels, more studies are carried out on the basis of samples than one independent variable, or any dependent and so the observed results need to be understood variables are used. with respect to the full population. Engineers must, therefore, develop an adequate understand- 1.2. Observational Study ing of statistical techniques for collecting reliable data in terms of sampling and analysis to arrive at An observational or case study is an empirical results that can be generalized. These techniques inquiry that makes observations of processes are discussed below. or phenomena within a real-life context. While an experiment deliberately ignores context, an 2.1. Unit of Analysis (Sampling Units), observational or case study includes context as Population, and Sample part of the observation. A case study is most useful when the focus of the study is on how and why Unit of analysis. While carrying out any empiri- questions, when the behavior of those involved in cal study, observations need to be made on cho- the study cannot be manipulated, and when consen units called the units of analysis or sampling textual conditions are relevant and the boundaries units. The unit of analysis must be identified and between the phenomena and context are not clear. must be appropriate for the analysis. For example, when a software product company wants to 1.3. Retrospective Study find the perceived usability of a software product, the user or the software function may be the unit A retrospective study involves the analysis of his- of analysis. torical data. Retrospective studies are also known Population. The set of all respondents or items as historical studies. This type of study uses data (possible sampling units) to be studied forms the (regarding some phenomenon) that has been population. As an example, consider the case of archived over time. This archived data is then ana- studying the perceived usability of a software lyzed in an attempt to find a relationship between product. In this case, the set of all possible users variables, to predict future events, or to identify forms the population. trends. The quality of the analysis results will While defining the population, care must be depend on the quality of the information contained exercised to understand the study and target in the archived data. Historical data may be incom- population. There are cases when the popula- plete, inconsistently measured, or incorrect. tion studied and the population for which the Engineering Foundations 15-3

results are being generalized may be different. Distribution of a random variable. The range For example, when the study population consists and pattern of variation of a random variable is of only past observations and generalizations are given by its distribution. When the distribution required for the future, the study population and of a random variable is known, it is possible to the target population may not be the same. compute the chance of any event. Some distribu- Sample. A sample is a subset of the population. tions are found to occur commonly and are used The most crucial issue towards the selection of to model many random variables occurring in a sample is its representativeness, including size. practice in the context of engineering. A few of The samples must be drawn in a manner so as the more commonly occurring distributions are to ensure that the draws are independent, and given below. the rules of drawing the samples must be predefined so that the probability of selecting a par- • Binomial distribution: used to model random ticular sampling unit is known beforehand. This variables that count the number of successes method of selecting samples is called probability in n trials carried out independently of each sampling. other, where each trial results in success or Random variable. In statistical terminology, failure. We make an assumption that the the process of making observations or measure- chance of obtaining a success remains con- ments on the sampling units being studied is stant [2*, c3s6]. referred to as conducting the experiment. For • Poisson distribution: used to model the count example, if the experiment is to toss a coin 10 of occurrence of some event over time or times and then count the number of times the space [2*, c3s9]. coin lands on heads, each 10 tosses of the coin • Normal distribution: used to model continu- is a sampling unit and the number of heads for a ous random variables or discrete random given sample is the observation or outcome for variables by taking a very large number of the experiment. The outcome of an experiment is values [2*, c4s6]. obtained in terms of real numbers and defines the random variable being studied. Thus, the attribute Concept of parameters. A statistical distribution of the items being measured at the outcome of is characterized by some parameters. For exam- the experiment represents the random variable ple, the proportion of success in any given trial being studied; the observation obtained from a is the only parameter characterizing a binomial particular sampling unit is a particular realization distribution. Similarly, the Poisson distribution is of the random variable. In the example of the coin characterized by a rate of occurrence. A normal toss, the random variable is the number of heads distribution is characterized by two parameters: observed for each experiment. In statistical stud- namely, its mean and standard deviation. ies, attempts are made to understand population Once the values of the parameters are known, characteristics on the basis of samples. the distribution of the random variable is com- The set of possible values of a random variable pletely known and the chance (probability) of may be finite or infinite but countable (e.g., the any event can be computed. The probabilities set of all integers or the set of all odd numbers). for a discrete random variable can be computed In such a case, the random variable is called a dis- through the probability mass function, called crete random variable. In other cases, the random the pmf. The pmf is defined at discrete points variable under consideration may take values on and gives the point mass—i.e., the probability a continuous scale and is called a continuous ran- that the random variable will take that particular dom variable. value. Likewise, for a continuous random vari- Event. A subset of possible values of a random able, we have the probability density function, variable is called an event. Suppose X denotes called the pdf. The pdf is very much like density some random variable; then, for example, we and needs to be integrated over a range to obtain may define different events such as X ³ x or X < the probability that the continuous random vari- x and so on. able lies between certain values. Thus, if the pdf 15-4 SWEBOK® Guide V3.0

or pmf is known, the chances of the random vari- observations as well as the sample size. The lim- able taking certain set of values may be computed its are computed on the basis of some assump- theoretically. tions regarding the sampling distribution of the Concept of estimation [2*, c6s2, c7s1, c7s3]. point estimate on which the limits are based. The true values of the parameters of a distribution Properties of estimators. Various statistical are usually unknown and need to be estimated properties of estimators are used to decide about from the sample observations. The estimates are the appropriateness of an estimator in a given functions of the sample values and are called sta- situation. The most important properties are that tistics. For example, the sample mean is a statistic an estimator is unbiased, efficient, and consistent and may be used to estimate the population mean. with respect to the population. Similarly, the rate of occurrence of defects esti- Tests of hypotheses [2*, c9s1].A hypothesis is mated from the sample (rate of defects per line of a statement about the possible values of a param- code) is a statistic and serves as the estimate of eter. For example, suppose it is claimed that a the population rate of rate of defects per line of new method of software development reduces the code. The statistic used to estimate some popula- occurrence of defects. In this case, the hypoth- tion parameter is often referred to as the estimator esis is that the rate of occurrence of defects has of the parameter. reduced. In tests of hypotheses, we decide—on A very important point to note is that the results the basis of sample observations—whether a proof the estimators themselves are random. If we posed hypothesis should be accepted or rejected. take a different sample, we are likely to get a dif- For testing hypotheses, the null and alternative ferent estimate of the population parameter. In the hypotheses are formed. The null hypothesis is the theory of estimation, we need to understand dif- hypothesis of no change and is denoted as H0. The ferent properties of estimators—particularly, how alternative hypothesis is written as H1. It is impor- much the estimates can vary across samples and tant to note that the alternative hypothesis may be how to choose between different alternative ways one-sided or two-sided. For example, if we have to obtain the estimates. For example, if we wish the null hypothesis that the population mean is not to estimate the mean of a population, we might less than some given value, the alternative hypoth- use as our estimator a sample mean, a sample esis would be that it is less than that value and we median, a sample mode, or the midrange of the would have a one-sided test. However, if we have sample. Each of these estimators has different the null hypothesis that the population mean is statistical properties that may impact the standard equal to some given value, the alternative hypoth- error of the estimate. esis would be that it is not equal and we would Types of estimates [2*, c7s3, c8s1].There are have a two-sided test (because the true value could two types of estimates: namely, point estimates be either less than or greater than the given value). and interval estimates. When we use the value In order to test some hypothesis, we first com- of a statistic to estimate a population parameter, pute some statistic. Along with the computation we get a point estimate. As the name indicates, a of the statistic, a region is defined such that in point estimate gives a point value of the param- case the computed value of the statistic falls in eter being estimated. that region, the null hypothesis is rejected. This Although point estimates are often used, they region is called the critical region (also known as leave room for many questions. For instance, we the confidence interval). In tests of hypotheses, are not told anything about the possible size of we need to accept or reject the null hypothesis error or statistical properties of the point esti- on the basis of the evidence obtained. We note mate. Thus, we might need to supplement a point that, in general, the alternative hypothesis is the estimate with the sample size as well as the vari- hypothesis of interest. If the computed value of ance of the estimate. Alternately, we might use the statistic does not fall inside the critical region, an interval estimate. An interval estimate is a then we cannot reject the null hypothesis. This random interval with the lower and upper lim- indicates that there is not enough evidence to its of the interval being functions of the sample believe that the alternative hypothesis is true. Engineering Foundations 15-5

As the decision is being taken on the basis given the value of one variable, the other can be of sample observations, errors are possible; the estimated with no error. A positive correlation types of such errors are summarized in the fol- coefficient indicates a positive relationship—that lowing table. is, if one variable increases, so does the other. On the other hand, when the variables are negatively Statistical Decision correlated, an increase of one leads to a decrease Nature of the other. Accept H Reject H 0 0 It is important to remember that correlation H is Type I error 0 OK does not imply causation. Thus, if two variables true (probability = a) are correlated, we cannot conclude that one H is Type II error causes the other. 0 OK false (probability = b) Regression. The correlation analysis only measures the degree of relationship between In test of hypotheses, we aim at maximizing the two variables. The analysis to find the relation- power of the test (the value of 1−b) while ensur- ship between two variables is called regression ing that the probability of a type I error (the value analysis. The strength of the relationship between of a) is maintained within a particular value— two variables is measured using the coefficient of typically 5 percent. determination. This is a value between 0 and 1. It is to be noted that construction of a test of The closer the coefficient is to 1, the stronger the hypothesis includes identifying statistic(s) to relationship between the variables. A value of 1 estimate the parameter(s) and defining a critical indicates a perfect relationship. region such that if the computed value of the statistic falls in the critical region, the null hypoth- 3. Measurement esis is rejected. [4*, c3s1, c3s2] [5*, c4s4] [6*, c7s5] [7*, p442–447] 2.2. Concepts of Correlation and Regression [2*, c11s2, c11s8] Knowing what to measure and which measurement method to use is critical in engineering A major objective of many statistical investiga- endeavors. It is important that everyone involved tions is to establish relationships that make it pos- in an engineering project understand the mea- sible to predict one or more variables in terms of surement methods and the measurement results others. Although it is desirable to predict a quan- that will be used. tity exactly in terms of another quantity, it is sel- Measurements can be physical, environmen- dom possible and, in many cases, we have to be tal, economic, operational, or some other sort of satisfied with estimating the average or expected measurement that is meaningful for the particular values. project. This section explores the theory of mea- The relationship between two variables is stud- surement and how it is fundamental to engineer- ied using the methods of correlation and regres- ing. Measurement starts as a conceptualization sion. Both these concepts are explained briefly in then moves from abstract concepts to definitions the following paragraphs. of the measurement method to the actual appli- Correlation. The strength of linear relation- cation of that method to obtain a measurement ship between two variables is measured using result. Each of these steps must be understood, the correlation coefficient. While computing the communicated, and properly employed in order correlation coefficient between two variables, we to generate usable data. In traditional engineer- assume that these variables measure two differing, direct measures are often used. In software ent attributes of the same entity. The correlation engineering, a combination of both direct and coefficient takes a value between –1 to +1. The derived measures is necessary [6*, p273]. values –1 and +1 indicate a situation when the The theory of measurement states that mea- association between the variables is perfect—i.e., surement is an attempt to describe an underlying 15-6 SWEBOK® Guide V3.0

real empirical system. Measurement methods this simple measurement will lead to substantial define activities that allocate a value or a symbol variation. Engineers must appreciate the need to to an attribute of an entity. define measures from an operational perspective. Attributes must then be defined in terms of the operations used to identify and measure 3.1. Levels (Scales) of Measurement them— that is, the measurement methods. In this [4*, c3s2] [6*, c7s5] approach, a measurement method is defined to be a precisely specified operation that yields a num- Once the operational definitions are determined, ber (called the measurement result) when mea- the actual measurements need to be undertaken. suring an attribute. It follows that, to be useful, It is to be noted that measurement may be car- the measurement method has to be well defined. ried out in four different scales: namely, nominal, Arbitrariness in the method will reflect itself in ordinal, interval, and ratio. Brief descriptions of ambiguity in the measurement results. each are given below. In some cases—particularly in the physical Nominal scale: This is the lowest level of mea- world—the attributes that we wish to measure are surement and represents the most unrestricted easy to grasp; however, in an artificial world like assignment of numerals. The numerals serve only software engineering, defining the attributes may as labels, and words or letters would serve as well. not be that simple. For example, the attributes of The nominal scale of measurement involves only height, weight, distance, etc. are easily and uni- classification and the observed sampling units formly understood (though they may not be very are put into any one of the mutually exclusive easy to measure in all circumstances), whereas and collectively exhaustive categories (classes). attributes such as software size or complexity Some examples of nominal scales are: require clear definitions. Operational definitions. The definition of attri- • Job titles in a company butes, to start with, is often rather abstract. Such • The software development life cycle (SDLC) definitions do not facilitate measurements. For model (like waterfall, iterative, agile, etc.) example, we may define a circle as a line forming followed by different software projects a closed loop such that the distance between any point on this line and a fixed interior point called In nominal scale, the names of the different cat- the center is constant. We may further say that the egories are just labels and no relationship between fixed distance from the center to any point on the them is assumed. The only operations that can be closed loop gives the radius of the circle. It may be carried out on nominal scale is that of counting noted that though the concept has been defined, no the number of occurrences in the different classes means of measuring the radius has been proposed. and determining if two occurrences have the same The operational definition specifies the exact steps nominal value. However, statistical analyses may or method used to carry out a specific measure- be carried out to understand how entities belong- ment. This can also be called the measurement ing to different classes perform with respect to method; sometimes a measurement procedure may some other response variable. be required to be even more precise. Ordinal scale: Refers to the measurement scale The importance of operational definitions where the different values obtained through the can hardly be overstated. Take the case of the process of measurement have an implicit order- apparently simple measurement of height of ing. The intervals between values are not speci- individuals. Unless we specify various factors fied and there is no objectively defined zero like the time when the height will be measured element. Typical examples of measurements in (it is known that the height of individuals vary ordinal scales are: across various time points of the day), how the variability due to hair would be taken care of, • Skill levels (low, medium, high) whether the measurement will be with or without • Capability Maturity Model Integration shoes, what kind of accuracy is expected (correct (CMMI) maturity levels of software devel- up to an inch, 1/2 inch, centimeter, etc.)—even opment organizations Engineering Foundations 15-7

• Level of adherence to process as measured in measured in interval scale, as it is not neces- a 5-point scale of excellent, above average, sary to define what zero intelligence would average, below average, and poor, indicating mean. the range from total adherence to no adherence at all If a variable is measured in interval scale, most of the usual statistical analyses like mean, stan- Measurement in ordinal scale satisfies the tran- dard deviation, correlation, and regression may sitivity property in the sense that if A > B and B be carried out on the measured values. > C, then A > C. However, arithmetic operations Ratio scale: These are quite commonly encoun- cannot be carried out on variables measured in tered in physical science. These scales of mea- ordinal scales. Thus, if we measure customer sat- sures are characterized by the fact that operations isfaction on a 5-point ordinal scale of 5 implying exist for determining all 4 relations: equality, rank a very high level of satisfaction and 1 implying a order, equality of intervals, and equality of ratios. very high level of dissatisfaction, we cannot say Once such a scale is available, its numerical val- that a score of four is twice as good as a score ues can be transformed from one unit to another of two. So, it is better to use terminology such by just multiplying by a constant, e.g., conversion as excellent, above average, average, below aver- of inches to feet or centimeters. When measure- age, and poor than ordinal numbers in order to ments are being made in ratio scale, existence of avoid the error of treating an ordinal scale as a a nonarbitrary zero is mandatory. All statistical ratio scale. It is important to note that ordinal measures are applicable to ratio scale; logarithm scale measures are commonly misused and such usage is valid only when these scales are used, as misuse can lead to erroneous conclusions [6*, in the case of decibels. Some examples of ratio p274]. A common misuse of ordinal scale mea- measures are sures is to present a mean and standard deviation for the data set, both of which are meaningless. • the number of statements in a software However, we can find the median, as computation program of the median involves counting only. • temperature measured in the Kelvin (K) scale Interval scales: With the interval scale, we or in Fahrenheit (F). come to a form that is quantitative in the ordinary sense of the word. Almost all the usual sta- An additional measurement scale, the absolute tistical measures are applicable here, unless they scale, is a ratio scale with uniqueness of the mea- require knowledge of a true zero point. The zero sure; i.e., a measure for which no transformation point on an interval scale is a matter of conven- is possible (for example, the number of program- tion. Ratios do not make sense, but the difference mers working on a project). between levels of attributes can be computed and is meaningful. Some examples of interval scale of 3.2. Direct and Derived Measures measurement follow: [6*, c7s5]

• Measurement of temperature in different Measures may be either direct or derived (some- scales, such as Celsius and Fahrenheit. Sup- times called indirect measures). An example of

pose T1 and T2 are temperatures measured a direct measure would be a count of how many

in some scale. We note that the fact that T1 times an event occurred, such as the number of

is twice T2 does not mean that one object is defects found in a software product. A derived twice as hot as another. We also note that the measure is one that combines direct measures in zero points are arbitrary. some way that is consistent with the measurement • Calendar dates. While the difference between method. An example of a derived measure would dates to measure the time elapsed is a mean- be calculating the productivity of a team as the ingful concept, the ratio does not make sense. number of lines of code developed per developer- • Many psychological measurements aspire to month. In both cases, the measurement method create interval scales. Intelligence is often determines how to make the measurement. 15-8 SWEBOK® Guide V3.0

3.3. Reliability and Validity The design of a software product is guided by [4*, c3s4, c3s5] the features to be included and the quality attributes to be provided. It is important to note that A basic question to be asked for any measure- software engineers use the term “design” within ment method is whether the proposed measure- their own context; while there are some common- ment method is truly measuring the concept with alities, there are also many differences between good quality. Reliability and validity are the two engineering design as discussed in this section most important criteria to address this question. and software engineering design as discussed in The reliability of a measurement method is the Software Design KA. The scope of engineer- the extent to which the application of the mea- ing design is generally viewed as much broader surement method yields consistent measurement than that of software design. The primary aim of results. Essentially, reliability refers to the consis- this section is to identify the concepts needed to tency of the values obtained when the same item develop a clear understanding regarding the pro- is measured a number of times. When the results cess of engineering design. agree with each other, the measurement method Many disciplines engage in problem solving is said to be reliable. Reliability usually depends activities where there is a single correct solu- on the operational definition. It can be quantified tion. In engineering, most problems have many by using the index of variation, which is com- solutions and the focus is on finding a feasible puted as the ratio between the standard deviation solution (among the many alternatives) that and the mean. The smaller the index, the more best meets the needs presented. The set of pos- reliable the measurement results. sible solutions is often constrained by explic- Validity refers to whether the measurement itly imposed limitations such as cost, available method really measures what we intend to mea- resources, and the state of discipline or domain sure. Validity of a measurement method may knowledge. In engineering problems, sometimes be looked at from three different perspectives: there are also implicit constraints (such as the namely, construct validity, criteria validity, and physical properties of materials or laws of phys- content validity. ics) that also restrict the set of feasible solutions for a given problem. 3.4. Assessing Reliability [4*, c3s5] 4.1. Engineering Design in Engineering Education There are several methods for assessing reliability; these include the test-retest method, the The importance of engineering design in engi- alternative form method, the split-halves method, neering education can be clearly seen by the high and the internal consistency method. The easi- expectations held by various accreditation bod- est of these is the test-retest method. In the test- ies for engineering education. Both the Cana- retest method, we simply apply the measurement dian Engineering Accreditation Board and the method to the same subjects twice. The correla- Accreditation Board for Engineering and Tech- tion coefficient between the first and second set nology (ABET) note the importance of including of measurement results gives the reliability of the engineering design in education programs. measurement method. The Canadian Engineering Accreditation Board includes requirements for the amount of 4. Engineering Design engineering design experience/coursework that [5*, c1s2, c1s3, c1s4] is necessary for engineering students as well as qualifications for the faculty members who teach A product’s life cycle costs are largely influenced such coursework or supervise design projects. by the design of the product. This is true for manu- Their accreditation criteria states: factured products as well as for software products. Engineering Foundations 15-9

Design: An ability to design solutions for 4.3. Steps Involved in Engineering Design complex, open-ended engineering prob- [7*, c4] lems and to design systems, components or processes that meet specified needs with Engineering problem solving begins when a appropriate attention to health and safety need is recognized and no existing solution will risks, applicable standards, and economic, meet that need. As part of this problem solving, environmental, cultural and societal con- the design goals to be achieved by the solution siderations. [8, p12] should be identified. Additionally, a set of acceptance criteria must be defined and used to deter- In a similar manner, ABET defines engineering mine how well a proposed solution will satisfy design as the need. Once a need for a solution to a problem has been identified, the process of engineering the process of devising a system, compo- design has the following generic steps: nent, or process to meet desired needs. It is a decision-making process (often itera- a) define the problem tive), in which the basic sciences, math- b) gather pertinent information ematics, and the engineering sciences are c) generate multiple solutions applied to convert resources optimally to d) analyze and select a solution meet these stated needs. [9, p4] e) implement the solution

Thus, it is clear that engineering design is a All of the engineering design steps are itera- vital component in the training and education for tive, and knowledge gained at any step in the all engineers. The remainder of this section will process may be used to inform earlier tasks and focus on various aspects of engineering design. trigger an iteration in the process. These steps are expanded in the subsequent sections. 4.2. Design as a Problem Solving Activity [5*, c1s4, c2s1, c3s3] a. Define the problem. At this stage, the customer’s requirements are gathered. Specific informa- It is to be noted that engineering design is primar- tion about product functions and features are also ily a problem solving activity. Design problems closely examined. This step includes refining the are open ended and more vaguely defined. There problem statement to identify the real problem to are usually several alternative ways to solve the be solved and setting the design goals and criteria same problem. Design is generally considered to for success. be a wicked problem—a term first coined by Horst The problem definition is a crucial stage in Rittel in the 1960s when design methods were a engineering design. A point to note is that this subject of intense interest. Rittel sought an alterna- step is deceptively simple. Thus, enough care tive to the linear, step-by-step model of the design must be taken to carry out this step judiciously. It process being explored by many designers and is important to identify needs and link the success design theorists and argued that most of the prob- criteria with the required product characteristics. lems addressed by the designers are wicked prob- It is also an engineering task to limit the scope lems. As explained by Steve McConnell, a wicked of a problem and its solution through negotiation problem is one that could be clearly defined only among the stakeholders. by solving it or by solving part of it. This paradox implies, essentially, that a wicked problem has to b. Gather pertinent information. At this stage, be solved once in order to define it clearly and then the designer attempts to expand his/her knowl- solved again to create a solution that works. This edge about the problem. This is a vital, yet often has been an important insight for software design- neglected, stage. Gathering pertinent information ers for several decades [10*, c5s1]. can reveal facts leading to a redefinition of the 15-10 SWEBOK® Guide V3.0

problem—in particular, mistakes and false starts refine the design or drive the selection of an alter- may be identified. This step may also involve the native design solution. One of the most impor- decomposition of the problem into smaller, more tant activities in design is documentation of the easily solved subproblems. design solution as well as of the tradeoffs for the While gathering pertinent information, care choices made in the design of the solution. This must be taken to identify how a product may be work should be carried out in a manner such that used as well as misused. It is also important to the solution to the design problem can be com- understand the perceived value of the product/ municated clearly to others. service being offered. Included in the pertinent The testing and verification take us back to the information is a list of constraints that must be success criteria. The engineer needs to devise satisfied by the solution or that may limit the set tests such that the ability of the design to meet the of feasible solutions. success criteria is demonstrated. While designing the tests, the engineer must think through c. Generate multiple solutions. During this stage, different possible failure modes and then design different solutions to the same problem are devel- tests based on those failure modes. The engineer oped. It has already been stated that design prob- may choose to carry out designed experiments to lems have multiple solutions. The goal of this assess the validity of the design. step is to conceptualize multiple possible solutions and refine them to a sufficient level of detail 5. Modeling, Simulation, and Prototyping that a comparison can be done among them. [5*, c6] [11*, c13s3] [12*, c2s3.1] d. Analyze and select a solution. Once alternative Modeling is part of the abstraction process used solutions have been identified, they need to be ana- to represent some aspects of a system. Simula- lyzed to identify the solution that best suits the cur- tion uses a model of the system and provides a rent situation. The analysis includes a functional means of conducting designed experiments with analysis to assess whether the proposed design that model to better understand the system, its would meet the functional requirements. Physical behavior, and relationships between subsystems, solutions that involve human users often include as well as to analyze aspects of the design. Mod- analysis of the ergonomics or user friendliness of eling and simulation are techniques that can be the proposed solution. Other aspects of the solu- used to construct theories or hypotheses about the tion—such as product safety and liability, an eco- behavior of the system; engineers then use those nomic or market analysis to ensure a return (profit) theories to make predictions about the system. on the solution, performance predictions and anal- Prototyping is another abstraction process where ysis to meet quality characteristics, opportunities a partial representation (that captures aspects of for incorrect data input or hardware malfunctions, interest) of the product or system is built. A pro- and so on—may be studied. The types and amount totype may be an initial version of the system but of analysis used on a proposed solution are depen- lacks the full functionality of the final version. dent on the type of problem and the needs that the solution must address as well as the constraints 5.1. Modeling imposed on the design. A model is always an abstraction of some real e. Implement the solution. The final phase of the or imagined artifact. Engineers use models in design process is implementation. Implemen- many ways as part of their problem solving tation refers to development and testing of the activities. Some models are physical, such as a proposed solution. Sometimes a preliminary, made-to-scale miniature construction of a bridge partial solution called a prototype may be devel- or building. Other models may be nonphysical oped initially to test the proposed design solu- representations, such as a CAD drawing of a cog tion under certain conditions. Feedback resulting or a mathematical model for a process. Models from testing a prototype may be used either to help engineers reason and understand aspects of Engineering Foundations 15-11

a problem. They can also help engineers under- An important problem in the development of a stand what they do know and what they don’t discrete simulation is that of initialization. Before know about the problem at hand. a simulation can be run, the initial values of all There are three types of models: iconic, ana- the state variables must be provided. As the simu- logic, and symbolic. An iconic model is a visu- lation designer may not know what initial values ally equivalent but incomplete 2-dimensional are appropriate for the state variables, these val- or 3-dimensional representation—for example, ues might be chosen somewhat arbitrarily. For maps, globes, or built-to-scale models of struc- instance, it might be decided that a queue should tures such as bridges or highways. An iconic be initialized as empty and idle. Such a choice of model actually resembles the artifact modeled. initial condition can have a significant but unrec- In contrast, an analogic model is a functionally ognized impact on the outcome of the simulation. equivalent but incomplete representation. That is, the model behaves like the physical artifact 5.3. Prototyping even though it may not physically resemble it. Examples of analogic models include a miniature Constructing a prototype of a system is another airplane for wind tunnel testing or a computer abstraction process. In this case, an initial version simulation of a manufacturing process. of the system is constructed, often while the sys- Finally, a symbolic model is a higher level of tem is being designed. This helps the designers abstraction, where the model is represented using determine the feasibility of their design. symbols such as equations. The model captures There are many uses for a prototype, includ- the relevant aspects of the process or system in ing the elicitation of requirements, the design and symbolic form. The symbols can then be used to refinement of a user interface to the system, vali- increase the engineer’s understanding of the final dation of functional requirements, and so on. The system. An example is an equation such as F = objectives and purposes for building the proto- Ma. Such mathematical models can be used to type will determine its construction and the level describe and predict properties or behavior of the of abstraction used. final system or product. The role of prototyping is somewhat different between physical systems and software. With 5.2. Simulation physical systems, the prototype may actually be the first fully functional version of a system All simulation models are a specification of real- or it may be a model of the system. In software ity. A central issue in simulation is to abstract engineering, prototypes are also an abstract and specify an appropriate simplification of model of part of the software but are usually not reality. Developing this abstraction is of vital constructed with all of the architectural, perfor- importance, as misspecification of the abstrac- mance, and other quality characteristics expected tion would invalidate the results of the simulation in the finished product. In either case, prototype exercise. Simulation can be used for a variety of construction must have a clear purpose and be testing purposes. planned, monitored, and controlled—it is a tech- Simulation is classified based on the type of nique to study a specific problem within a limited system under study. Thus, simulation can be either context [6*, c2s8]. continuous or discrete. In the context of software In conclusion, modeling, simulation, and pro- engineering, the emphasis will be primarily on totyping are powerful techniques for studying the discrete simulation. Discrete simulations may behavior of a system from a given perspective. model event scheduling or process interaction. All can be used to perform designed experiments The main components in such a model include to study various aspects of the system. How- entities, activities and events, resources, the state ever, these are abstractions and, as such, may not of the system, a simulation clock, and a random model all attributes of interest. number generator. Output is generated by the simulation and must be analyzed. 15-12 SWEBOK® Guide V3.0

6. Standards regional and governmentally recognized organi- [5*, c9s3.2] [13*, c1s2] zations that generate standards for that region or country. For example, in the United States, there Moore states that a are over 300 organizations that develop standards. These include organizations such as the standard can be; (a) an object or measure American National Standards Institute (ANSI), of comparison that defines or represents the American Society for Testing and Materials the magnitude of a unit; (b) a characteriza- (ASTM), the Society of Automotive Engineers tion that establishes allowable tolerances (SAE), and Underwriters Laboratories, Inc. (UL), for categories of items; and (c) a degree or as well as the US government. For more detail level of required excellence or attainment. on standards used in software engineering, see Standards are definitional in nature, estab- Appendix B on standards. lished either to further understanding and There is a set of commonly used principles interaction or to acknowledge observed (or behind standards. Standards makers attempt to desired) norms of exhibited characteristics have consensus around their decisions. There is or behavior. [13*, p8] usually an openness within the community of interest so that once a standard has been set, there Standards provide requirements, specifica- is a good chance that it will be widely accepted. tions, guidelines, or characteristics that must be Most standards organizations have well-defined observed by engineers so that the products, pro- processes for their efforts and adhere to those cesses, and materials have acceptable levels of processes carefully. Engineers must be aware of quality. The qualities that various standards pro- the existing standards but must also update their vide may be those of safety, reliability, or other understanding of the standards as those standards product characteristics. Standards are considered change over time. critical to engineers and engineers are expected to In many engineering endeavors, knowing and be familiar with and to use the appropriate stan- understanding the applicable standards is critical dards in their discipline. and the law may even require use of particular Compliance or conformance to a standard lets standards. In these cases, the standards often rep- an organization say to the public that they (or resent minimal requirements that must be met by their products) meet the requirements stated in the endeavor and thus are an element in the con- that standard. Thus, standards divide organiza- straints imposed on any design effort. The engi- tions or their products into those that conform to neer must review all current standards related to the standard and those that do not. For a standard a given endeavor and determine which must be to be useful, conformance with the standard must met. Their designs must then incorporate any and add value—real or perceived—to the product, all constraints imposed by the applicable stan- process, or effort. dard. Standards important to software engineers Apart from the organizational goals, standards are discussed in more detail in an appendix spe- are used for a number of other purposes such cifically on this subject. as protecting the buyer, protecting the business, and better defining the methods and procedures 7. Root Cause Analysis to be followed by the practice. Standards also [4*, c5, c3s7, c9s8] [5*, c9s3, c9s4, c9s5] provide users with a common terminology and [13*, c13s3.4.5] expectations. There are many internationally recognized Root cause analysis (RCA) is a process designed standards-making organizations including the to investigate and identify why and how an International Telecommunications Union (ITU), undesirable event has happened. Root causes the International Electrotechnical Commission are underlying causes. The investigator should (IEC), IEEE, and the International Organization attempt to identify specific underlying causes of for Standardization (ISO). In addition, there are the event that has occurred. The primary objective Engineering Foundations 15-13

of RCA is to prevent recurrence of the undesir- A very simple approach that is useful in quality able event. Thus, the more specific the investiga- control is the use of a checklist. Checklists are tor can be about why an event occurred, the easier a list of key points in a process with tasks that it will be to prevent recurrence. A common way must be completed. As each task is completed, to identify specific underlying cause(s) is to ask a it is checked off the list. If a problem occurs, series of why questions. then sometimes the checklist can quickly identify tasks that may have been skipped or only par- 7.1. Techniques for Conducting Root Cause tially completed. Analysis Finally, relations diagrams are a means for dis- [4*, c5] [5*, c3] playing complex relationships. They give visual support to cause-and-effect thinking. The dia- There are many approaches used for both quality gram relates the specific to the general, revealing control and root cause analysis. The first step in key causes and key effects. any root cause analysis effort is to identify the real Root cause analysis aims at preventing the problem. Techniques such as statement-restate- recurrence of undesirable events. Reduction of ment, why-why diagrams, the revision method, variation due to common causes requires utili- present state and desired state diagrams, and the zation of a number of techniques. An important fresh-eye approach are used to identify and refine point to note is that these techniques should be the real problem that needs to be addressed. used offline and not necessarily in direct response Once the real problem has been identified, then to the occurrence of some undesirable event. work can begin to determine the cause of the Some of the techniques that may be used to problem. Ishikawa is known for the seven tools reduce variation due to common causes are given for quality control that he promoted. Some of below. those tools are helpful in identifying the causes for a given problem. Those tools are check sheets 1. Cause-and-effect diagrams may be used to or checklists, Pareto diagrams, histograms, run identify the sub and sub-sub causes. charts, scatter diagrams, control charts, and 2. Fault tree analysis is a technique that may be fishbone or cause-and-effect diagrams. More used to understand the sources of failures. recently, other approaches for quality improve- 3. Designed experiments may be used to under- ment and root cause analysis have emerged. Some stand the impact of various causes on the examples of these newer methods are affinity dia- occurrence of undesirable events (see Empir- grams, relations diagrams, tree diagrams, matrix ical Methods and Experimental Techniques charts, matrix data analysis charts, process deci- in this KA). sion program charts, and arrow diagrams. A few 4. Various kinds of correlation analyses may be of these techniques are briefly described below. used to understand the relationship between A fishbone or cause-and-effect diagram is a various causes and their impact. These tech- way to visualize the various factors that affect niques may be used in cases when conduct- some characteristic. The main line in the diagram ing controlled experiments is difficult but represents the problem and the connecting lines data may be gathered (see Statistical Analy- represent the factors that led to or influenced the sis in this KA). problem. Those factors are broken down into subfactors and sub-subfactors until root causes can be identified. 15-14 SWEBOK® Guide V3.0

MATRIX OF TOPICS VS. REFERENCE MATERIAL [4*] [6*] [2*] [3*] [5*] [7*] [11*] [10*] [13*] [12*] Kan 2002 Moore 2006Moore Tockey 2004 Tockey Voland 2003 Voland Fairley 2009Fairley McConnell 2004 Sommerville 2011 Null and Lobur 2006 Cheney and KincaidCheney 2007 Montgomery and Runger 2007

1. Empirical Methods and c1 Experimental Techniques 1.1. Designed Experiment 1.2. Observational Study 1.3. Retrospective Study 2. Statistical c9s1, c10s3 Analysis c2s1 c3s6, c3s9, 2.1. Concept of c4s6, Unit of Analysis c6s2, (Sampling c7s1, Units), Sample, c7s3, and Population c8s1, c9s1 2.2. Concepts of c11s2, Correlation and c11s8 Regression c3s1, 3. Measurement c4s4 c7s5 c3s2 3.1. Levels p442 (Scales) of c3s2 c7s5 –447 Measurement 3.2. Direct and Derived Measures Engineering Foundations 15-15 [4*] [6*] [2*] [3*] [5*] [7*] [11*] [10*] [13*] [12*] Kan 2002 Moore 2006Moore Tockey 2004 Tockey Voland 2003 Voland Fairley 2009Fairley McConnell 2004 Sommerville 2011 Null and Lobur 2006 Cheney and KincaidCheney 2007 Montgomery and Runger 2007

3.3. Reliability c3s4, and Validity c3s5 3.4. Assessing c3s5 Reliability c1s2, 4. Engineering c1s3, Design c1s4 4.1. Design in Engineering Education 4.2. Design c1s4, as a Problem c2s1, c5s1 Solving Activity c3s3 4.3. Steps Involved in c4 Engineering Design 5. Modeling, c2 Prototyping, and c6 c13s3 s3.1 Simulation 5.1. Modeling 5.2. Simulation 5.3. Prototyping c9 6. Standards c1s2 s3.2 c5, c9s3, 7. Root Cause c13 c3s7, c9s4, Analysis s3.4.5 c9s8 c9s5 7.1. Techniques for Conducting c5 c3 Root Cause Analysis 15-16 SWEBOK® Guide V3.0

FURTHER READINGS A. Abran, Software Metrics and Software W.G. Vincenti, What Engineers Know and How Metrology. [14] They Know It. [15]

This book provides very good information on the This book provides an interesting introduc- proper use of the terms measure, measurement tion to engineering foundations through a series method and measurement outcome. It provides of case studies that show many of the founda- strong support material for the entire section on tional concepts as used in real world engineering Measurement. applications. Engineering Foundations 15-17

REFERENCES [1] ISO/IEC/IEEE 24765:2010 Systems and [9] ABET Engineering Accreditation Software Engineering—Vocabulary, ISO/ Commission, “Criteria for Accrediting IEC/IEEE, 2010. Engineering Programs, 2012-2013,” ABET, 2011; www.abet.org/uploadedFiles/ [2*] D.C. Montgomery and G.C. Runger, Accreditation/Accreditation_Process/ Applied Statistics and Probability for Accreditation_Documents/Current/eac- Engineers, 4th ed., Wiley, 2007. criteria-2012-2013.pdf.

[3*] L. Null and J. Lobur, The Essentials of [10*] S. McConnell, Code Complete, 2nd ed., Computer Organization and Architecture, Microsoft Press, 2004. 2nd ed., Jones and Bartlett Publishers, 2006. [11*] E.W. Cheney and D.R. Kincaid, Numerical Mathematics and Computing, 6th ed., [4*] S.H. Kan, Metrics and Models in Software Brooks/Cole, 2007. Quality Engineering, 2nd ed., Addison- Wesley, 2002. [12*] I. Sommerville, Software Engineering, 9th ed., Addison-Wesley, 2011. [5*] G. Voland, Engineering by Design, 2nd ed., Prentice Hall, 2003. [13*] J.W. Moore, The Road Map to Software Engineering: A Standards-Based Guide, [6*] R.E. Fairley, Managing and Leading Wiley-IEEE Computer Society Press, 2006. Software Projects, Wiley-IEEE Computer Society Press, 2009. [14] A. Abran, Software Metrics and Software Metrology, Wiley-IEEE Computer Society [7*] S. Tockey, Return on Software: Maximizing Press, 2010. the Return on Your Software Investment, Addison-Wesley, 2004. [15] W.G. Vincenti, What Engineers Know and How They Know It, John Hopkins [8] Canadian Engineering Accreditation Board, University Press, 1990. Engineers Canada, “Accreditation Criteria and Procedures,” Canadian Council of Professional Engineers, 2011; www. engineerscanada.ca/files/w_Accreditation_ Criteria_Procedures_2011.pdf. APPENDIX A

KNOWLEDGE AREA DESCRIPTION SPECIFICATIONS

INTRODUCTION large notably through the official recognition of the 2004 Version as ISO/IEC Technical Report This document presents the specifications pro- 19759:2005. The list of knowledge areas (KAs) vided to the Knowledge Area Editors (KA Edi- and the breakdown of topics within each KA is tors) regarding the Knowledge Area Descriptions described and detailed in the introduction of this (KA Descriptions) of the Version 3 (V3) edition SWEBOK Guide. of the Guide to the Software Engineering Body Consequently, the SWEBOK Guide is founda- of Knowledge (SWEBOK Guide). This document tional to other initiatives within the IEEE Com- will also enable readers, reviewers, and users to puter Society: clearly understand what specifications were used when developing this version of the SWEBOK a) The list of KAs and the breakdown of topics Guide. within each KA are also adopted by the soft- This document begins by situating the SWE- ware engineering certification and associated BOK Guide as a foundational document for the professional development products offered IEEE Computer Society suite of software engi- by the IEEE Computer Society (see www. neering products and more widely within the computer.org/certification). software engineering community at large. The b) The list of KAs and the breakdown of top- role of the baseline and the Change Control ics are also foundational to the software Board is then described. Criteria and require- engineering curricula guidelines developed ments are defined for the breakdowns of topics, or endorsed by the IEEE Computer Society for the rationale underlying these breakdowns (www.computer.org/portal/web/education/ and the succinct description of topics, and for ref- Curricula). erence materials. Important input documents are c) The Consolidated Reference List (see Appen- also identified, and their role within the project is dix C), meaning the list of recommended explained. Noncontent issues such as submission reference materials (to the level of section format and style guidelines are also discussed. number) that accompanies the breakdown of topics within each KA is also adopted by the THE SWEBOK GUIDE IS A software engineering certification and asso- FOUNDATIONAL DOCUMENT FOR THE ciated professional development products IEEE COMPUTER SOCIETY SUITE OF offered by the IEEE Computer Society. SOFTWARE ENGINEERING PRODUCTS BASELINE AND CHANGE CONTROL The SWEBOK Guide is an IEEE Computer Soci- BOARD ety flagship and structural document for the IEEE Computer Society suite of software engineer- Due to the structural nature of the SWEBOK ing products. The SWEBOK Guide is also more Guide and its adoption by other products, a base- widely recognized as a foundational document line was developed at the outset of the project within the software engineering community at comprised of the list of KAs, the breakdown of

A-1 A-2 SWEBOK® Guide V3.0

topics within each KA, and the Consolidated Ref- Areas and therefore must be incorporated erence List. into the proposed breakdown of topics of A Change Control Board (CCB) has been in each Knowledge Area. These common place for the development of this version to han- themes are measurement, quality (in gen- dle all change requests to this baseline coming eral), and security. from the KA Editors, arising during the review i) The breakdown of topics should be at most process, or otherwise. Change requests must be two or three levels deep. Even though no approved both by the SWEBOK Guide Editors upper or lower limit is imposed on the num- and by the CCB before being implemented. This ber of topics within each KA, a reasonable CCB is comprised of members of the initiatives and manageable number of topics is expected listed above and acting under the authority of the to be included in each KA. Emphasis should Software and Systems Engineering Committee of also be put on the selection of the topics the IEEE Computer Society Professional Activi- themselves rather than on their organization ties Board. in an appropriate hierarchy. j) Topic names must be significant enough CRITERIA AND REQUIREMENTS FOR to be meaningful even when cited outside the THE BREAKDOWN OF TOPICS WITHIN SWEBOK Guide. A KNOWLEDGE AREA k) The description of a KA will include a chart (in tree form) describing the knowledge a) KA Editors are instructed to adopt the base- breakdown. line breakdown of topics. b) The breakdown of topics is expected to be CRITERIA AND REQUIREMENTS FOR “reasonable,” not “perfect.” DESCRIBING TOPICS c) The breakdown of topics within a KA must decompose the subset of the Software Engi- Topics need only be sufficiently described so the neering Body of Knowledge that is “gen- reader can select the appropriate reference mate- erally recognized.” See below for a more rial according to his/her needs. Topic descrip- detailed discussion of this point. tions must not be prescriptive. d) The breakdown of topics within a KA must not presume specific application domains, CRITERIA AND REQUIREMENTS FOR business needs, sizes of organizations, organi- REFERENCE MATERIAL zational structures, management philosophies, software life cycle models, software technolo- a) KA Editors are instructed to use the refer- gies, or software development methods. ences (to the level of section number) allo- e) The breakdown of topics must, as much cated to their KA by the Consolidated Refer- as possible, be compatible with the vari- ence List as their Recommended References. ous schools of thought within software b) There are three categories of reference engineering. material: f) The breakdown of topics within a KA must be compatible with the breakdown of soft- »» Recommended References. The set of ware engineering generally found in indus- Recommended References (to the level try and in the software engineering literature of section number) is collectively known and standards. as the Consolidated Reference List. g) The breakdown of topics is expected to be as »» Further Readings. inclusive as possible. »» Additional references cited in the KA h) The SWEBOK Guide adopts the position Description (for example, the source that even though the following “themes” are of a quotation or reference material in common across all Knowledge Areas, they support of a rationale behind a particular are also an integral part of all Knowledge argument). Appendix A A-3

c) The SWEBOK Guide is intended by defini- cited reference material is sufficient for tion to be selective in its choice of topics the objectives of the SWEBOK Guide). and associated reference material. The list of »» Each reference to the recommended reference material should be clearly viewed reference material should be as precise as an “informed and reasonable selection” as possible by identifying what specific rather than as a definitive list. chapter or section is relevant. d) Reference material can be book chapters, »» A matrix of reference material (to the refereed journal papers, refereed confer- level of section number) versus topics ence papers, refereed technical or industrial must be provided. reports, or any other type of recognized arti- »» A reasonable amount of recommended fact. References to another KA, subarea, or reference material must be identified topic are also permitted. for each KA. The following guidelines e) Reference material must be generally avail- should be used in determining how able and must not be confidential in nature. much is reasonable: f) Reference material must be in English. g) Criteria and requirements for recommended i. If the recommended reference reference material or Consolidated Refer- material were written in a coher- ence List: ent manner that followed the proposed breakdown of topics and in »» Collectively the list of Recommended a uniform style (for example, in a References should be new book based on the proposed KA description), an average tar- i. complete: covering the entire get across all KAs for the number scope of the SWEBOK Guide of pages would be 750. However, ii. sufficient: providing enough this target may not be attainable information to describe “gener- when selecting existing reference ally accepted” knowledge material due to differences in iii. consistent: not providing contra- style and overlap and redundancy dictory knowledge nor conflict- between the selected reference ing practices materials. iv. credible: recognized as providing ii. In other words, the target for the expert treatment number of pages for the entire v. current: treating the subject in collection of recommended refer- a manner that is commensurate ences of the SWEBOK Guide is with currently generally accepted in the range of 10,000 to 15,000 knowledge pages. vi. succinct: as short as possible iii. Another way of viewing this is (both in number of reference that the amount of recommended items and in total page count) reference material would be without failing other objectives. reasonable if it consisted of the study material on this KA for a »» Recommended reference material must software engineering licensing be identified for each topic. Each recom- exam that a graduate would pass mended reference item may of course after completing four years of cover multiple topics. Exceptionally, a work experience. topic may be self-descriptive and not cite a reference material item (for example, a h) Additional reference material can be topic that is a definition or a topic for included by the KA Editor in a “Further which the description itself without any Readings” list: A-4 SWEBOK® Guide V3.0

»» These further readings must be related to WHAT DO WE MEAN BY “GENERALLY the topics in the breakdown rather than, RECOGNIZED KNOWLEDGE”? for example, to more advanced topics. »» The list must be annotated (within 1 The Software Engineering Body of Knowledge paragraph per reference) as to why this is an all-inclusive term that describes the sum reference material was included in the of knowledge within the profession of software list of further readings. Further readings engineering. However, the SWEBOK Guide seeks could include: new versions of an exist- to identify and describe that subset of the body ing reference already included in the of knowledge that is generally recognized or, in recommended references, alternative other words, the core body of knowledge. To bet- viewpoints on a KA, or a seminal treat- ter illustrate what “generally recognized” knowl- ment of a KA. edge is relative to other types of knowledge, »» A general guideline to be followed is 10 Figure A.1 proposes a three-category schema for or fewer further readings per KA. classifying knowledge. »» There is no matrix of the reference The Project Management Institute in its Guide materials listed in further readings and to the Project Management Body of Knowledge the breakdown of topics. defines “generally recognized” knowledge for project management as being: i) Criteria and requirements regarding additional references cited in the KA Description: that subset of the project management body of knowledge generally recognized »» The SWEBOK Guide is not a research as good practice. “Generally recognized” document and its readership will be var- means the knowledge and practices ied. Therefore, a delicate balance must described are applicable to most projects be maintained between ensuring a high most of the time, and there is consensus level of readability within the document about their value and usefulness. “Good while maintaining its technical excel- practice” means there is general agreement lence. Additional reference material that the application of these skills, tools, should therefore only be brought in by and techniques can enhance the chances the KA Editor if it is necessary to the of success over a wide range of projects. discussion. Examples are to identify the “Good practice” does not mean that the source of a quotation or to cite reference knowledge described should always be item in support of a rationale behind a applied uniformly to all projects; the orga- particular and important argument. nization and/or project management team is responsible for determining what is COMMON STRUCTURE appropriate for any given project. [1]

KA descriptions should use the following structure: “Generally accepted” knowledge could also be viewed as knowledge to be included in the study • Acronyms material of a software engineering licensing exam • Introduction (in the USA) that a graduate would take after • Breakdown of Topics of the KA (including a completing four years of work experience. These figure describing the breakdown) two definitions should be seen as complementary. • Matrix of Topics vs. Reference Material KA Editors are also expected to be somewhat • List of Further Readings forward looking in their interpretation by tak- • References ing into consideration not only what is “generally recognized” today and but what they expect will be “generally recognized” in a 3- to 5-year timeframe. Appendix A A-5

Generally Recognized and Systems Engineering Standards Committees. Established traditional prac- It also has been designated as a pivotal standard tices recommended by many by the Software and System Engineering Stan- organizations dards Committee (S2ESC) of the IEEE. Advanced and Research Even though we do not intend that the Guide to Innovative practices tested the Software Engineering Body of Knowledge be fully 12207-conformant, this standard remains a Specialized and used only by some organizations and concepts still key input to the SWEBOK Guide, and special care being developed and tested in will be taken throughout the SWEBOK Guide Practices Used Only for

Certain Software of Types research organizations regarding the compatibility of the Guide with the 12207 standard. Figure A.1. Categories of Knowledge 3. J.W. Moore, The Road Map to Software Engineering: A Standards-Based Guide, LENGTH OF KA DESCRIPTION Wiley-IEEE Computer Society Press, 2006. [4*] KA Descriptions are to be roughly 10 to 20 pages using the formatting template for papers pub- This book describes the scope, roles, uses, and lished in conference proceedings of the IEEE development trends of the most widely used soft- Computer Society. This includes text, references, ware engineering standards. It concentrates on appendices, tables, etc. This, of course, does not important software engineering activities—qual- include the reference materials themselves. ity and project management, system engineering, dependability, and safety. The analysis and IMPORTANT RELATED DOCUMENTS regrouping of the standard collections exposes the reader to key relationships between standards. 1. Graduate Software Engineering 2009 Even though the SWEBOK Guide is not a soft- (GSwE2009): Curriculum Guidelines for ware engineering standard per se, special care Graduate Degree Programs in Software will be taken throughout the document regarding Engineering, 2009; www.gswe2009.org. [2] the compatibility of the Guide with the current IEEE and ISO/IEC Systems and Software Engi- This document “provides guidelines and rec- neering Standards Collection. ommendations” for defining the curricula of a professional master’s level program in software 4. Software Engineering 2004: Curriculum engineering. The SWEBOK Guide is identified Guidelines for Undergraduate Degree as a “primary reference” in developing the body Programs in Software Engineering, IEEE of knowledge underlying these guidelines. This Computer Society and Association for document has been officially endorsed by the Computing Machinery, 2004; http://sites. IEEE Computer Society and sponsored by the computer.org/ccse/SE2004Volume.pdf. [5] Association for Computing Machinery. This document describes curriculum guidelines 2. IEEE Std. 12207-2008 (a.k.a. ISO/IEC for an undergraduate degree in software engineer- 12207:2008) Standard for Systems and ing. The SWEBOK Guide is identified as being Software Engineering—Software Life Cycle “one of the primary sources” in developing the Processes, IEEE, 2008 [3]. body of knowledge underlying these guidelines.

This standard is considered the key standard 5. ISO/IEC/IEEE 24765:2010 Systems and regarding the definition of life cycle processes and Software Engineering—Vocabulary, ISO/ has been adopted by the two main standardization IEC/IEEE, 2010; www.computer.org/ bodies in software engineering: ISO/IEC JTC1/ sevocab. [6] SC7 and the IEEE Computer Society Software A-6 SWEBOK® Guide V3.0

The hierarchy of references for terminology is the bibliography. We believe this approach allows Merriam Webster’s Collegiate Dictionary (11th the reader to be better exposed to the source and ed.) [7], IEEE/ISO/IEC 24765 [6], and new pro- scope of a standard. posed definitions if required. The text accompanying figures and tables should be self-explanatory or have enough related 6. “Certification and Training for Software text. This would ensure that the reader knows Professionals,” IEEE Computer Society, what the figures and tables mean. 2013; www.computer.org/certification. [8] To make sure that some information in the SWEBOK Guide does not become rapidly obso- Information on the certification and associated lete and due to its generic nature, please avoid professional development products developed directly naming tools and products. Instead, try and offered by the IEEE Computer Society for to name their functions. professionals in the field of software engineering can be found on this website. The SWEBOK EDITING Guide is foundational to these products. Editors of the SWEBOK Guide as well as profes- STYLE AND TECHNICAL GUIDELINES sional copy editors will edit KA Descriptions. Editing includes copy editing (grammar, punc- • KA Descriptions should conform to the tuation, and capitalization), style editing (confor- Word template available at www.computer. mance to the Computer Society style guide), and org/portal/web/cscps/formatting. content editing (flow, meaning, clarity, direct- • KA Descriptions are expected to follow the ness, and organization). The final editing will IEEE Computer Society Style Guide (www. be a collaborative process in which the Editors computer.org/portal/web/publications/ of the SWEBOK Guide and the KA Editors work styleguide). together to achieve a concise, well-worded, and • Files are to be submitted in Microsoft Word useful KA Description. format. • All citations of reference material are to be RELEASE OF COPYRIGHT produced using EndNote Web as indicated in the instructions provided to KA Editors in All intellectual property rights associated with this regard. the SWEBOK Guide will remain with the IEEE. KA Editors must sign a copyright release form. OTHER DETAILED GUIDELINES It is also understood that the SWEBOK Guide will continue to be available free of charge in the When referencing the Guide to the Software public domain in at least one format, provided by Engineering Body of Knowledge, use the title the IEEE Computer Society through web technol- “SWEBOK Guide.” ogy or by other means. For the purpose of simplicity, avoid footnotes For more information, see www.computer.org/ and try to include their content in the main text. copyright.htm. Use explicit references to standards, as opposed to simply inserting numbers referencing items in Appendix A A-7

REFERENCES [1] Project Management Institute, A Guide to the [5] Joint Task Force on Computing Curricula, Project Management Body of Knowledge IEEE Computer Society and Association (PMBOK(R) Guide), 5th ed., Project for Computing Machinery, Software Management Institute, 2013. Engineering 2004: Curriculum Guidelines for Undergraduate Degree Programs in [2] Integrated Software and Systems Software Engineering, 2004; http://sites. Engineering Curriculum (iSSEc) Project, computer.org/ccse/SE2004Volume.pdf. Graduate Software Engineering 2009 (GSwE2009): Curriculum Guidelines [6] ISO/IEC/IEEE 24765:2010 Systems and for Graduate Degree Programs in Software Engineering—Vocabulary, ISO/ Software Engineering, Stevens Institute of IEC/IEEE, 2010. Technology, 2009; www.gswe2009.org. [7] Merriam-Webster’s Collegiate Dictionary, [3] IEEE Std. 12207-2008 (a.k.a. ISO/IEC 11th ed., 2003. 12207:2008) Standard for Systems and Software Engineering—Software Life Cycle [8] IEEE Computer Society, “Certification and Processes, IEEE, 2008. Training for Software Professionals,” 2013; www.computer.org/certification. [4*] J.W. Moore, The Road Map to Software Engineering: A Standards-Based Guide, Wiley-IEEE Computer Society Press, 2006. APPENDIX B

IEEE AND ISO/IEC STANDARDS SUPPORTING THE SOFTWARE ENGINEERING BODY OF KNOWLEDGE (SWEBOK)

Some might say that the supply of software engi- title of the standard or simply use its number. neering standards far exceeds the demand. One In obtaining a standard of interest, the reader seldom listens to a briefing on the subject without should rely on the number, not the title, given suffering some apparently obligatory joke that in this article. For reasons of consistency, the there are too many of them. However, the exis- article will use the IEEE’s convention for the tence of standards takes a very large (possibly capitalization of titles—nouns, pronouns, infinite) trade space of alternatives and reduces adjectives, verbs, adverbs, and first and last that space to a smaller set of choices—a huge words have an initial capital letter—despite advantage for users. Nevertheless, it can still be the fact that IEEE and ISO/IEC use differing difficult to choose from dozens of alternatives, so conventions. supplementary guidance, like this appendix, can • Because these standards are being continu- be helpful. A summary list of the standards men- ally revised to take account of new technolo- tioned in this appendix appears at the end. gies and usage patterns, this article will be To reduce tedium in reading, a few simplifica- obsolescent before it is published. Therefore, tions and abridgements are made in this appendix: it will occasionally discuss standards that have not yet been published, if they are likely • ISO/IEC JTC 1/SC 7 maintains nearly two to assume significant importance. hundred standards on the subject. IEEE • Explicit trademarks are omitted. Suffice it to maintains about fifty. The two organizations say that IEEE places a trademark on all of its are in the tenth year of a systematic program standards’ designations. to coordinate and integrate their collections. In general, this article will focus on the stan- There are some other conventions of interest: dards that are recognized by both organizations, taking this condition as evidence that • In both IEEE and ISO/IEC, standards for wide agreement has been obtained. Other systems engineering are maintained by the standards will be mentioned briefly. same committee as those for software engi- • Standards tend to have long, taxonomical neering. Many of the standards apply to both. titles. If there were a single standard for So, instead of making fine distinctions, this building an automobile, the one for your article will deal with both. Camry probably would be titled something • On the other hand, both S2ESC and SC 7 like, “Vehicle, internal combustion, four- (see below for descriptions of these orga- wheel, passenger, sedan.” Also, modern stan- nizations) are responsible for standards dards organizations provide their standards that don’t qualify as “engineering.” In the from databases. Like any database, these US and many other countries, the services sometimes contain errors, particularly for the of a licensed engineer are required when a titles. So this article will often paraphrase the product might affect public safety, health,

B-1 B-2 SWEBOK® Guide V3.0

and welfare as opposed to affecting merely 7) is the one responsible for software and sys- the pocketbook of the client. This appendix tems engineering. SC 7, and its working groups, will respect that distinction and ignore stan- meets twice a year, attracting delegations repre- dards that appear to be merely economic in senting the national standards bodies of partici- consequence. pating nations. Each nation follows its own pro- • User documentation is assumed to be devel- cedures for determining national positions and oped similarly to software. For example, each nation has the responsibility of determining a standard concerning the design of user whether an ISO/IEC standard should be adopted documentation is described in the Software as a national standard. Design KA. SC 7 creates three types of documents: • Some jointly developed standards are explicitly labeled as joint developments, e.g., ISO/ • International Standards: Documents contain- IEC/IEEE 24765. In other cases, the stan- ing requirements that must be satisfied in dards have different designations in the two order to claim conformance. organizations. Examples include • Technical Specifications (formerly called Technical Reports, type 1 and type 2): Docu- »» IEEE Std. 12207:2008 (a.k.a. ISO/IEC ments published in a preliminary manner 12207:2008), where “a.k.a.” (“also while work continues. known as”) is this appendix’s abbrevia- • Technical Reports (formerly called Techni- tion to note the designation in the other cal Reports, type 3): Documents inherently organization; unsuited to be standards, usually because »» IEEE Std. 15939:2008 Standard Adop- they are descriptive rather than prescriptive. tion of ISO/IEC 15939:2007, an adoption by IEEE of a standard developed in The key thing to remember is that only the ISO/IEC; first category counts as a consensus standard. »» IEEE Std. 1220:2005 (a.k.a. ISO/IEC The reader can easily recognize the others by the 26702:2007), a “fast-track” by ISO/IEC suffix TS or TR prepended to the number of the of a standard developed in IEEE. document.

In each of these cases, the standards are IEEE SOFTWARE AND SYSTEMS substantively identical in the two orga- ENGINEERING STANDARDS nizations, differing only in front matter COMMITTEE (S2ESC) and, occasionally, added informational material. IEEE is the world’s largest organization of technical professionals, with about 400,000 members A summary list of all of the mentioned stan- in more than 160 countries. The publication of dards is provided at the end of this appendix. standards is performed by the IEEE Standards Association (IEEE-SA), but the committees that ISO/IEC JTC 1/SC 7, SOFTWARE AND draft and sponsor the standards are in the various SYSTEMS ENGINEERING IEEE societies; S2ESC is a part of the IEEE Com- puter Society. IEEE is a global standards maker ISO/IEC JTC 1/SC 7 is the major source of because its standards are used in many differ- international standards on software and systems ent countries. Despite its international member- engineering. Its name is formed taxonomically. ship (about 50% non-US), though, the IEEE-SA Joint Technical Committee 1 (JTC 1) is a child routinely submits its standards to the American of the International Organization for Standardiza- National Standards Institute (ANSI) for endorse- tion (ISO) and the International Electrotechnical ment as “American National Standards.” Some Commission (IEC); it has the scope of “informa- S2ESC standards are developed within S2ESC, tion technology” and subdivides its work among some are developed jointly with SC 7, and some a number of subcommittees; Subcommittee 7 (SC are adopted after being developed by SC 7. Appendix B B-3

IEEE-SA publishes three types of “standards”: for any of the IEEE categories. In ISO/IEC, it is a “technical report”—defined as a document inher- • Standards, with a preponderance of the verb ently unsuited to be a standard. The 2004 IEEE “shall” SWEBOK Guide was adopted by ISO/IEC with- • Recommended Practices, with a preponder- out change. Presumably, ISO/IEC will adopt Ver- ance of the verb “should” sion 3 of the SWEBOK Guide. • Guides, with a preponderance of the verb “may.” ISO/IEC TR 19759:2005 Software Engineering— All three of these compare to ISO/IEC stan- Guide to the Software Engineering Body of Knowledge dards. IEEE-SA does have the concept of a “Trial- (SWEBOK) Use” standard, which is roughly comparable to Applies to all KAs an ISO/IEC Technical Specification. However, it has nothing comparable to an ISO/IEC Techni- ISO/IEC 19759:2005, a Guide to the Software cal Report; one would look elsewhere in IEEE for Engineering Body of Knowledge (SWEBOK), documents of this ilk. identifies and describes that subset of the body of knowledge that is generally accepted, even THE STANDARDS though software engineers must be knowledge- able not only in software engineering, but also, The remainder of this article allocates the selected of course, in other related disciplines. SWEBOK standards to relevant knowledge areas (KAs) of is an all-inclusive term that describes the sum the SWEBOK Guide. There is a section for each of knowledge within the profession of software KA. Within each section, the relevant standards engineering. are listed—the ones that principally apply to the KA as well as others that principally apply to other KAs but which are also related to the cur- The text of the SWEBOK Guide is freely avail- rent one. Following each standard is a brief sum- able at www.swebok.org/. The ISO/IEC adoption mary. In most cases, the summary is a quotation of the Guide is freely available at http://standards. or paraphrase of the abstract or other introductory iso.org/ittf/PubliclyAvailableStandards/index. material from the text of the standard. html. Most of the standards easily fit into one KA. ISO/IEC/IEEE 24765 provides a shared vocab- Some fit into more than one; in such cases, ulary for the systems and software engineering a cross-reference is provided. Two standards standards of both SC 7 and S2ESC. apply to all KAs, so they are listed in a category called “General.” All of the standards related to computer-aided software engineering (CASE) ISO/IEC/IEEE 24765:2010 Systems and Software tools and environments are listed in the Software Engineering—Vocabulary Engineering Models and Methods KA section. Applies to all KAs

GENERAL ISO/IEC/IEEE 24765:2010 provides a common vocabulary applicable to all systems and software The first two standards are so central that they engineering work. It was prepared to collect and could be slotted into all of the KAs. Two more are support the standardization of terminology. ISO/ described in the Software Engineering Process IEC/IEEE 24765:2010 is intended to serve as a KA, but are mentioned here because they provide useful reference for those in the information tech- a helpful framework and because the descriptions nology field and to encourage the use of systems of several other standards refer to them. and software engineering standards prepared by ISO/IEC TR 19759 is the SWEBOK Guide ISO and liaison organizations IEEE Computer itself. It’s not an IEEE standard because, lacking Society and Project Management Institute. ISO/ prescriptive verbs, it doesn’t satisfy the criteria IEC/IEEE 24765:2010 includes references to the B-4 SWEBOK® Guide V3.0

active source standards for each definition so that It defines the construct of a good requirement, the use of the term can be further explored. provides attributes and characteristics of requirements, and discusses the iterative and recursive application of requirements processes through- The vocabulary is descriptive, rather than pre- out the life cycle. ISO/IEC/IEEE 29148:2011 scriptive; it gathers up all of the definitions from provides additional guidance in the application all of the relevant standards, as well as a few of requirements engineering and management other sources, rather than choosing among com- processes for requirements-related activities in peting definitions. ISO/IEC 12207:2008 and ISO/IEC 15288:2008. The content of the 24765 standard is freely Information items applicable to the engineering accessible online at www.computer.org/sevocab. of requirements and their content are defined. Two standards, 12207 and 15288, provide a The content of ISO/IEC/IEEE 29148:2011 can complete set of processes for the entire life cycle be added to the existing set of requirements- of a system or a software product. The two stan- related life cycle processes defined by ISO/IEC dards are aligned for concurrent use on a single 12207:2008 or ISO/IEC 15288:2008, or it can be project or in a single organization. They are used independently. mentioned here because they are often used as a framework for explaining or localizing the role of other standards in the life cycle. A multipart ISO/IEC standard provides principles and methods for “sizing” software based on its requirements. The functional size is often use- IEEE Std. 12207-2008 (a.k.a. ISO/IEC 12207:2008) ful in the denominator of measurements of qual- Standard for Systems and Software Engineering— ity and productivity in software development. It Software Life Cycle Processes may also play a role in contracting for service- See Software Engineering Process KA level agreements.

IEEE Std. 15288-2008 (a.k.a. ISO/IEC 15288:2008) Standard for Systems and Software Engineering— ISO/IEC 14143 [six parts] Information Technol- System Life Cycle Processes ogy—Software Measurement—Functional Size See Software Engineering Process KA Measurement

ISO/IEC 14143 describes FSM (functional size SOFTWARE REQUIREMENTS measurement). The concepts of functional size measurement (FSM) are designed to overcome the The primary standard for software and systems limitations of earlier methods of sizing software by requirements engineering is a new one that shifting the focus away from measuring how the replaced several existing IEEE standards. It pro- software is implemented to measuring size in terms vides a broad view of requirements engineering of the functions required by the user. across the entire life cycle.

FSM is often known as “function point count- ISO/IEC/IEEE 29148:2011 Systems and Software ing.” The four standards listed below are alter- Engineering—Life Cycle Processes—Requirements native methods for function point counting—all Engineering meet the requirements of ISO/IEC 14143. The dominant method, in terms of market share, is ISO/IEC/IEEE 29148:2011 contains provisions the IFPUG method, described in ISO/IEC 20926. for the processes and products related to the engi- Other methods are variations intended to improve neering of requirements for systems and software the validity of the count in various circumstances. products and services throughout the life cycle. For example, ISO/IEC 19761—COSMIC is Appendix B B-5

notably intended to be used on software with a SOFTWARE DESIGN real-time component. The software design KA includes both software architectural design (for determining the relation- ISO/IEC 19761:2011 Software Engineering—COS- ships among the items of the software and detailed MIC: A Functional Size Measurement Method design (for describing the individual items). ISO/ IEC/IEEE 42010 concerns the description of ISO/IEC 20926:2009 Software and Systems Engi- architecture for systems and software. neering—Software Measurement—IFPUG Func- tional Size Measurement Method ISO/IEC/IEEE 42010:2011 Systems and Software ISO/IEC 20968:2002 Software Engineering—Mk Engineering—Architecture Description II Function Point Analysis—Counting Practices Manual ISO/IEC/IEEE 42010:2011 addresses the creation, analysis, and sustainment of architec- ISO/IEC 24570:2005 Software Engineering— tures of systems through the use of architecture NESMA Functional Size Measurement Method Ver- descriptions. A conceptual model of architecture sion 2.1—Definitions and Counting Guidelines for description is established. The required contents the Application of Function Point Analysis of an architecture description are specified. Archi- tecture viewpoints, architecture frameworks and architecture description languages are introduced Sometimes requirements are described in natu- for codifying conventions and common practices ral language, but sometimes they are described of architecture description. The required content in formal or semiformal notations. The objective of architecture viewpoints, architecture frame- of the Unified Modeling Language (UML) is to works and architecture description languages provide system architects, software engineers, is specified. Annexes provide the motivation and software developers with tools for analysis, and background for key concepts and terminol- design, and implementation of software-based ogy and examples of applying ISO/IEC/IEEE systems as well as for modeling business and 42010:2011. similar processes. The two parts of ISO/IEC 19505 define UML, revision 2. The older ISO/ IEC 19501 is an earlier version of UML. They Like ISO/IEC/IEEE 42010, the next stan- are mentioned here because they are often used to dard treats software “design” as an abstraction, model requirements. independent of its representation in a document. Accordingly, the standard places provisions on the description of design, rather than on design ISO/IEC 19501:2005 Information Technology— itself. Open Distributed Processing—Unified Modeling Language (UML) Version 1.4.2 See Software Engineering Models and IEEE Std. 1016-2009 Standard for Information Methods KA Technology—Systems Design—Software Design Descriptions ISO/IEC 19505:2012 [two parts] Information Tech- nology—Object Management Group Unified Model- This standard describes software designs and ing Language (OMG UML) establishes the information content and organiza- See Software Engineering Models and tion of a software design description (SDD). An Methods KA SDD is a representation of a software design to be used for recording design information and communicating that design information to key design B-6 SWEBOK® Guide V3.0

stakeholders. This standard is intended for use in standard is also applicable to user documentation design situations in which an explicit software for systems including hardware. design description is to be prepared. These situations include traditional software construction activities (when design leads to code) and reverse SOFTWARE CONSTRUCTION engineering situations (when a design description is recovered from an existing implementation). The term “software construction” refers to the This standard can be applied to commercial, sci- detailed creation of working, meaningful software entific, or military software that runs on digital through a combination of coding, verification, computers. Applicability is not restricted by the unit testing, integration testing, and debugging. size, complexity, or criticality of the software. There are few standards on the details of soft- This standard can be applied to the description ware coding. It has been found through (mostly of high-level and detailed designs. This stan- bad) experience that coding conventions are not dard does not prescribe specific methodologies appropriate for standardization because, in most for design, configuration management, or -qual cases, the real benefit comes from the consis- ity assurance. This standard does not require the tency of applying an arbitrary convention rather use of any particular design languages, but estab- than the convention itself. So, although coding lishes requirements on the selection of design conventions are a good idea, it is generally left languages for use in an SDD. This standard can to the organization or the project to develop such be applied to the preparation of SDDs captured as a standard. paper documents, automated databases, software Nevertheless, the subject of secure coding has development tools, or other media. attracted attention in recent years because some coding idioms are insecure in the face of attack. A Technical Report prepared by ISO/IEC JTC 1/ By convention, this appendix treats user docu- SC 22 (programming languages) describes vul- mentation as a part of a software system. There- nerabilities in programming languages and how fore, the various aspects of user documentation— they can be avoided. its design, its testing, and so forth—are allocated to different KAs. The next standard deals with the design of user documentation. ISO/IEC TR 24772:2013 Information Technology— Programming Languages—Guidance to Avoiding Vulnerabilities in Programming Languages through IEEE Std. 26514-2010 Standard Adoption of ISO/ Language Selection and Use IEC 26514:2008 Systems and Software Engineer- ing—Requirements for Designers and Developers of ISO/IEC TR 24772:2013 specifies software pro- User Documentation gramming language vulnerabilities to be avoided in the development of systems where assured This standard provides requirements for the behavior is required for security, safety, mis- design and development of software user docu- sion-critical, and business-critical software. In mentation as part of the life cycle processes. It general, this guidance is applicable to the soft- defines the documentation process from the view- ware developed, reviewed, or maintained for any point of the documentation developer and also application. covers the documentation product. It specifies the Vulnerabilities are described in a generic man- structure, content, and format for user documen- ner that is applicable to a broad range of pro- tation and also provides informative guidance for gramming languages. Annexes relate the generic user documentation style. It is independent of the guidance to a selection of specific programming software tools that may be used to produce docu- languages. mentation and applies to both printed documentation and onscreen documentation. Much of this Appendix B B-7

The Technical Report is freely available at http:// SOFTWARE TESTING standards.iso.org/ittf/PubliclyAvailableStandards/ index.html. Oddly, there are few standards for testing. IEEE Two standards are mentioned here because unit Std. 829 is the most comprehensive. testing is often regarded as an activity of software construction. IEEE and ISO/IEC are cooperating in the development of a four-part joint standard, IEEE Std. 829-2008 Standard for Software and Sys- 29119, that will provide a comprehensive treat- tem Test Documentation ment of testing and supplant IEEE Std. 1008. Test processes determine whether the development products of a given activity conform to the IEEE Std. 1008-1987 Standard for Software Unit requirements of that activity and whether the sys- Testing tem and/or software satisfies its intended use and See Software Testing KA user needs. Testing process tasks are specified for different integrity levels. These process tasks ISO/IEC/IEEE 29119 [four parts] (Draft) Software determine the appropriate breadth and depth of and Systems Engineering—Software Testing test documentation. The documentation elements See Software Testing KA for each type of test documentation can then be selected. The scope of testing encompasses software-based systems, computer software, hard- The next standard provides for the development ware, and their interfaces. This standard applies of user documentation during an agile devel- to software-based systems being developed, opment process. It is mentioned here because maintained, or reused (legacy, commercial off- agile development is sometimes regarded as the-shelf, nondevelopmental items). The term construction. “software” also includes firmware, microcode, and documentation. Test processes can include inspection, analysis, demonstration, verification, ISO/IEC/IEEE 26515:2012 Systems and Software and validation of software and software-based Engineering—Developing User Documentation in an system products. Agile Environment See Software Engineering Models and Methods KA IEEE Std. 1008 focuses on unit testing.

Coding is not the only way to create a software IEEE Std. 1008-1987 Standard for Software Unit product. Often code (as well as requirements and Testing design) is reused from previous projects or engi- neered for reuse in future projects. IEEE Std. 1517 The primary objective is to specify a standard is mentioned here because it provides a common approach to software unit testing that can be framework for extending the system and software used as a basis for sound software engineer- life cycle processes of IEEE Std. 12207:2008 to ing practice. A second objective is to describe include the systematic practice of reuse. the software engineering concepts and testing assumptions on which the standard approach is based. A third objective is to provide guidance IEEE Std. 1517-2010 Standard for Information and resource information to assist with the imple- Technology—System and Software Life Cycle Pro- mentation and usage of the standard unit testing cesses—Reuse Processes approach. See Software Engineering Process KA B-8 SWEBOK® Guide V3.0

IEEE and ISO/IEC JTC 1/SC 7 are cooperating It specifies processes for use in testing and in a project to develop a single comprehensive reviewing of user documentation. It is not lim- standard that covers all aspects of testing. One ited to the test and review phase of the life cycle, can hope for publication of the four-part standard but includes activities throughout the information by 2014. Portions of the content remain contro- management and documentation management versial. One taxonomical issue is whether “static processes. methods”—such as inspection, review, and static analysis—should fall within the scope of “testing” or should be distinguished as “verification Two standards are mentioned here because and validation.” Although the resolution of the some sources consider software verification and issue is probably of little importance to users of validation to be taxonomically included in testing. the standard, it assumes great importance to the standards-writers who must manage an integrated suite of interoperating standards. IEEE Std. 1012-2012 Standard for System and Soft- ware Verification and Validation See Software Quality KA ISO/IEC/IEEE 29119 [four parts] (Draft) Software and Systems Engineering—Software Testing IEEE Std. 1044-2009 Standard for Classification for Software Anomalies The purpose of ISO/IEC 29119 Software Testing See Software Quality KA is to define an internationally agreed standard for software testing that can be used by any organization when performing any form of software SOFTWARE MAINTENANCE testing. This standard—the result of harmonizing distinct IEEE and ISO/IEC standards on the subject— Testing of user documentation is described in describes a single comprehensive process for the the next standard, providing requirements for the management and execution of software mainte- test and review of software user documentation nance. It expands on the provisions of the soft- as part of the life cycle processes. It defines the ware maintenance process provided in ISO/IEC/ documentation process from the viewpoint of the IEEE 12207. documentation tester and reviewer. It is relevant to roles involved in testing and development of software and user documentation, including proj- IEEE Std. 14764-2006 (a.k.a. ISO/IEC 14764:2006) ect managers, usability experts, and information Standard for Software Engineering—Software Life developers in addition to testers and reviewers. Cycle Processes—Maintenance

ISO/IEC 14764:2006 describes in greater IEEE Std. 26513-2010 Standard Adoption of ISO/ detail management of the maintenance process IEC 26513:2009 Systems and Software Engineer- described in ISO/IEC 12207, including amend- ing—Requirements for Testers and Reviewers of ments. It also establishes definitions for the vari- Documentation ous types of maintenance. ISO/IEC 14764:2006 provides guidance that applies to planning, exe- ISO/IEC 26513 provides the minimum require- cution and control, review and evaluation, and ments for the testing and reviewing of user docu- closure of the maintenance process. The scope of mentation, including both printed and onscreen ISO/IEC 14764:2006 includes maintenance for documents used in the work environment by the multiple software products with the same main- users of systems software. It applies to printed tenance resources. “Maintenance” in ISO/IEC user manuals, online help, tutorials, and user ref- 14764:2006 means software maintenance unless erence documentation. otherwise stated. Appendix B B-9

ISO/IEC 14764:2006 provides the framework in ISO/IEC/IEEE Std. 24765 and the information within which generic and specific software main- item requirements of IEEE Std. 15939. tenance plans may be executed, evaluated, and tailored to the maintenance scope and magnitude of given software products. It provides the ISO/IEC JTC 1/SC 7 has not yet determined framework, precise terminology, and processes what action it should take regarding the new to allow the consistent application of technol- IEEE Std. 828. There are issues concerning the ogy (tools, techniques, and methods) to software extent of compatibility with ISO/IEC/IEEE maintenance. 12207 and other standards in the SC 7 suite. It It does not address the operation of software should be noted, though, that SC 7 does not have and the operational functions, e.g., backup, a competing standard. recovery, and system administration, which are normally performed by those who operate the SOFTWARE ENGINEERING software. MANAGEMENT ISO/IEC 14764:2006 is written primarily for maintainers of software and additionally for those Most readers will interpret the phrase “software responsible for development and quality assur- engineering management” to mean the manage- ance. It may also be used by acquirers and users ment of a project that concerns software. There of systems containing software, who may provide are at least two possible extensions to this gen- inputs to the maintenance plan. eralization, though. Some software activities are managed according to a service-level agreement (SLA). SLAs do not meet the criteria for “proj- SOFTWARE CONFIGURATION ect” according to some definitions. Also, it has MANAGEMENT become generally agreed that some management of software should occur in the organization at a There is one standard for configuration level above the project, so that all projects can management. benefit from a common investment. A commonly cited example is the provision of software processes and tooling by the organization. IEEE Std. 828-2012 Standard for Configuration Software project management can be regarded Management in Systems and Software Engineering as a specialization of “project management”— often regarded as a distinct discipline. The Proj- This standard establishes the minimum require- ect Management Institute’s Guide to the Project ments for processes for configuration management Management Body of Knowledge (PMBOK® (CM) in systems and software engineering. The Guide) is often regarded as the authoritative application of this standard applies to any form, source for this knowledge. From time to time, class, or type of software or system. This revision IEEE adopts the most recent version of the of the standard expands the previous version to PMBOK® Guide as an IEEE standard. explain CM, including identifying and acquiring configuration items, controlling changes, reporting the status of configuration items, as well as IEEE Std. 1490-2011 Guide—Adoption of the Proj- software builds and release engineering. Its pre- ect Management Institute (PMI®) Standard, A decessor defined only the contents of a software Guide to the Project Management Body of Knowl- configuration management plan. This standard edge (PMBOK® Guide)—Fourth Edition addresses what CM activities are to be done, when they are to happen in the life cycle, and what plan- The PMBOK® Guide identifies that subset of ning and resources are required. It also describes the project management body of knowledge gen- the content areas for a CM plan. The standard sup- erally recognized as good practice. “Generally ports ISO/IEC/IEEE 12207:2008 and ISO/IEC/ recognized” means the knowledge and practices IEEE 15288:2008 and adheres to the terminology described are applicable to most projects most of B-10 SWEBOK® Guide V3.0

the time and there is consensus about their value and Particularly in high-technology applications usefulness. “Good practice” means there is general and high-consequence projects, the management agreement that the application of these skills, tools, of risk is an important aspect of the overall proj- and techniques can enhance the chances of success ect management responsibilities. This standard over a wide range of projects. Good practice does deals with that subject. not mean the knowledge described should always be applied uniformly to all projects; the organization and/or project management team is respon- IEEE Std. 16085-2006 (a.k.a. ISO/IEC 16085:2006) sible for determining what is appropriate for any Standard for Systems and Software Engineering— given project. The PMBOK® Guide also provides Software Life Cycle Processes—Risk Management and promotes a common vocabulary within the project management profession for discussing, ISO/IEC 16085:2006 defines a process for the writing, and applying project management con- management of risk in the life cycle. It can be cepts. Such a standard vocabulary is an essential added to the existing set of system and software element of a professional discipline. The Project life cycle processes defined by ISO/IEC 15288 and Management Institute (PMI) views this standard ISO/IEC 12207, or it can be used independently. as a foundational project management reference ISO/IEC 16085:2006 can be applied equally to for its professional development programs and systems and software. certifications. The purpose of risk management is to identify potential managerial and technical problems before they occur so that actions can be taken that The 2008 revisions of ISO/IEC/IEEE 12207 reduce or eliminate the probability and/or impact and 15288 provide project management proof these problems should they occur. It is a criti- cesses for software and systems and relate them cal tool for continuously determining the feasi- to organization-level processes as well as tech- bility of project plans, for improving the search nical processes. The jointly developed 16326 for and identification of potential problems that standard, replacing two older standards, expands can affect life cycle activities and the quality and those provisions with guidance for application. performance of products, and for improving the active management of projects.

ISO/IEC/IEEE 16326:2009 Systems and Soft- ware Engineering—Life Cycle Processes—Project The analysis of risk and risk mitigation depends Management crucially upon measurement. This international standard provides an elaboration of the measure- ISO/IEC/IEEE 16326:2009 provides normative ment process from ISO/IEC/IEEE 15288:2008 content specifications for project management and ISO/IEC/IEEE 12207:2008. plans covering software projects and software- intensive system projects. It also provides detailed discussion and advice on applying a set of proj- IEEE Std. 15939-2008 Standard Adoption of ISO/ ect processes that are common to both the soft- IEC 15939:2007 Systems and Software Engineer- ware and system life cycle as covered by ISO/IEC ing—Measurement Process 12207:2008 (IEEE Std. 12207-2008) and ISO/IEC 15288:2008 (IEEE Std. 15288-2008), respectively. ISO/IEC 15939 defines a measurement process The discussion and advice are intended to aid in applicable to system and software engineer- the preparation of the normative content of project ing and management disciplines. The process is management plans. ISO/IEC/IEEE 16326:2009 described through a model that defines the activi- is the result of the harmonization of ISO/IEC TR ties of the measurement process that are required 16326:1999 and IEEE Std. 1058-1998. to adequately specify what measurement information is required, how the measures and analysis results are to be applied, and how to determine Appendix B B-11

if the analysis results are valid. The measurement to produce or manage documentation, and applies process is flexible, tailorable, and adaptable to the to both printed documentation and onscreen docu- needs of different users. mentation. Much of its guidance is applicable to ISO/IEC 15939:2007 identifies a process that user documentation for systems including hard- supports defining a suitable set of measures that ware as well as software. address specific information needs. It identifies the activities and tasks that are necessary to successfully identify, define, select, apply, and improve Sometimes software or system components are measurement within an overall project or organi- acquired rather than developed. zational measurement structure. It also provides definitions for measurement terms commonly used within the system and software industries. IEEE Std. 1062-1998 Recommended Practice for Software Acquisition

Software projects often require the develop- A set of useful quality practices that can be ment of user documentation. Management of the selected and applied during one or more steps in project, therefore, includes management of the a software acquisition process is described. This documentation effort. recommended practice can be applied to software that runs on any computer system regardless of the size, complexity, or criticality of the software, ISO/IEC/IEEE 26511:2012 Systems and Software but is more suited for use on modified-off-the- Engineering—Requirements for Managers of User shelf software and fully developed software. Documentation

ISO/IEC/IEEE 26511:2012 specifies procedures Sometimes user documentation is acquired for managing user documentation throughout the regardless of whether the software it describes software life cycle. It applies to people or orga- was acquired. The following standard deals with nizations producing suites of documentation, to that subject. those undertaking a single documentation project, and to documentation produced internally, as well as to documentation contracted to outside service ISO/IEC/IEEE 26512:2011 Systems and Software organizations. It provides an overview of the soft- Engineering—Requirements for Acquirers and Sup- ware documentation and information management pliers of User Documentation processes, and also presents aspects of portfolio planning and content management that user docu- ISO/IEC/IEEE 26512:2011 was developed to mentation managers apply. It covers management assist users of ISO/IEC/IEEE 15288:2008 or ISO/ activities in starting a project, including setting IEC/IEEE 12207:2008 to acquire or supply soft- up procedures and specifications, establishing ware user documentation as part of the software infrastructure, and building a team. It includes life cycle processes. It defines the documentation examples of roles needed on a user documentation process from the acquirer’s standpoint and the team. It addresses measurements and estimates supplier’s standpoint. ISO/IEC/IEEE 26512:2011 needed for management control, and the use of covers the requirements for information items used supporting processes such as change management, in the acquisition of user documentation products: schedule and cost control, resource management, the acquisition plan, document specification, state- and quality management and process improvement of work, request for proposals, and proposal. ment. It includes requirements for key documents It provides an overview of the software user docu- produced for user documentation management, mentation and information management processes including documentation plans and documentation which may require acquisition and supply of soft- management plans. ISO/IEC/IEEE 26511:2012 is ware user documentation products and services. independent of the software tools that may be used It addresses the preparation of requirements for B-12 SWEBOK® Guide V3.0

software user documentation. These requirements improved practices. For example, one might pro- are central to the user documentation specification pose an improved practice for software require- and statement of work. It includes requirements ments analysis. A naïve treatment might relate for primary document outputs of the acquisition the description to an early stage of the life cycle and supply process: the request for proposal and model. A superior approach is to describe the the proposal for user documentation products and practice in the context of a process that can be services. It also discusses the use of a documen- applied at any stage of the life cycle. The require- tation management plan and a document plan as ments analysis process, for example, is neces- they arise in the acquisition and supply processes. sary for the development stage, for maintenance, ISO/IEC/IEEE 26512:2011 is independent of the and often for retirement, so an improved practice software tools that may be used to produce docu- described in terms of the requirements analysis mentation and applies to both printed documen- process can be applied to any of those stages. tation and onscreen documentation. Much of its The two key standards are ISO/IEC/IEEE guidance is applicable to user documentation for 12207, Software Life Cycle Processes, and ISO/ systems including hardware as well as software. IEC/IEEE 15288, System Life Cycle Processes. The two standards have distinct histories, but they were both revised in 2008 to align their pro- The next two standards are mentioned here cesses, permitting their interoperable use across a because they supply information used in manage- wide spectrum of projects ranging from a stand- ment decision-making. alone software component to a system with neg- ligible software content. Both are being revised again with the intent of containing an identical IEEE Std. 1028-2008 Standard for Software Reviews list of processes, but with provisions specialized and Audits for the respective disciplines. See Software Quality KA

IEEE Std. 1061-1998 Standard for Software Quality IEEE Std. 12207-2008 (a.k.a. ISO/IEC 12207:2008) Metrics Methodology Standard for Systems and Software Engineering— See Software Quality KA Software Life Cycle Processes

ISO/IEC 12207:2008 establishes a common The next standard is mentioned because it framework for software life cycle processes, with includes the manager’s role in developing user well-defined terminology that can be referenced documentation in an agile project. by the software industry. ISO/IEC 12207:2008 applies to the acquisition of systems and software products and ser- ISO/IEC/IEEE 26515:2012 Systems and Software vices and to the supply, development, operation, Engineering—Developing User Documentation in an maintenance, and disposal of software products Agile Environment and the software portion of a system, whether See Software Engineering Models and performed internally or externally to an organiza- Methods KA tion. Those aspects of system definition needed to provide the context for software products and services are included. SOFTWARE ENGINEERING PROCESS ISO/IEC 12207:2008 also provides a process that can be employed for defining, controlling, Software and systems engineering processes and improving software life cycle processes. are central to the standardization of those two The processes, activities and tasks of ISO/IEC disciplines—not just because many are inter- 12207:2008—either alone or in conjunction with ested in process improvement, but also because ISO/IEC 15288—may also be applied during the processes are effective for the description of acquisition of a system that contains software. Appendix B B-13

IEEE Std. 15288-2008 (a.k.a. ISO/IEC 15288:2008) information items (information products, docu- Standard for Systems and Software Engineering— mentation) to be developed and revised during System Life Cycle Processes systems and software life cycles and service management processes. It specifies the purpose ISO/IEC 15288:2008 establishes a common and content of all identified systems and software framework for describing the life cycle of sys- data records and life cycle information items, as tems created by humans. It defines a set of well as records and information items for infor- processes and associated terminology. These mation technology service management. The processes can be applied at any level in the information item contents are defined according hierarchy of a system’s structure. Selected sets to generic document types (description, plan, pol- of these processes can be applied throughout icy, procedure, report, request, and specification) the life cycle for managing and performing the and the specific purpose of the document. For stages of a system’s life cycle. This is accom- simplicity of reference, each information item plished through the involvement of all interested is described as if it were published as a separate parties, with the ultimate goal of achieving cus- document. However, information items may be tomer satisfaction. unpublished but available in a repository for ref- ISO/IEC 15288:2008 also provides processes erence, divided into separate documents or vol- that support the definition, control, and improve- umes, or combined with other information items ment of the life cycle processes used within an into one document. ISO/IEC/IEEE 15289:2011 organization or a project. Organizations and is based on the life cycle processes specified in projects can use these life cycle processes when ISO/IEC 12207:2008 (IEEE Std. 12207-2008) acquiring and supplying systems. and ISO/IEC 15288:2008 (IEEE Std. 15288- ISO/IEC 15288:2008 concerns those systems 2008), and the service management processes that are man-made and may be configured with specified in ISO/IEC 20000-1:2005 and ISO/IEC one or more of the following: hardware, software, 20000-2:2005. data, humans, processes (e.g., processes for providing service to users), procedures (e.g., opera- tor instructions), facilities, materials, and natu- The next two guides provide supplementary rally occurring entities. When a system element is information helpful in applying 12207 and 15288. software, the software life cycle processes documented in ISO/IEC 12207:2008 may be used to implement that system element. IEEE Std. 24748.2-2012 Guide—Adoption of ISO/ ISO/IEC 15288:2008 and ISO/IEC 12207:2008 IEC TR 24748-2:2011 Systems and Software Engi- are harmonized for concurrent use on a single neering—Life Cycle Management—Part 2: Guide to project or in a single organization. the Application of ISO/IEC 15288 (System Life Cycle Processes)

Those two standards specify that processes ISO/IEC TR 24748-2 is a guide for the applica- may produce items of information but do not pre- tion of ISO/IEC 15288:2008. It addresses sys- scribe their content or format. The next standard tem, life cycle, process, organizational, project, provides help with that. and adaptation concepts, principally through reference to ISO/IEC TR 24748-1 and ISO/IEC 15288:2008. It then gives guidance on applying ISO/IEC/IEEE 15289:2011 Systems and Software ISO/IEC 15288:2008 from the aspects of strat- Engineering—Content of Life-Cycle Information egy, planning, application in organizations, and Products (Documentation) application on projects.

ISO/IEC/IEEE 15289:2011 provides require- IEEE Std. 24748.3-2012 Guide—Adoption of ments for identifying and planning the specific ISO/IEC TR 24748-3:2011 Systems and Software B-14 SWEBOK® Guide V3.0

Engineering—Life Cycle Management—Part 3: updated application guides for those International Guide to the Application of ISO/IEC 12207 (Soft- Standards. ISO/IEC TR 24748-1 is a result of the ware Life Cycle Processes) alignment stage of the harmonization of ISO/IEC 12207 and ISO/IEC 15288. ISO/IEC TR 24748-3 is a guide for the application of ISO/IEC 12207:2008. It addresses system, life cycle, process, organizational, project, The next standard extends the provisions of and adaptation concepts, principally through ISO/IEC/IEEE 12207 to deal with systematic reference to ISO/IEC TR 24748-1 and ISO/IEC software reuse. 12207:2008. It gives guidance on applying ISO/ IEC 12207:2008 from the aspects of strategy, planning, application in organizations, and appli- IEEE Std. 1517-2010 Standard for Information cation on projects. Technology—System and Software Life Cycle Pro- cesses—Reuse Processes

The 12207 and 15288 standards provide pro- A common framework for extending the system cesses covering the life cycle, but they do not pro- and software life cycle processes of IEEE Std. vide a standard life cycle model (waterfall, incre- 12207:2008 to include the systematic practice mental delivery, prototype-driven, etc). Selecting of reuse is provided. The processes, activities, an appropriate life cycle model for a project is a and tasks to be applied during each life cycle major concern of ISO/IEC 24748-1. process to enable a system and/or product to be constructed from reusable assets are specified. The processes, activities, and tasks to enable IEEE Std. 24748.1-2011 Guide—Adoption of ISO/ the identification, construction, maintenance, IEC TR 24748-1:2010 Systems and Software Engi- and management of assets supplied are also neering—Life Cycle Management—Part 1: Guide specified. for Life Cycle Management

ISO/IEC TR 24748-1 provides information on IEEE Std. 1220 has been widely applied as a life cycle concepts and descriptions of the pur- systems engineering process and was adopted by poses and outcomes of representative life cycle ISO/IEC with the number 26702. Unfortunately, stages. It also illustrates the use of a life cycle the standard is not completely compatible with model for systems in the context of ISO/IEC ISO/IEC/IEEE 15288 and is being revised to 15288 and provides a corresponding illustration solve that problem. The result will be published of the use of a life cycle model for software in the as ISO/IEC/IEEE 24748-4. context of ISO/IEC 12207. ISO/IEC TR 24748-1 additionally provides detailed discussion and advice on adapting a life cycle model for use in a IEEE Std. 1220-2005 (a.k.a. ISO/IEC 26702:2007) specific project and organizational environment. Standard for Application and Management of the It further provides guidance on life cycle model Systems Engineering Process use by domains, disciplines and specialties. ISO/ IEC TR 24748-1 gives a detailed comparison ISO/IEC 26702 defines the interdisciplinary tasks between prior and current versions of ISO/IEC which are required throughout a system’s life 12207 and ISO/IEC 15288 as well as advice on cycle to transform customer needs, requirements, transitioning from prior to current versions and and constraints into a system solution. In addi- on using their application guides. The discus- tion, it specifies the requirements for the systems sion and advice are intended to provide a refer- engineering process and its application through- ence model for life cycle models, facilitate use of out the product life cycle. ISO/IEC 26702:2007 the updated ISO/IEC 15288 and ISO/IEC 12207, focuses on engineering activities necessary to and provide a framework for the development of guide product development, while ensuring Appendix B B-15

that the product is properly designed to make it A VSE could obtain an ISO/IEC 29110 Certi- affordable to produce, own, operate, maintain, fication. The set of technical reports is available and eventually dispose of without undue risk to at no cost on the ISO website. Many ISO 29110 health or the environment. documents are available in English, Spanish, Por- tuguese, Japanese, and French.

Since SC 7 and IEEE have written so many process standards, one may not be surprised to ISO/IEC TR 29110-5-1-2:2011 Software Engineer- learn that their model for process description is ing—Lifecycle Profiles for Very Small Entities recorded in a Technical Report. (VSEs)—Part 5-1-2: Management and Engineering Guide: Generic Profile Group: Basic Profile

IEEE Std. 24774-2012 Guide—Adoption of ISO/IEC ISO/IEC TR 29110-5-1-2:2011 is applicable to TR 24474:2010 Systems and Software Engineer- very small entities (VSEs). A VSE is defined as ing—Life Cycle Management—Guidelines for Pro- an enterprise, organization, department, or proj- cess Description ect having up to 25 people. A set of standards and guides has been developed according to a set of An increasing number of international, national, VSEs’ characteristics and needs. The guides are and industry standards describe process mod- based on subsets of appropriate standards ele- els. These models are developed for a range of ments, referred to as VSE profiles. The purpose purposes including process implementation and of a VSE profile is to define a subset of ISO/IEC assessment. The terms and descriptions used in international standards relevant to the VSEs’ such models vary in format, content, and level context. of prescription. ISO/IEC TR 24774:2010 pres- ISO/IEC TR 29110-5-1-2:2011 provides the ents guidelines for the elements used most fre- management and engineering guide to the basic quently in describing a process: the title, pur- VSE profile applicable to VSEs that do not pose, outcomes, activities, task, and information develop critical software. The generic profile item. Whilst the primary purpose of ISO/IEC TR group does not imply any specific application 24774:2010 is to encourage consistency in stan- domain. dard process reference models, the guidelines it provides can be applied to any process model developed for any purpose. The next standard may be viewed as an alternative to 12207 for individual projects. The 1074 standard explains how to define processes for A very small entity (VSE) is an enterprise, an use on a given project. The 12207 and 15288 organization, a department, or a project having standards, however, focus on defining processes up to 25 people. The ISO/IEC 29110 series “pro- for organizational adoption and repeated use on files” large standards, such as ISO/IEC 12207 for many projects. The current 1074 is the update of software and ISO/IEC 15288 for systems, into a standard that was a predecessor of 12207. smaller ones for VSEs. ISO 29110 is applicable to VSEs that do not develop critical systems or critical software. Profiles provide a roadmap allowing IEEE Std. 1074-2006 Standard for Developing a a start-up to grow a step at a time using the ISO Software Project Life Cycle Process 29110 management and engineering guides. ISO/IEC 29110 set of standards and technical This standard provides a process for creating a reports are targeted by audience such as VSEs, software project life cycle process (SPLCP). It is customers, or auditors. ISO/IEC 29110 is not primarily directed at the process architect for a intended to preclude the use of different life given software project. cycles approaches such as waterfall, iterative, incremental, evolutionary, or agile. B-16 SWEBOK® Guide V3.0

All of the standards described so far in this sec- • is applicable across all application domains tion provide a basis for defining processes. Some and sizes of organization; and users are interested in assessing and improving • may provide an objective benchmark their processes after implementation. The 15504 between organizations. series provides for process assessment; it is currently being revised and renumbered 330xx. The minimum set of requirements defined in ISO/IEC 15504-2:2003 ensures that assessment results are objective, impartial, consistent, repeat- ISO/IEC 15504 [ten parts] Information Technol- able, and representative of the assessed processes. ogy—Process Assessment Results of conformant process assessments may be compared when the scopes of the assessments ISO/IEC 15504-2:2003 defines the requirements are considered to be similar; for guidance on this for performing process assessment as a basis matter, refer to ISO/IEC 15504-4. for use in process improvement and capability determination. Process assessment is based on a two-dimen- Several other standards are mentioned here sional model containing a process dimension and because they are written as elaborations of the a capability dimension. The process dimension is processes of 12207 or 15288. They are allocated provided by an external process reference model to other KAs because each one deals with topics (such as 12207 or 15288), which defines a set of described in those other KAs. processes characterized by statements of process purpose and process outcomes. The capability dimension consists of a measurement framework IEEE Std. 828-2012 Standard for Configuration comprising six process capability levels and their Management in Systems and Software Engineering associated process attributes. See Software Configuration Management KA The assessment output consists of a set of process attribute ratings for each process assessed, IEEE Std. 14764-2006 (a.k.a. ISO/IEC 14764:2006) termed the process profile, and may also include Standard for Software Engineering—Software Life the capability level achieved by that process. Cycle Processes—Maintenance ISO/IEC 15504-2:2003 identifies the measure- See Software Maintenance KA ment framework for process capability and the requirements for ISO/IEC 15026-4:2012 Systems and Software Engi- neering—Systems and Software Assurance—Part 4: • performing an assessment; Assurance in the Life Cycle • process reference models; See Software Quality KA • process assessment models; • verifying conformity of process assessment. IEEE Std. 15939-2008 Standard Adoption of ISO/ IEC 15939:2007 Systems and Software Engineer- The requirements for process assessment ing—Measurement Process defined in ISO/IEC 15504-2:2003 form a struc- See Software Engineering Management KA ture that ISO/IEC 15940:2006 Information Technology— • facilitates self-assessment; Software Engineering Environment Services • provides a basis for use in process improve- See Software Engineering Models and ment and capability determination; Methods KA • takes into account the context in which the assessed process is implemented; IEEE Std. 16085-2006 (a.k.a. ISO/IEC 16085:2006) • produces a process rating; Standard for Systems and Software Engineering— • addresses the ability of the process to achieve Software Life Cycle Processes—Risk Management its purpose; See Software Engineering Management KA Appendix B B-17

ISO/IEC/IEEE 16326:2009 Systems and Soft- example. Neither S2ESC nor SC 7 has a standard ware Engineering—Life Cycle Processes—Project for agile development, but there is a standard Management for developing user documentation in an agile See Software Engineering Management KA project.

ISO/IEC/IEEE 29148:2011 Systems and Software Engineering—Life Cycle Processes—Requirements ISO/IEC/IEEE 26515:2012 Systems and Software Engineering Engineering—Developing User Documentation in an See Software Requirements KA Agile Environment

ISO/IEC/IEEE 26515:2012 specifies the way in Some users desire process standards usable which user documentation can be developed in for IT operations or IT service management. agile development projects. It is intended for use The ISO/IEC 20000 series describe IT service in all organizations that are using agile develop- management. The processes are less rigorously ment or are considering implementing their proj- defined than those of the aforementioned- engi ects using these techniques. It applies to people neering standards, but may be preferable for situ- or organizations producing suites of documen- ations where the risks of failure involve money tation, to those undertaking a single documen- or customer satisfaction rather than public health, tation project, and to documentation produced safety, and welfare. The ISO/IEC 20000 series internally, as well as to documentation contracted now extend to many parts. The foundation of to outside service organizations. ISO/IEC/IEEE the series, ISO/IEC 20000-1, is briefly described 26515:2012 addresses the relationship between below. the user documentation process and the life cycle documentation process in agile development. It describes how the information developer or proj- ISO/IEC 20000-1:2011 Information Technology— ect manager may plan and manage the user docu- Service Management—Part 1: Service Management mentation development in an agile environment. System Requirements It is intended neither to encourage nor to discour- age the use of any particular agile development ISO/IEC 20000-1:2011 is a service management tools or methods. system (SMS) standard. It specifies requirements for the service provider to plan, establish, implement, operate, monitor, review, maintain, and Many methodologies are based on semiformal improve an SMS. The requirements include the descriptions of the software to be constructed. design, transition, delivery and improvement of These range from simple descriptive notations services to fulfill agreed service requirements. to models that can be manipulated and tested and, in some cases, can generate code. Two relatively old techniques start the list; the first has IEEE has adopted the first two parts of the ISO/ been widely applied for modeling processes and IEC 20000 series. workflows.

SOFTWARE ENGINEERING MODELS AND METHODS IEEE Std. 1320.1-1998 Standard for Functional Mod- eling Language—Syntax and Semantics for IDEF0 Some approaches to software engineering use methods that cut across large parts of the life IDEF0 function modeling is designed to repre- cycle, rather than focusing on specific processes. sent the decisions, actions, and activities of an “Chief Programmer” was one traditional exam- existing or prospective organization or system. ple. “Agile development” (actually an example IDEF0 graphics and accompanying texts are pre- of traditional incremental delivery) is a current sented in an organized and systematic way to gain B-18 SWEBOK® Guide V3.0

understanding, support analysis, provide logic for The next two standards provide two versions of potential changes, specify requirements, and sup- the UML language. port system-level design and integration activities. IDEF0 may be used to model a wide variety of systems, composed of people, machines, mate- ISO/IEC 19501:2005 Information Technology— rials, computers, and information of all varieties, Open Distributed Processing—Unified Modeling and structured by the relationships among them, Language (UML) Version 1.4.2 both automated and nonautomated. For new systems, IDEF0 may be used first to define require- ISO/IEC 19501 describes the Unified Model- ments and to specify the functions to be carried ing Language (UML), a graphical language for out by the future system. As the basis of this visualizing, specifying, constructing, and docu- architecture, IDEF0 may then be used to design menting the artifacts of a software-intensive sys- an implementation that meets these requirements tem. The UML offers a standard way to write a and performs these functions. For existing sys- system’s blueprints, including conceptual things tems, IDEF0 can be used to analyze the functions such as business processes and system functions that the system performs and to record the means as well as concrete things such as programming by which these are done. language statements, database schemas, and reusable software components. IEEE Std. 1320.2-1998 Standard for Conceptual Modeling Language—Syntax and Semantics for ISO/IEC 19505:2012 [two parts] Information Tech- IDEF1X97 (IDEFobject) nology—Object Management Group Unified Model- ing Language (OMG UML) IDEF1X 97 consists of two conceptual modeling languages. The key-style language supports data/ ISO/IEC 19505 defines the Unified Modeling information modeling and is downward compat- Language (UML), revision 2. The objective of ible with the US government’s 1993 standard, UML is to provide system architects, software FIPS PUB 184. The identity-style language is engineers, and software developers with tools for based on the object model with declarative rules analysis, design, and implementation of software- and constraints. IDEF1X 97 identity style includes based systems as well as for modeling business constructs for the distinct but related components and similar processes. of object abstraction: interface, requests, and realization; utilizes graphics to state the interface; and defines a declarative, directly executable rule Two more standards build on the base of UML and constraint language for requests and realiza- to provide additional modeling capabilities: tions. IDEF1X 97 conceptual modeling supports implementation by relational databases, extended relational databases, object databases, and object ISO/IEC 19506:2012 Information Technology— programming languages. IDEF1X 97 is formally Object Management Group Architecture-Driven defined in terms of first order logic. A procedure Modernization (ADM)—Knowledge Discovery is given whereby any valid IDEF1X 97 model Meta-Model (KDM) can be transformed into an equivalent theory in first order logic. That procedure is then applied to ISO/IEC 19506:2012 defines a metamodel for rep- a metamodel of IDEF1X 97 to define the valid set resenting existing software assets, their associa- of IDEF1X 97 models. tions, and operational environments, referred to as the knowledge discovery metamodel (KDM). This is the first in the series of specifications related to In recent years, the UML notation has become software assurance (SwA) and architecture-driven popular for modeling software-intensive systems. modernization (ADM) activities. KDM facilitates Appendix B B-19

projects that involve existing software systems Within systems and software engineering, com- by insuring interoperability and exchange of data puter-aided software engineering (CASE) tools between tools provided by different vendors. represent a major part of the supporting technologies used to develop and maintain informa- ISO/IEC 19507:2012 Information Technology— tion technology systems. Their selection must be Object Management Group Object Constraint Lan- carried out with careful consideration of both the guage (OCL) technical and management requirements. ISO/IEC 14102:2008 defines both a set of pro- ISO/IEC 19507:2012 defines the Object Con- cesses and a structured set of CASE tool char- straint Language (OCL), version 2.3.1. OCL ver- acteristics for use in the technical evaluation and sion 2.3.1 is the version of OCL that is aligned the ultimate selection of a CASE tool. It follows with UML 2.3 and MOF 2.0. the software product evaluation model defined in ISO/IEC 14598-5:1998. ISO/IEC 14102:2008 adopts the general model Some organizations invest in software engi- of software product quality characteristics and neering environments (SEE) to assist in the subcharacteristics defined in ISO/IEC 9126- construction of software. An SEE, per se, is not 1:2001 and extends these when the software a replacement for sound processes. However, a product is a CASE tool; it provides product char- suitable SEE must support the processes that acteristics unique to CASE tools. have been chosen by the organization.

The next document provides guidance on how ISO/IEC 15940:2006 Information Technology— to adopt CASE tools, once selected. Software Engineering Environment Services

ISO/IEC 15940:2006 defines software engineering IEEE Std. 14471-2010 Guide—Adoption of ISO/IEC environment (SEE) services conceptually in a refer- TR 14471:2007 Information Technology—Software ence model that can be adapted to any SEEs to auto- Engineering—Guidelines for the Adoption of CASE mate one or more software engineering activities. Tools It describes services that support the process definitions as in ISO/IEC 12207 so that the set of SEE The purpose of ISO/IEC TR 14471:2007 is to services is compatible with ISO/IEC 12207. ISO/ provide a recommended practice for CASE adop- IEC 15940:2006 can be used either as a general ref- tion. It provides guidance in establishing pro- erence or to define an automated software process. cesses and activities that are to be applied for the successful adoption of CASE technology. The use of ISO/IEC TR 14471:2007 will help The selection of tooling for a software engineering to maximize the return and minimize the risk of environment is itself a difficult task. Two standards investing in CASE technology. However, ISO/ provide some assistance. ISO/IEC 14102:2008 IEC TR 14471:2007 does not establish compli- defines both a set of processes and a structured set of ance criteria. computer-aided software engineering (CASE) tool It is best used in conjunction with ISO/IEC characteristics for use in the technical evaluation 14102 for CASE tool evaluation and selection. It and the ultimate selection of a CASE tool. neither dictates nor advocates particular development standards, software processes, design methods, methodologies, techniques, programming IEEE Std. 14102-2010 Standard Adoption of ISO/ languages, or life cycle paradigms. IEC 14102:2008 Information Technology—Guide- line for the Evaluation and Selection of CASE Tools B-20 SWEBOK® Guide V3.0

Within a software engineering environment, it for the Application of ISO 9001:2000 to Computer is important for the various tools to interoperate. Software The following standards provide a scheme for interconnection. ISO/IEC 90003 provides guidance for organizations in the application of ISO 9001:2000 to the acquisition, supply, development, operation, and IEEE Std. 1175.1-2002 Guide for CASE Tool Inter- maintenance of computer software and related connections—Classification and Description support services. ISO/IEC 90003:2004 does not add to or otherwise change the requirements of IEEE Std. 1175.2-2006 Recommended Practice for ISO 9001:2000. CASE Tool Interconnection—Characterization of The guidelines provided in ISO/IEC Interconnections 90003:2004 are not intended to be used as assessment criteria in quality management system IEEE Std. 1175.3-2004 Standard for CASE Tool registration/certification. Interconnections—Reference Model for Specifying The application of ISO/IEC 90003:2004 is Software Behavior appropriate to software that is

IEEE Std. 1175.4-2008 Standard for CASE Tool • part of a commercial contract with another Interconnections—Reference Model for Specifying organization, System Behavior • a product available for a market sector, • used to support the processes of an The purpose of this family of standards is to spec- organization, ify a common set of modeling concepts based • embedded in a hardware product, or on those found in commercial CASE tools for • related to software services. describing the operational behavior of a software system. These standards establish a uniform, Some organizations may be involved in all integrated model of software concepts related to the above activities; others may specialize in software functionality. They also provide a tex- one area. Whatever the situation, the organiza- tual syntax for expressing the common properties tion’s quality management system should cover (attributes and relationships) of those concepts as all aspects (software related and nonsoftware they have been used to model software behavior. related) of the business. ISO/IEC 90003:2004 identifies the issues which should be addressed and is independent SOFTWARE QUALITY of the technology, life cycle models, development processes, sequence of activities, and One viewpoint of software quality starts with organizational structure used by an organiza- ISO 9001, Quality Management Requirements, tion. Additional guidance and frequent ref- dealing with quality policy throughout an orga- erences to the ISO/IEC JTC 1/SC 7 software nization. The terminology of that standard may engineering standards are provided to assist in be unfamiliar to software professionals, and the application of ISO 9001:2000: in particu- quality management auditors may be unfamiliar lar, ISO/IEC 12207, ISO/IEC TR 9126, ISO/ with software jargon. The following standard IEC 14598, ISO/IEC 15939, and ISO/IEC TR describes the relationship between ISO 9001 and 15504. ISO/IEC 12207. Unfortunately, the current version refers to obsolete editions of both; a replacement is in progress: The ISO 9001 approach posits an organization-level quality management process paired with project-level quality assurance planning IEEE Std. 90003-2008 Guide—Adoption of ISO/ to achieve the organizational goals. IEEE 730 IEC 90003:2004 Software Engineering—Guidelines describes project-level quality planning. It is Appendix B B-21

currently aligned with an obsolete edition of SQuaRE provides 12207, but a revision is being prepared. • terms and definitions, • reference models, IEEE Std. 730-2002 Standard for Software Quality • guides Assurance Plans • standards for requirements specification, planning and management, measurement, The standard specifies the format and content of and evaluation purposes. software quality assurance plans.

The next SQuaRE standard provides a taxon- Another viewpoint of software quality begins omy of software quality characteristics that may with enumerating the desired characteristics of a be useful in selecting characteristics relevant to a software product and selecting measures or other specific project: evaluations to determine if the desired level of characteristics has been achieved. The so-called SQuaRE (software product quality requirements ISO/IEC 25010:2011 Systems and Software Engi- and evaluation) series of SC 7 standards covers neering—Systems and Software Quality Require- this approach in great detail. ments and Evaluation (SQuaRE)—System and Soft- ware Quality Models

ISO/IEC 25000 through 25099 Software Engineer- ISO/IEC 25010:2011 defines the following: ing—Software Product Quality Requirements and Evaluation (SQuaRE) 1. A quality in-use model composed of five characteristics (some of which are further subdivided into subcharacteristics) that A few of the SQuaRE standards are selected relate to the outcome of interaction when a below for particular attention. The first is the product is used in a particular context of use. overall guide to the series. This system model is applicable to the complete human-computer system, including both computer systems in use and software ISO/IEC 25000:2005 Software Engineering—Soft- products in use. ware Product Quality Requirements and Evaluation 2. A product quality model composed of eight (SQuaRE)—Guide to SQuaRE characteristics (which are further subdivided into subcharacteristics) that relate to static ISO/IEC 25000:2005 provides guidance for the properties of software and dynamic proper- use of the new series of international standards ties of the computer system. The model is named Software product Quality Requirements applicable to both computer systems and and Evaluation (SQuaRE). The purpose of this software products. guide is to provide a general overview of SQuaRE contents, common reference models, and defini- The characteristics defined by both models tions, as well as the relationship among the docu- are relevant to all software products and comments, allowing users of this guide a good under- puter systems. The characteristics and subchar- standing of those international standards. This acteristics provide consistent terminology for document contains an explanation of the transi- specifying, measuring, and evaluating system tion process between the old ISO/IEC 9126 and and software product quality. They also provide the 14598 series and SQuaRE, and also presents a set of quality characteristics against which information on how to use the ISO/IEC 9126 and stated quality requirements can be compared for 14598 series in their previous form. completeness. B-22 SWEBOK® Guide V3.0

Although the scope of the product quality Evaluation (SQuaRE)—Common Industry Format model is intended to be software and computer (CIF) for Usability systems, many of the characteristics are also relevant to wider systems and services. A family of international standards, named the ISO/IEC 25012 contains a model for data qual- Common Industry Formats (CIF), documents ity that is complementary to this model. the specification and evaluation of the usability The scope of the models excludes purely func- of interactive systems. It provides a general over- tional properties, but it does include functional view of the CIF framework and contents, defini- suitability. tions, and the relationship of the framework ele- The scope of application of the quality models ments. The intended users of the framework are includes supporting specification and evaluation identified, as well as the situations in which the of software and software-intensive computer sys- framework may be applied. The assumptions and tems from different perspectives by those who are constraints of the framework are also enumerated. associated with their acquisition, requirements, The framework content includes the following: development, use, evaluation, support, maintenance, quality assurance and control, and audit. • consistent terminology and classification of The models can, for example, be used by devel- specification, evaluation, and reporting; opers, acquirers, quality assurance and control • a definition of the type and scope of formats staff, and independent evaluators, particularly and the high-level structure to be used for those responsible for specifying and evaluating documenting required information and the software product quality. Activities during prod- results of evaluation. uct development that can benefit from the use of the quality models include The CIF family of standards is applicable to software and hardware products used for pre- • identifying software and system requirements; defined tasks. The information items are intended • validating the comprehensiveness of a to be used as part of system-level documentation requirements definition; resulting from development processes such as • identifying software and system design those in ISO 9241-210 and ISO/IEC JTC 1/SC 7 objectives; process standards. • identifying software and system testing The CIF family focuses on documenting those objectives; elements needed for design and development of • identifying quality control criteria as part of usable systems, rather than prescribing a specific quality assurance; process. It is intended to be used in conjunction • identifying acceptance criteria for a software with existing international standards, includ- product and/or software-intensive computer ing ISO 9241, ISO 20282, ISO/IEC 9126, and system; the SQuaRE series (ISO/IEC 25000 to ISO/IEC • establishing measures of quality characteris- 25099). tics in support of these activities. The CIF family of standards does not prescribe any kind of method, life cycle or process.

Some documents in the SQuaRE series deal specifically with the characteristic of usability. The Not everyone agrees with the taxonomy of Common Industry Format (CIF) for usability report- quality characteristics in ISO/IEC 25010. That ing began at the US National Institute for Standards standard has a quality factor called “reliability” and Technology (NIST) and was moved into ISO/ that has subfactors of maturity, availability, fault IEC JTC 1/SC 7 for purposes of standardization. tolerance, and recoverability. IEC TC 65, which has responsibility for standards on “dependability,” defines that term as a nonquantitative com- ISO/IEC 25060 through 25064 Software Engineer- posite of reliability, maintainability, and mainte- ing—Software Product Quality Requirements and nance support. Others use the term “reliability” Appendix B B-23

to denote a measure defined by a mathematical One approach to achieving software quality is equation. The disagreement over the use of these to perform an extensive program of verification words means that the standards on the subject are and validation. IEEE Std. 1012 is probably the inherently unaligned. A few will be noted below, world’s most widely applied standard on this sub- but the words like those noted above may mean ject. A revision was recently published. different things in different standards.

IEEE Std. 1012-2012 Standard for System and Soft- IEEE Std. 982.1-2005 Standard for Dictionary of ware Verification and Validation Measures of the Software Aspects of Dependability Verification and validation (V&V) processes are A standard dictionary of measures of the soft- used to determine whether the development prod- ware aspects of dependability for assessing and ucts of a given activity conform to the require- predicting the reliability, maintainability, and ments of that activity and whether the product availability of any software system; in particular, satisfies its intended use and user needs. V&V life it applies to mission critical software systems. cycle process requirements are specified for different integrity levels. The scope of V&V processes IEEE Std. 1633-2008 Recommended Practice for encompasses systems, software, and hardware, and Software Reliability it includes their interfaces. This standard applies to systems, software, and hardware being developed, The methods for assessing and predicting the reli- maintained, or reused [legacy, commercial off-the- ability of software, based on a life cycle approach shelf (COTS), nondevelopmental items]. The term to software reliability engineering, are prescribed in software also includes firmware and microcode, this recommended practice. It provides information and each of the terms system, software, and hard- necessary for the application of software reliability ware includes documentation. V&V processes (SR) measurement to a project, lays a foundation include the analysis, evaluation, review, inspec- for building consistent methods, and establishes tion, assessment, and testing of products. the basic principle for collecting the data needed to assess and predict the reliability of software. The recommended practice prescribes how any user can There are other standards that support the veri- participate in SR assessments and predictions. fication and validation processes. One describes techniques for performing reviews and audits during a software project. IEEE has an overall standard for software product quality that has a scope similar to the ISO/IEC 250xx series described previously. Its IEEE Std. 1028-2008 Standard for Software Reviews terminology differs from the ISO/IEC series, but and Audits it is substantially more compact. Five types of software reviews and audits, together with procedures required for the execu- IEEE Std. 1061-1998 Standard for Software Quality tion of each type, are defined in this standard. Metrics Methodology This standard is concerned only with the reviews and audits; procedures for determining the neces- A methodology for establishing quality require- sity of a review or audit are not defined, and the ments and identifying, implementing, analyzing, disposition of the results of the review or audit and validating the process and product software is not specified. Types included are management quality metrics is defined. The methodology reviews, technical reviews, inspections, walk- spans the entire software life cycle. throughs, and audits. B-24 SWEBOK® Guide V3.0

In many cases, a database of software anoma- use of each part and the combined use of multiple lies is used to support verification and validation parts. Coverage of assurance for a service being activities. The following standard suggests how operated and managed on an ongoing basis is not anomalies should be classified. covered in ISO/IEC 15026.

IEEE Std. 1044-2009 Standard for Classification for The second part of the standard describes the Software Anomalies structure of an “assurance case,” which is intended as a structured argument that the critical property This standard provides a uniform approach to the has been achieved. It is a generalization of various classification of software anomalies, regardless domain-specific constructs like “safety cases.” of when they originate or when they are encountered within the project, product, or system life cycle. Classification data can be used for a vari- IEEE Std. 15026.2-2011 Standard Adoption of ISO/ ety of purposes, including defect causal analy- IEC 15026-2:2011 Systems and Software Engineer- sis, project management, and software process ing—Systems and Software Assurance—Part 2: improvement (e.g., to reduce the likelihood of Assurance Case defect insertion and/or increase the likelihood of early defect detection). ISO/IEC 15026-2:2011 is adopted by this standard. ISO/IEC 15026-2:2011 specifies minimum requirements for the structure and contents of an In some systems, one particular property of the assurance case to improve the consistency and software is so important that it requires special comparability of assurance cases and to facili- treatment beyond that provided by a conven- tate stakeholder communications, engineering tional verification and validation program. The decisions, and other uses of assurance cases. An emerging term for this sort of treatment is “sys- assurance case includes a top-level claim for a tems and software assurance.” Examples include property of a system or product (or set of claims), safety, privacy, high security, and ultrareliability. systematic argumentation regarding this claim, The 15026 standard is under development to deal and the evidence and explicit assumptions that with such situations. The first part of the four-part underlie this argumentation. Arguing through standard provides terminology and concepts used multiple levels of subordinate claims, this struc- in the remaining parts. It was first written before tured argumentation connects the top-level claim the other parts and is now being revised for com- to the evidence and assumptions. Assurance plete agreement with the others. cases are generally developed to support claims in areas such as safety, reliability, maintainability, human factors, operability, and security, IEEE Std. 15026.1-2011 Trial-Use Standard Adop- although these assurance cases are often called tion of ISO/IEC TR 15026-1:2010 Systems and Soft- by more specific names, e.g., safety case or reli- ware Engineering—Systems and Software Assur- ability and maintainability (R&M) case. ISO/IEC ance—Part 1: Concepts and Vocabulary 15026-2:2011 does not place requirements on the quality of the contents of an assurance case This trial-use standard adopts ISO/IEC TR and does not require the use of a particular termi- 15026-1:2010, which defines terms and estab- nology or graphical representation. Likewise, it lishes an extensive and organized set of concepts places no requirements on the means of physical and their relationships for software and systems implementation of the data, including no require- assurance, thereby establishing a basis for shared ments for redundancy or colocation. understanding of the concepts and principles central to ISO/IEC 15026 across its user communities. It provides information to users of the sub- In many systems, some portions are critical to sequent parts of ISO/IEC 15026, including the achieving the desired property while others are only Appendix B B-25

incidental. For example, the flight control system of TR 15026-1 provides additional information and an airliner is critical to safety, but the microwave references to aid users of ISO/IEC 15026-3:2011. oven is not. Conventionally, the various portions ISO/IEC 15026-3:2011 does not require the are assigned “criticality levels” to indicate their sig- use of the assurance cases described by ISO/IEC nificance to the overall achievement of the property. 15026-2 but describes how integrity levels and The third part of ISO/IEC 15026 describes how that assurance cases can work together, especially in is done. This part will be revised for better fit with the definition of specifications for integrity levels the remainder of the 15026 standard. or by using integrity levels within a portion of an assurance case.

ISO/IEC 15026-3:2011 Systems and Software Engi- neering—Systems and Software Assurance—Part 3: The final part of 15026 provides additional System Integrity Levels guidance for executing the life cycle processes of 12207 and 15288 when a system or software is ISO/IEC 15026-3:2011 specifies the concept of required to achieve an important property. integrity levels with corresponding integrity level requirements that are required to be met in order to show the achievement of the integrity level. It ISO/IEC 15026-4:2012 Systems and Software Engi- places requirements on and recommends meth- neering—Systems and Software Assurance—Part 4: ods for defining and using integrity levels and Assurance in the Life Cycle their integrity level requirements, including the assignment of integrity levels to systems, soft- This part of ISO/IEC 15026 gives guidance and ware products, their elements, and relevant exter- recommendations for conducting selected pro- nal dependences. cesses, activities and tasks for systems and software ISO/IEC 15026-3:2011 is applicable to sys- products requiring assurance claims for properties tems and software and is intended for use by: selected for special attention, called critical properties. This part of ISO/IEC 15026 specifies a prop- • definers of integrity levels such as industry erty-independent list of processes, activities, and and professional organizations, standards tasks to achieve the claim and show the achieve- organizations, and government agencies; ment of the claim. This part of ISO/IEC 15026 • users of integrity levels such as developers establishes the processes, activities, tasks, guidance, and maintainers, suppliers and acquirers, and recommendations in the context of a defined users, and assessors of systems or software, life cycle model and set of life cycle processes for and for the administrative and technical sup- system and/or software life cycle management. port of systems and/or software products.

One important use of integrity levels is by sup- The next standard deals with a property— pliers and acquirers in agreements; for example, safety—that is often identified as critical. It was to aid in assuring safety, economic, or security originally developed in cooperation with the US characteristics of a delivered system or product. nuclear power industry. ISO/IEC 15026-3:2011 does not prescribe a specific set of integrity levels or their integrity level requirements. In addition, it does not pre- IEEE Std. 1228-1994 Standard for Software Safety scribe the way in which integrity level use is inte- Plans grated with the overall system or software engineering life cycle processes. The minimum acceptable requirements for the ISO/IEC 15026-3:2011 can be used alone or content of a software safety plan are established. with other parts of ISO/IEC 15026. It can be used This standard applies to the software safety plan with a variety of technical and specialized risk used for the development, procurement, mainte- analysis and development approaches. ISO/IEC nance, and retirement of safety-critical software. B-26 SWEBOK® Guide V3.0

This standard requires that the plan be prepared Knowledge (SWEBOK) within the context of the system safety pro- See General gram. Only the safety aspects of the software are included. This standard does not contain special provisions required for software used in distrib- An SC 7 standard provides a framework for uted systems or in parallel processors. comparisons among certifications of software engineering professionals. That standard states that the areas considered in certification must be Classical treatments suggest that “verification” mapped to the SWEBOK Guide. deals with static evaluation methods and that “testing” deals with dynamic evaluation methods. Recent treatments, including ISO/IEC draft ISO/IEC 24773:2008 Software Engineering—Certi- 29119, are blurring this distinction, though, so fication of Software Engineering Professionals testing standards are mentioned here. ISO/IEC 24773:2008 establishes a framework for comparison of schemes for certifying software IEEE Std. 829-2008 Standard for Software and Sys- engineering professionals. A certification scheme tem Test Documentation is a set of certification requirements for software See Software Testing KA engineering professionals. ISO/IEC 24773:2008 specifies the items that a scheme is required to IEEE Std. 1008-1987 Standard for Software Unit contain and indicates what should be defined for Testing each item. See Software Testing KA ISO/IEC 24773:2008 will facilitate the portability of software engineering professional cer- IEEE Std. 26513-2010 Standard Adoption of ISO/ tifications between different countries or orga- IEC 26513:2009 Systems and Software Engineer- nizations. At present, different countries and ing—Requirements for Testers and Reviewers of organizations have adopted different approaches Documentation on the topic, which are implemented by means See Software Testing KA of regulations and bylaws. The intention of ISO/ IEC 24773:2008 is to be open to these individ- ISO/IEC/IEEE 29119 [four parts] (Draft) Software ual approaches by providing a framework for and Systems Engineering—Software Testing expressing them in a common scheme that can See Software Testing KA lead to understanding.

SOFTWARE ENGINEERING SC 7 is currently drafting a guide that will sup- PROFESSIONAL PRACTICE plement 24773.

IEEE is a provider of products related to the cer- SOFTWARE ENGINEERING ECONOMICS tification of professional practitioners of software engineering. The first has already been described, No standards are allocated to this KA. the Guide to the Software Engineering Body of Knowledge. The SWEBOK Guide has been adopted COMPUTING FOUNDATIONS by ISO/IEC as an outline of the knowledge that professional software engineers should have. No standards are allocated to this KA.

MATHEMATICAL FOUNDATIONS ISO/IEC TR 19759:2005 Software Engineer- ing—Guide to the Software Engineering Body of No standards are allocated to this KA. Appendix B B-27

ENGINEERING FOUNDATIONS The definitions contained in ISO/IEC/IEEE 24765, System and Software Vocabulary, are No standards are allocated to this KA. freely available at www.computer.org/sevocab. However, the vast majority of standards are not STAYING CURRENT free. ISO/IEC standards are generally purchased from the national standards organization of the This article was obsolescent the moment it was country in which one lives. For example, in the drafted. Some readers will need to know how US, international standards can be purchased to get current designations and descriptions of from the American National Standards Institute standards. This section describes some helpful at http://webstore.ansi.org/. Alternatively, stan- resources. dards can be purchased directly from ISO/IEC at www.iso.org/iso/store.htm. It should be noted WHERE TO FIND STANDARDS that each individual nation is free to set its own prices, so it may be helpful to check both sources. The list of standards published for ISO/IEC JTC IEEE standards may be available to you for 1/SC 7 can be found at www.iso.org/iso/iso_ free if your employer or library has a subscription catalogue/catalogue_tc/catalogue_tc_browse. to IEEE Xplore: http://ieeexplore.ieee.org/. Some htm?commid=45086. subscriptions to Xplore provide access only to Because the URL might change, readers might the abstracts of standards; the full text may then have to navigate to the list. Begin at www.iso.org/ be purchased via Xplore. Alternatively, standards iso/store.htm, then click on “browse standards may be purchased via the IEEE standards store at catalogue,” then “browse by TC,” then “JTC 1,” www.techstreet.com/ieeegate.html. It should be then “SC 7.” noted that IEEE-SA sometimes bundles standards Finding the current list of standards for S2ESC into groups available at a substantial discount. is a bit more difficult. Begin at http://standards. Finally, the reader should note that standards ieee.org/. In the search box under “Find Stan- that IEEE has adopted from ISO/IEC, standards dards,” type “S2ESC.” This should produce a that ISO/IEC has “fast-tracked” from IEEE, and list of published standards for which S2ESC is standards that were jointly developed or revised responsible. are available from both sources. For all standards Keep in mind that the searchable databases described in this article, the IEEE version and the are compilations. Like any such database, they ISO/IEC version are substantively identical. The can contain errors that lead to incomplete search respective versions may have different front and results. back matter but the bodies are identical.

WHERE TO OBTAIN THE STANDARDS WHERE TO SEE THE SWEBOK GUIDE

Some readers will want to obtain standards The SWEBOK Guide is published under an IEEE described in this article. The first thing to copyright. The current version of the SWEBOK know is that some international standards are Guide is available free to the public at www. available free for individual use. The current swebok.org/. The ISO/IEC adoption of the list of ISO/IEC standards available under these SWEBOK Guide, ISO/IEC TR 19759, is one of terms is located at http://standards.iso.org/ittf/ the freely available standards. PubliclyAvailableStandards/index.html. One of the publicly available standards is the ISO/IEC adoption of the SWEBOK Guide, ISO/ IEC 19759. B-28 SWEBOK® Guide V3.0

SUMMARY LIST OF THE STANDARDS

Number and Title (listed in order of number) Most Relevant KA IEEE Std. 730-2002 Standard for Software Quality Assurance Plans SW Quality IEEE Std. 828-2012 Standard for Configuration Management in SW Configuration Systems and Software Engineering Management IEEE Std. 829-2008 Standard for Software and System Test SW Testing Documentation IEEE Std. 982.1-2005 Standard for Dictionary of Measures of the SW Quality Software Aspects of Dependability IEEE Std. 1008-1987 Standard for Software Unit Testing SW Testing IEEE Std. 1012-2012 Standard for System and Software Verification and SW Quality Validation IEEE Std. 1016-2009 Standard for Information Technology—Systems SW Design Design—Software Design Descriptions IEEE Std. 1028-2008 Standard for Software Reviews and Audits SW Quality IEEE Std. 1044-2009 Standard for Classification for Software SW Quality Anomalies IEEE Std. 1061-1998 Standard for Software Quality Metrics SW Quality Methodology SW Engineering IEEE Std. 1062-1998 Recommended Practice for Software Acquisition Management IEEE Std. 1074-2006 Standard for Developing a Software Project Life SW Engineering Cycle Process Process IEEE Std. 1175.1-2002 Guide for CASE Tool Interconnections— SW Engineering Classification and Description Models and Methods IEEE Std. 1175.2-2006 Recommended Practice for CASE Tool SW Engineering Interconnection—Characterization of Interconnections Models and Methods IEEE Std. 1175.3-2004 Standard for CASE Tool Interconnections— SW Engineering Reference Model for Specifying Software Behavior Models and Methods IEEE Std. 1175.4-2008 Standard for CASE Tool Interconnections— SW Engineering Reference Model for Specifying System Behavior Models and Methods IEEE Std. 1220-2005 (a.k.a. ISO/IEC 26702:2007) Standard for SW Engineering Application and Management of the Systems Engineering Process Process IEEE Std. 1228-1994 Standard for Software Safety Plans SW Quality IEEE Std. 1320.1-1998 Standard for Functional Modeling Language— SW Engineering Syntax and Semantics for IDEF0 Models and Methods IEEE Std. 1320.2-1998 Standard for Conceptual Modeling Language— SW Engineering Syntax and Semantics for IDEF1X97 (IDEFobject) Models and Methods IEEE Std. 1490-2011 Guide—Adoption of the Project Management SW Engineering Institute (PMI®) Standard, A Guide to the Project Management Body Management of Knowledge (PMBOK® Guide)—Fourth Edition IEEE Std. 1517-2010 Standard for Information Technology—System SW Engineering and Software Life Cycle Processes—Reuse Processes Process Appendix B B-29

Number and Title (listed in order of number) Most Relevant KA IEEE Std. 1633-2008 Recommended Practice for Software Reliability SW Quality IEEE Std. 12207-2008 (a.k.a. ISO/IEC 12207:2008) Standard for SW Engineering Systems and Software Engineering—Software Life Cycle Processes Process IEEE Std. 14102-2010 Standard Adoption of ISO/IEC 14102:2008 SW Engineering Information Technology—Guideline for the Evaluation and Selection of Models and Methods CASE Tools ISO/IEC 14143 [six parts] Information Technology—Software SW Requirements Measurement—Functional Size Measurement IEEE Std. 14471-2010 Guide—Adoption of ISO/IEC TR 14471:2007 SW Engineering Information Technology—Software Engineering—Guidelines for the Models and Methods Adoption of CASE Tools IEEE Std. 14764-2006 (a.k.a. ISO/IEC 14764:2006) Standard for SW Maintenance Software Engineering—Software Life Cycle Processes—Maintenance IEEE Std. 15026.1-2011 Trial-Use Standard Adoption of ISO/IEC TR 15026-1:2010 Systems and Software Engineering—Systems and SW Quality Software Assurance—Part 1: Concepts and Vocabulary IEEE Std. 15026.2-2011 Standard Adoption of ISO/IEC 15026- 2:2011 Systems and Software Engineering—Systems and Software SW Quality Assurance—Part 2: Assurance Case ISO/IEC 15026-3 Systems and Software Engineering—Systems and SW Quality Software Assurance—Part 3: System Integrity Levels ISO/IEC 15026-4:2012 Systems and Software Engineering—Systems SW Quality and Software Assurance—Part 4: Assurance in the Life Cycle IEEE Std. 15288-2008 (a.k.a. ISO/IEC 15288:2008) Standard for SW Engineering Systems and Software Engineering—System Life Cycle Processes Process ISO/IEC/IEEE 15289:2011 Systems and Software Engineering— SW Engineering Content of Life-Cycle Information Products (Documentation) Process ISO/IEC 15504 [ten parts] Information Technology—Process SW Engineering Assessment Process IEEE Std. 15939-2008 Standard Adoption of ISO/IEC 15939:2007 SW Engineering Systems and Software Engineering—Measurement Process Management ISO/IEC 15940:2006 Information Technology—Software Engineering SW Engineering Environment Services Models and Methods IEEE Std. 16085-2006 (a.k.a. ISO/IEC 16085:2006) Standard for SW Engineering Systems and Software Engineering—Software Life Cycle Processes— Management Risk Management ISO/IEC/IEEE 16326:2009 Systems and Software Engineering—Life SW Engineering Cycle Processes—Project Management Management ISO/IEC 19501:2005 Information Technology—Open Distributed SW Engineering Processing—Unified Modeling Language (UML) Version 1.4.2 Models and Methods B-30 SWEBOK® Guide V3.0

Number and Title (listed in order of number) Most Relevant KA ISO/IEC 19505:2012 [two parts] Information Technology—Object SW Engineering Management Group Unified Modeling Language (OMG UML) Models and Methods ISO/IEC 19506:2012 Information Technology—Object Management SW Engineering Group Architecture-Driven Modernization (ADM)—Knowledge Models and Methods Discovery Meta-Model (KDM) ISO/IEC 19507:2012 Information Technology—Object Management SW Engineering Group Object Constraint Language (OCL) Models and Methods ISO/IEC TR 19759:2005 Software Engineering—Guide to the Software [General] Engineering Body of Knowledge (SWEBOK) ISO/IEC 19761:2011 Software Engineering—COSMIC: A Functional SW Requirements Size Measurement Method ISO/IEC 20000-1:2011 Information Technology—Service SW Engineering Management—Part 1: Service management system requirements Process ISO/IEC 20926:2009 Software and Systems Engineering—Software SW Requirements Measurement—IFPUG Functional Size Measurement Method ISO/IEC 20968:2002 Software Engineering—Mk II Function Point SW Requirements Analysis—Counting Practices Manual ISO/IEC 24570:2005 Software Engineering—NESMA Functional Size Measurement Method Version 2.1—Definitions and Counting SW Requirements Guidelines for the Application of Function Point Analysis IEEE Std. 24748.1-2011 Guide—Adoption of ISO/IEC TR 24748-1:2010 SW Engineering Systems and Software Engineering—Life Cycle Management—Part 1: Process Guide for Life Cycle Management IEEE Std. 24748.2-2012 Guide—Adoption of ISO/IEC TR 24748-2:2011 Systems and Software Engineering—Life Cycle Management—Part SW Engineering 2: Guide to the Application of ISO/IEC 15288 (System Life Cycle Process Processes) IEEE Std. 24748-3:2012 Guide—Adoption of ISO/IEC TR 24748-3:2011 Systems and Software Engineering—Life Cycle Management—Part SW Engineering 3: Guide to the Application of ISO/IEC 12207 (Software Life Cycle Process Processes) ISO/IEC/IEEE 24765:2010 Systems and Software [General] Engineering—Vocabulary ISO/IEC TR 24772:2013 Information technology—Programming Languages — Guidance to Avoiding Vulnerabilities in Programming SW Construction Languages through Language Selection and Use ISO/IEC 24773:2008 Software Engineering—Certification of Software SW Engineering Engineering Professionals Professional Practice IEEE Std. 24774:2012 Guide—Adoption of ISO/IEC TR 24474:2010 SW Engineering Systems and Software Engineering—Life Cycle Management— Process Guidelines for Process Description ISO/IEC 25000:2005 Software Engineering—Software Product Quality SW Quality Requirements and Evaluation (SQuaRE)—Guide to SQuaRE Appendix B B-31

Number and Title (listed in order of number) Most Relevant KA ISO/IEC 25000 through 25099 Software Engineering—Software SW Quality Product Quality Requirements and Evaluation (SQuaRE) ISO/IEC 25010:2011 Systems and Software Engineering—Systems and Software Quality Requirements and Evaluation (SQuaRE)—System SW Quality and Software Quality Models ISO/IEC 25060 through 25064 Software Engineering—Software Product Quality Requirements and Evaluation (SQuaRE)—Common SW Quality Industry Format (CIF) for Usability ISO/IEC/IEEE 26511:2012 Systems and Software Engineering— SW Engineering Requirements for Managers of User Documentation Management ISO/IEC/IEEE 26512:2011 Systems and Software Engineering— SW Engineering Requirements for Acquirers and Suppliers of User Documentation Management IEEE Std. 26513-2010 Standard Adoption of ISO/IEC 26513:2009 Systems and Software Engineering—Requirements for Testers and SW Testing Reviewers of Documentation IEEE Std. 26514-2010 Standard Adoption of ISO/IEC 26514:2008 Systems and Software Engineering—Requirements for Designers and SW Design Developers of User Documentation ISO/IEC/IEEE 26515:2012 Systems and Software Engineering— SW Engineering Developing User Documentation in an Agile Environment Models and Methods ISO/IEC 29110 [several parts] Software Engineering—Lifecycle SW Engineering Profiles for Very Small Entities (VSE) Process ISO/IEC/IEEE 29119 [four parts] (Draft) Software and Systems SW Testing Engineering—Software Testing ISO/IEC/IEEE 29148:2011 Systems and Software Engineering—Life SW Requirements Cycle Processes—Requirements Engineering ISO/IEC/IEEE 42010:2011 Systems and Software Engineering— SW Design Architecture Description IEEE Std. 90003:2008 Guide—Adoption of ISO/IEC 90003:2004 Software Engineering—Guidelines for the Application of ISO SW Quality 9001:2000 to Computer Software APPENDIX C

CONSOLIDATED REFERENCE LIST

The Consolidated Reference List identifies all [4*] F. Bott et al., Professional Issues in recommended reference materials (to the level of Software Engineering, 3rd ed., Taylor & section number) that accompany the breakdown Francis, 2000. of topics within each knowledge area (KA). This Consolidated Reference List is adopted by the [5*] J.G. Brookshear, Computer Science: An software engineering certification and associated Overview, 10th ed., Addison-Wesley, 2008. professional development products offered by the IEEE Computer Society. KA Editors used the ref- [6*] D. Budgen, Software Design, 2nd ed., erences allocated to their KA by the Consolidated Addison-Wesley, 2003. Reference List as their Recommended References. Collectively this Consolidated Reference List is [7*] E.W. Cheney and D.R. Kincaid, Numerical Mathematics and Computing, 6th ed., • Complete: Covering the entire scope of the Brooks/Cole, 2007. SWEBOK Guide. • Sufficient: Providing enough information to [8*] P. Clements et al., Documenting Software describe “generally accepted” knowledge. Architectures: Views and Beyond, 2nd ed., • Consistent: Not providing contradictory Pearson Education, 2010. knowledge nor conflicting practices. • Credible: Recognized as providing expert [9*] R.E. Fairley, Managing and Leading treatment. Software Projects, Wiley-IEEE Computer • Current: Treating the subject in a manner that Society Press, 2009. is commensurate with currently generally accepted knowledge. [10*] D. Galin, Software Quality Assurance: • Succinct: As short as possible (both in num- From Theory to Implementation, Pearson ber of reference items and in total page Education Limited, 2004. count) without failing other objectives. [11*] E. Gamma et al., Design Patterns: [1*] J.H. Allen et al., Software Security Elements of Reusable Object-Oriented Engineering: A Guide for Project Software, 1st ed., Addison-Wesley Managers, Addison-Wesley, 2008. Professional, 1994.

[2*] M. Bishop, Computer Security: Art and [12*] P. Grubb and A.A. Takang, Software Science, Addison-Wesley, 2002. Maintenance: Concepts and Practice, 2nd ed., World Scientific Publishing, 2003. [3*] B. Boehm and R. Turner, Balancing Agility and Discipline: A Guide for the Perplexed, [13*] A.M.J. Hass, Configuration Management Addison-Wesley, 2003. Principles and Practices, 1st ed., Addison- Wesley, 2003.

C-1 C-2 SWEBOK® Guide V3.0

[14*] E. Horowitz et al., Computer Algorithms, [25*] S. Naik and P. Tripathy, Software Testing 2nd ed., Silicon Press, 2007. and Quality Assurance: Theory and Practice, Wiley-Spektrum, 2008. [15*] IEEE CS/ACM Joint Task Force on Software Engineering Ethics and [26*] J. Nielsen, Usability Engineering, 1st ed., Professional Practices, “Software Morgan Kaufmann, 1993. Engineering Code of Ethics and Professional Practice (Version 5.2),” 1999; [27*] L. Null and J. Lobur, The Essentials of www.acm.org/serving/se/code.htm. Computer Organization and Architecture, 2nd ed., Jones and Bartlett Publishers, [16*] IEEE Std. 828-2012, Standard for 2006. Configuration Management in Systems and Software Engineering, IEEE, 2012. [28*] M. Page-Jones, Fundamentals of Object- Oriented Design in UML, 1st ed., Addison- [17*] IEEE Std. 1028-2008, Software Reviews Wesley, 1999. and Audits, IEEE, 2008. [29*] K. Rosen, Discrete Mathematics and Its [18*] ISO/IEC 14764 IEEE Std. 14764-2006, Applications, 7th ed., McGraw-Hill, 2011. Software Engineering—Software Life Cycle Processes—Maintenance, IEEE, 2006. [30*] A. Silberschatz, P.B. Galvin, and G. Gagne, Operating System Concepts, 8th [19*] S.H. Kan, Metrics and Models in Software ed., Wiley, 2008. Quality Engineering, 2nd ed., Addison- Wesley, 2002. [31*] H.M. Sneed, “Offering Software Maintenance as an Offshore Service,” Proc. [20*] S. McConnell, Code Complete, 2nd ed., IEEE Int’l Conf. Software Maintenance Microsoft Press, 2004. (ICSM 08), IEEE, 2008, pp. 1–5.

[21*] J. McGarry et al., Practical Software [32*] I. Sommerville, Software Engineering, 9th Measurement: Objective Information ed., Addison-Wesley, 2011. for Decision Makers, Addison-Wesley Professional, 2001. [33*] S. Tockey, Return on Software: Maximizing the Return on Your Software [22*] S.J. Mellor and M.J. Balcer, Executable Investment, 1st ed., Addison-Wesley, 2004. UML: A Foundation for Model-Driven Architecture, 1st ed., Addison-Wesley, [34*] G. Voland, Engineering by Design, 2nd 2002. ed., Prentice Hall, 2003.

[23*] D.C. Montgomery and G.C. Runger, [35*] K.E. Wiegers, Software Requirements, 2nd Applied Statistics and Probability for ed., Microsoft Press, 2003. Engineers, 4th ed., Wiley, 2007. [36*] J.M. Wing, “A Specifier’s Introduction to [24*] J.W. Moore, The Road Map to Software Formal Methods,” Computer, vol. 23, no. 9, Engineering: A Standards-Based Guide, 1st 1990, pp. 8, 10–23. ed., Wiley-IEEE Computer Society Press, 2006.