commit 04d6379861b6e56c86afd388776c01c7497bbb7f from: Sergey Bronnikov date: Mon Jul 08 07:05:10 2019 UTC removed sources commit - d5e5b13e231b9785ccf67065b3a7fff8a3300504 commit + 04d6379861b6e56c86afd388776c01c7497bbb7f blob - f3e7166bf5fd2ba686b784b446b5f608eb56d94a (mode 644) blob + /dev/null --- .travis.yml +++ /dev/null @@ -1,25 +0,0 @@ -sudo: required -language: ruby - -rvm: - - 2.2 - -os: - - linux - -before_script: - - gem install awesome_bot - - sudo apt-get install -y pandoc - -script: - - make epub - - make html - - make release - - awesome_bot *.markdown --allow-redirect --allow-ssl --allow-dupe - -notifications: - email: - recipients: - - estetus+travis-ci@gmail.com - on_success: change - on_failure: always blob - d837bd78e66836fddb5448bd2710d304f30fea04 (mode 644) blob + /dev/null --- 0_introduction.markdown +++ /dev/null @@ -1,1556 +0,0 @@ -## Guide to the Software Engineering Body of Knowledge Version 3. - -## SWEBOK ®A Project of the IEEE Computer Society - -**Guide to the Software Engineering** - -**Body of Knowledge** - -**Version 3.** - -**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 -pubs-permissions@ieee.org. - -Reference to any specific commercial products, process, or service does not -imply endorsement by IEEE. The views and opinions 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. - -Copyright © 2014 IEEE. All rights reserved. -Paperback ISBN-10: 0-7695-5166- -Paperback ISBN-13: 978-0-7695-5166- - -Digital copies of _SWEBOK Guide_ V3.0 may be downloaded free of charge for -personal and academic use via [http://www.swebok.org.](http://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 [http://www.computer.org](http://www.computer.org) for -more information. - -**TABLE OF CONTENTS** - -- Foreword -- Foreword to the 2004 Edition -- Editors -- Coeditors -- Contributing Editors -- Change Control Board -- Knowledge Area Editors -- Knowledge Area Editors of Previous SWEBOK Versions -- Review Team -- Acknowledgements -- Professional Activities Board, 2013 Membership -- Motions Regarding the Approval of SWEBOK Guide V3.0 -- Motions Regarding the Approval of SWEBOK Guide 2004 Version -- Introduction to the Guide - -**Chapter 1: Software Requirements 1** - -### 1. Software Construction Fundamentals - -1.1. Definition of a Software Requirement -1.2. Product and Process Requirements -1.3. Functional and Nonfunctional Requirements -1.4. Emergent Properties -1.5. Quantifiable Requirements -1.6. System Requirements and Software Requirements - -2. Requirements Process - 2.1. Process Models - 2.2. Process Actors - 2.3. Process Support and Management - 2.4. Process Quality and Improvement -3. Requirements Elicitation - 3.1. Requirements Sources - 3.2. Elicitation Techniques -4. Requirements Analysis - 4.1. Requirements Classification - 4.2. Conceptual Modeling - 4.3. Architectural Design and Requirements Allocation - 4.4. Requirements Negotiation - 4.5. Formal Analysis -5. Requirements Specification - 5.1. System Definition Document - 5.2. System Requirements Specification - 5.3. Software Requirements Specification -6. Requirements Validation - 6.1. Requirements Reviews - 6.2. Prototyping - - -#### 2.1. Concurrency - -#### 2.2. Control and Handling of Events - -#### 2.3. Data Persistence - -#### 2.4. Distribution of Components - -#### 2.5. Error and Exception Handling and Fault Tolerance - -#### 2.6. Interaction and Presentation - -#### 2.7. Security - -### 3. Software Structure and Architecture - -#### 3.1. Architectural Structures and Viewpoints - -#### 3.2. Architectural Styles - -#### 3.3. Design Patterns - -#### 3.4. Architecture Design Decisions - -#### 3.5. Families of Programs and Frameworks - -### 4. User Interface Design - - -## Table of Contents - -### 3. Practical Considerations - -#### 3.1. Construction Design - -#### 3.2. Construction Languages - -#### 3.3. Coding - -#### 3.4. Construction Testing - -#### 3.5. Construction for Reuse - - -### 3. Test Techniques - -#### 2.3. Maintenance Cost Estimation - -#### 2.4. Software Maintenance Measurement - -### 3. Maintenance Process - -#### 3.1. Maintenance Processes - - -#### 2.2. Software Library - -### 3. Software Configuration Control - -#### 3.1. Requesting, Evaluating, and Approving Software Changes - -#### 2.7. Plan Management - -### 3. Software Project Enactment - -#### 3.1. Implementation of Plans - -#### 3.2. Software Acquisition and Supplier Contract Management - -#### 3.3. Implementation of Measurement Process - -#### 3.4. Monitor Process - -#### 3.5. Control Process - -#### 3.6. Reporting - - -### 4. Review and Evaluation - -#### 4.1. Determining Satisfaction of Requirements - -#### 4.2. Reviewing and Evaluating Performance - -### 5. Closure - -#### 5.1. Determining Closure - -#### 5.2. Closure Activities - -### 6. Software Engineering Measurement - -#### 6.1. Establish and Sustain Measurement Commitment - -#### 3.4. Continuous and Staged Software Process Ratings - -### 4. Software Measurement - -#### 4.1. Software Process and Product Measurement - - -#### 4.4. Agile Methods - -### Matrix of Topics vs. Reference Material - -### 3. Practical Considerations - -#### 3.1. Software Quality Requirements - -#### 3.2. Defect Characterization - -### 2. Group Dynamics and Psychology - -#### 2.1. Dynamics of Working in Teams/Groups - -#### 2.2. Individual Cognition - -#### 2.3. Dealing with Problem Complexity - -#### 2.4. Interacting with Stakeholders - -#### 2.5. Dealing with Uncertainty and Ambiguity - -#### 2.6. Dealing with Multicultural Environments - - -#### 3.2. Writing - -#### 3.3. Team and Group Communication - -#### 2.15. Replacement and Retirement Decisions - -### 3. Risk and Uncertainty - -#### 3.1. Goals, Estimates, and Plans - -#### 3.2. Estimation Techniques - -#### 3.3. Addressing Uncertainty - -#### 3.4. Prioritization - -#### 3.5. Decisions under Risk - - -#### 7.4. Algorithmic Design Strategies - -#### 7.5. Algorithmic Analysis Strategies - -### 8. Basic Concept of a System - -#### 8.1. Emergent System Properties - - -#### 8.2. Systems Engineering - -#### 8.3. Overview of a Computer System - -### 9. Computer Organization - -#### 9.1. Computer Organization Overview - -#### 9.2. Digital Systems - -#### 9.3. Digital Logic - -#### 9.4. Computer Expression of Data - - -### 6. Discrete Probability - -### 7. Finite State Machines - - -### Matrix of Topics vs. Reference Material - - - 6.3. Model Validation - - 6.4. Acceptance Tests - - 7. Practical Considerations - - 7.1. Iterative Nature of the Requirements Process - - 7.2. Change Management - - 7.3. Requirements Attributes - - 7.4. Requirements Tracing - - 7.5. Measuring Requirements - - 8. Software Requirements Tools - - Matrix of Topics vs. Reference Material -- Chapter 2: Software Design - - 1. Software Design Fundamentals - - 1.1. General Design Concepts - - 1.2. Context of Software Design - - 1.3. Software Design Process - - 1.4. Software Design Principles - - 2. Key Issues in Software Design - - 2.1. Concurrency - - 2.2. Control and Handling of Events - - 2.3. Data Persistence - - 2.4. Distribution of Components - - 2.5. Error and Exception Handling and Fault Tolerance - - 2.6. Interaction and Presentation - - 2.7. Security - - 3. Software Structure and Architecture - - 3.1. Architectural Structures and Viewpoints - - 3.2. Architectural Styles - - 3.3. Design Patterns - - 3.4. Architecture Design Decisions - - 3.5. Families of Programs and Frameworks - - 4. User Interface Design - - 4.1. General User Interface Design Principles - - 4.2. User Interface Design Issues - - 4.3. The Design of User Interaction Modalities - - 4.4. The Design of Information Presentation - - 4.5. User Interface Design Process - - 4.6. Localization and Internationalization - - 4.7. Metaphors and Conceptual Models - - 5. Software Design Quality Analysis and Evaluation - - 5.1. Quality Attributes - - 5.2. Quality Analysis and Evaluation Techniques - - 5.3. Measures - - 6. Software Design Notations - - 6.1. Structural Descriptions (Static View) - - 6.2. Behavioral Descriptions (Dynamic View) - - 7. Software Design Strategies and Methods - - 7.1. General Strategies - - 7.2. Function-Oriented (Structured) Design - - 7.3. Object-Oriented Design - - 7.4. Data Structure-Centered Design - - 7.5. Component-Based Design (CBD) - - 7.6. Other Methods - - 8. Software Design Tools - - Matrix of Topics vs. Reference Material -- Chapter 3: Software Construction - - 1. Software Construction Fundamentals - - 1.1. Minimizing Complexity - - 1.2. Anticipating Change - - 1.3. Constructing for Verification - - 1.4. Reuse - - 1.5. Standards in Construction - - 2. Managing Construction - - 2.1. Construction in Life Cycle Models - - 2.2. Construction Planning - - 2.3. Construction Measurement - - 3. Practical Considerations - - 3.1. Construction Design - - 3.2. Construction Languages - - 3.3. Coding - - 3.4. Construction Testing - - 3.5. Construction for Reuse - - 3.6. Construction with Reuse - - 3.7. Construction Quality - - 3.8. Integration - - 4. Construction Technologies - - 4.1. API Design and Use - - 4.2. Object-Oriented Runtime Issues - - 4.3. Parameterization and Generics - - 4.4. Assertions, Design by Contract, and Defensive Programming - - 4.5. Error Handling, Exception Handling, and Fault Tolerance - - 4.6. Executable Models - - 4.7. State-Based and Table-Driven Construction Techniques - - 4.8. Runtime Configuration and Internationalization - - 4.9. Grammar-Based Input Processing - - 4.10. Concurrency Primitives - - 4.11. Middleware - - 4.12. Construction Methods for Distributed Software - - 4.13. Constructing Heterogeneous Systems - - 4.14. Performance Analysis and Tuning - - 4.15. Platform Standards - - 4.16. Test-First Programming - - 5. Software Construction Tools - - 5.1. Development Environments - - 5.2. GUI Builders - - 5.3. Unit Testing Tools - - 5.4. Profiling, Performance Analysis, and Slicing Tools - - Matrix of Topics vs. Reference Material -- Chapter 4: Software Testing - - 1. Software Testing Fundamentals - - 1.1. Testing-Related Terminology - - 1.2. Key Issues - - 1.3. Relationship of Testing to Other Activities - - 2. Test Levels - - 2.1. The Target of the Test - - 2.2. Objectives of Testing - - 3. Test Techniques - - 3.1. Based on the Software Engineer’s Intuition and Experience - - 3.2. Input Domain-Based Techniques - - 3.3. Code-Based Techniques - - 3.4. Fault-Based Techniques - - 3.5. Usage-Based Techniques - - 3.6. Model-Based Testing Techniques - - 3.7. Techniques Based on the Nature of the Application - - 3.8. Selecting and Combining Techniques - - 4. Test-Related Measures - - 4.1. Evaluation of the Program Under Test - - 4.2. Evaluation of the Tests Performed - - 5. Test Process - - 5.1. Practical Considerations - - 5.2. Test Activities - - 6. Software Testing Tools - - 6.1. Testing Tool Support - - 6.2. Categories of Tools - - Matrix of Topics vs. Reference Material -- Chapter 5: Software Maintenance - - 1. Software Maintenance Fundamentals - - 1.1. Definitions and Terminology - - 1.2. Nature of Maintenance - - 1.3. Need for Maintenance - - 1.4. Majority of Maintenance Costs - - 1.5. Evolution of Software - - 1.6. Categories of Maintenance - - 2. Key Issues in Software Maintenance - - 2.1. Technical Issues - - 2.2. Management Issues - - 2.3. Maintenance Cost Estimation - - 2.4. Software Maintenance Measurement - - 3. Maintenance Process - - 3.1. Maintenance Processes - - 3.2. Maintenance Activities - - 4. Techniques for Maintenance - - 4.1. Program Comprehension - - 4.2. Reengineering - - 4.3. Reverse Engineering - - 4.4. Migration - - 4.5. Retirement - - 5. Software Maintenance Tools - - Matrix of Topics vs. Reference Material -- Chapter 6: Software Configuration Management - - 1. Management of the SCM Process - - 1.1. Organizational Context for SCM - - 1.2. Constraints and Guidance for the SCM Process - - 1.3. Planning for SCM - - 1.4. SCM Plan - - 1.5. Surveillance of Software Configuration Management - - 2. Software Configuration Identification - - 2.1. Identifying Items to Be Controlled - - 2.2. Software Library - - 3. Software Configuration Control - - 3.1. Requesting, Evaluating, and Approving Software Changes - - 3.2. Implementing Software Changes - - 3.3. Deviations and Waivers - - 4. Software Configuration Status Accounting - - 4.1. Software Configuration Status Information - - 4.2. Software Configuration Status Reporting - - 5. Software Configuration Auditing - - 5.1. Software Functional Configuration Audit - - 5.2. Software Physical Configuration Audit - - 5.3. In-Process Audits of a Software Baseline - - 6. Software Release Management and Delivery - - 6.1. Software Building - - 6.2. Software Release Management - - 7. Software Configuration Management Tools - - Matrix of Topics vs. Reference Material -- Chapter 7: Software Engineering Management - - 1. Initiation and Scope Definition - - 1.1. Determination and Negotiation of Requirements - - 1.2. Feasibility Analysis - - 1.3. Process for the Review and Revision of Requirements - - 2. Software Project Planning - - 2.1. Process Planning - - 2.2. Determine Deliverables - - 2.3. Effort, Schedule, and Cost Estimation - - 2.4. Resource Allocation - - 2.5. Risk Management - - 2.6. Quality Management - - 2.7. Plan Management - - 3. Software Project Enactment - - 3.1. Implementation of Plans - - 3.2. Software Acquisition and Supplier Contract Management - - 3.3. Implementation of Measurement Process - - 3.4. Monitor Process - - 3.5. Control Process - - 3.6. Reporting - - 4. Review and Evaluation - - 4.1. Determining Satisfaction of Requirements - - 4.2. Reviewing and Evaluating Performance - - 5. Closure - - 5.1. Determining Closure - - 5.2. Closure Activities - - 6. Software Engineering Measurement - - 6.1. Establish and Sustain Measurement Commitment - - 6.2. Plan the Measurement Process - - 6.3. Perform the Measurement Process - - 6.4. Evaluate Measurement - - 7. Software Engineering Management Tools - - Matrix of Topics vs. Reference Material -- Chapter 8: Software Engineering Process - - 1. Software Process Definition - - 1.1. Software Process Management - - 1.2. Software Process Infrastructure - - 2. Software Life Cycles - - 2.1. Categories of Software Processes - - 2.2. Software Life Cycle Models - - 2.3. Software Process Adaptation - - 2.4. Practical Considerations - - 3. Software Process Assessment and Improvement - - 3.1. Software Process Assessment Models - - 3.2. Software Process Assessment Methods - - 3.3. Software Process Improvement Models - - 3.4. Continuous and Staged Software Process Ratings - - 4. Software Measurement - - 4.1. Software Process and Product Measurement - - 4.2. Quality of Measurement Results - - 4.3. Software Information Models - - 4.4. Software Process Measurement Techniques - - 5. Software Engineering Process Tools - - Matrix of Topics vs. Reference Material -- Chapter 9: Software Engineering Models and Methods - - 1. Modeling - - 1.1. Modeling Principles - - 1.2. Properties and Expression of Models - - 1.3. Syntax, Semantics, and Pragmatics - - 1.4. Preconditions, Postconditions, and Invariants - - 2. Types of Models - - 2.1. Information Modeling - - 2.2. Behavioral Modeling - - 2.3. Structure Modeling - - 3. Analysis of Models - - 3.1. Analyzing for Completeness - - 3.2. Analyzing for Consistency - - 3.3. Analyzing for Correctness - - 3.4. Traceability - - 3.5. Interaction Analysis - - 4. Software Engineering Methods - - 4.1. Heuristic Methods - - 4.2. Formal Methods - - 4.3. Prototyping Methods - - 4.4. Agile Methods - - Matrix of Topics vs. Reference Material -- Chapter 10: Software Quality - - 1. Software Quality Fundamentals - - 1.1. Software Engineering Culture and Ethics - - 1.2. Value and Costs of Quality - - 1.3. Models and Quality Characteristics - - 1.4. Software Quality Improvement - - 1.5. Software Safety - - 2. Software Quality Management Processes - - 2.1. Software Quality Assurance - - 2.2. Verification & Validation - - 2.3. Reviews and Audits - - 3. Practical Considerations - - 3.1. Software Quality Requirements - - 3.2. Defect Characterization - - 3.3. Software Quality Management Techniques - - 3.4. Software Quality Measurement - - 4. Software Quality Tools - - Matrix of Topics vs. Reference Material -- Chapter 11: Software Engineering Professional Practice - - 1. Professionalism - - 1.1. Accreditation, Certification, and Licensing - - 1.2. Codes of Ethics and Professional Conduct - - 1.3. Nature and Role of Professional Societies - - 1.4. Nature and Role of Software Engineering Standards - - 1.5. Economic Impact of Software - - 1.6. Employment Contracts - - 1.7. Legal Issues - - 1.8. Documentation - - 1.9. Tradeoff Analysis - - 2. Group Dynamics and Psychology - - 2.1. Dynamics of Working in Teams/Groups - - 2.2. Individual Cognition - - 2.3. Dealing with Problem Complexity - - 2.4. Interacting with Stakeholders - - 2.5. Dealing with Uncertainty and Ambiguity - - 2.6. Dealing with Multicultural Environments - - 3. Communication Skills - - 3.1. Reading, Understanding, and Summarizing - - 3.2. Writing - - 3.3. Team and Group Communication - - 3.4. Presentation Skills - - Matrix of Topics vs. Reference Material -- Chapter 12: Software Engineering Economics - - 1. Software Engineering Economics Fundamentals - - 1.1. Finance - - 1.2. Accounting - - 1.3. Controlling - - 1.4. Cash Flow - - 1.5. Decision-Making Process - - 1.6. Valuation - - 1.7. Inflation - - 1.8. Depreciation - - 1.9. Taxation - - 1.10. Time-Value of Money - - 1.11. Efficiency - - 1.12. Effectiveness - - 1.13. Productivity - - 2. Life Cycle Economics - - 2.1. Product - - 2.2. Project - - 2.3. Program - - 2.4. Portfolio - - 2.5. Product Life Cycle - - 2.6. Project Life Cycle - - 2.7. Proposals - - 2.8. Investment Decisions - - 2.9. Planning Horizon - - 2.10. Price and Pricing - - 2.11. Cost and Costing - - 2.12. Performance Measurement - - 2.13. Earned Value Management - - 2.14. Termination Decisions - - 2.15. Replacement and Retirement Decisions - - 3. Risk and Uncertainty - - 3.1. Goals, Estimates, and Plans - - 3.2. Estimation Techniques - - 3.3. Addressing Uncertainty - - 3.4. Prioritization - - 3.5. Decisions under Risk - - 3.6. Decisions under Uncertainty - - 4. Economic Analysis Methods - - 4.1. For-Profit Decision Analysis - - 4.2. Minimum Acceptable Rate of Return - - 4.3. Return on Investment - - 4.4. Return on Capital Employed - - 4.5. Cost-Benefit Analysis - - 4.6. Cost-Effectiveness Analysis - - 4.7. Break-Even Analysis - - 4.8. Business Case - - 4.9. Multiple Attribute Evaluation - - 4.10. Optimization Analysis - - 5. Practical Considerations - - 5.1. The “Good Enough” Principle - - 5.2. Friction-Free Economy - - 5.3. Ecosystems - - 5.4. Offshoring and Outsourcing - - Matrix of Topics vs. Reference Material -- Chapter 13: Computing Foundations - - 1. Problem Solving Techniques - - 1.1. Definition of Problem Solving - - 1.2. Formulating the Real Problem - - 1.3. Analyze the Problem - - 1.4. Design a Solution Search Strategy - - 1.5. Problem Solving Using Programs - - 2. Abstraction - - 2.1. Levels of Abstraction - - 2.2. Encapsulation - - 2.3. Hierarchy - - 2.4. Alternate Abstractions - - 3. Programming Fundamentals - - 3.1. The Programming Process - - 3.2. Programming Paradigms - - 4. Programming Language Basics - - 4.1. Programming Language Overview - - 4.2. Syntax and Semantics of Programming Languages - - 4.3. Low-Level Programming Languages - - 4.4. High-Level Programming Languages - - 4.5. Declarative vs. Imperative Programming Languages - - 5. Debugging Tools and Techniques - - 5.1. Types of Errors - - 5.2. Debugging Techniques - - 5.3. Debugging Tools - - 6. Data Structure and Representation - - 6.1. Data Structure Overview - - 6.2. Types of Data Structure - - 6.3. Operations on Data Structures - - 7. Algorithms and Complexity - - 7.1. Overview of Algorithms - - 7.2. Attributes of Algorithms - - 7.3. Algorithmic Analysis - - 7.4. Algorithmic Design Strategies - - 7.5. Algorithmic Analysis Strategies - - 8. Basic Concept of a System - - 8.1. Emergent System Properties - - 8.2. Systems Engineering - - 8.3. Overview of a Computer System - - 9. Computer Organization - - 9.1. Computer Organization Overview - - 9.2. Digital Systems - - 9.3. Digital Logic - - 9.4. Computer Expression of Data - - 9.5. The Central Processing Unit (CPU) - - 9.6. Memory System Organization - - 9.7. Input and Output (I/O) - - 10. Compiler Basics - - 10.1. Compiler/Interpreter Overview - - 10.2. Interpretation and Compilation - - 10.3. The Compilation Process - - 11. Operating Systems Basics - - 11.1. Operating Systems Overview - - 11.2. Tasks of an Operating System - - 11.3. Operating System Abstractions - - 11.4. Operating Systems Classification - - 12. Database Basics and Data Management - - 12.1. Entity and Schema - - 12.2. Database Management Systems (DBMS) - - 12.3. Database Query Language - - 12.4. Tasks of DBMS Packages - - 12.5. Data Management - - 12.6. Data Mining - - 13. Network Communication Basics - - 13.1. Types of Network - - 13.2. Basic Network Components - - 13.3. Networking Protocols and Standards - - 13.4. The Internet - - 13.5. Internet of Things - - 13.6. Virtual Private Network (VPN) - - 14. Parallel and Distributed Computing - - 14.1. Parallel and Distributed Computing Overview - - 14.2. Difference between Parallel and Distributed Computing - - 14.3. Parallel and Distributed Computing Models - - 14.4. Main Issues in Distributed Computing - - 15. Basic User Human Factors - - 15.1. Input and Output - - 15.2. Error Messages - - 15.3. Software Robustness - - 16. Basic Developer Human Factors - - 16.1. Structure - - 16.2. Comments - - 17. Secure Software Development and Maintenance - - 17.1. Software Requirements Security - - 17.2. Software Design Security - - 17.3. Software Construction Security - - 17.4. Software Testing Security - - 17.5. Build Security into Software Engineering Process - - 17.6. Software Security Guidelines - - Matrix of Topics vs. Reference Material -- Chapter 14: Mathematical Foundations - - 1. Set, Relations, Functions - - 1.1. Set Operations - - 1.2. Properties of Set - - 1.3. Relation and Function - - 2. Basic Logic - - 2.1. Propositional Logic - - 2.2. Predicate Logic - - 3. Proof Techniques - - 3.1. Methods of Proving Theorems - - 4. Basics of Counting - - 5. Graphs and Trees - - 5.1. Graphs - - 5.2. Trees - - 6. Discrete Probability - - 7. Finite State Machines - - 8. Grammars - - 8.1. Language Recognition - - 9. Numerical Precision, Accuracy, and Errors - - 10. Number Theory - - 10.1. Divisibility - - 10.2. Prime Number, GCD - - 11. Algebraic Structures - - 11.1. Group - - 11.2. Rings - - Matrix of Topics vs. Reference Material -- Chapter 15: Engineering Foundations 15- - - 1. Empirical Methods and Experimental Techniques - - 1.1. Designed Experiment - - 1.2. Observational Study - - 1.3. Retrospective Study - - 2. Statistical Analysis - - 2.1. Unit of Analysis (Sampling Units), Population, and Sample - - 2.2. Concepts of Correlation and Regression - - 3. Measurement - - 3.1. Levels (Scales) of Measurement - - 3.2. Direct and Derived Measures - - 3.3. Reliability and Validity - - 3.4. Assessing Reliability - - 4. Engineering Design - - 4.1. Engineering Design in Engineering Education - - 4.2. Design as a Problem Solving Activity - - 4.3. Steps Involved in Engineering Design - - 5. Modeling, Simulation, and Prototyping - - 5.1. Modeling - - 5.2. Simulation - - 5.3. Prototyping - - 6. Standards - - 7. Root Cause Analysis - - 7.1. Techniques for Conducting Root Cause Analysis - - Matrix of Topics vs. Reference Material -- Appendix A: Knowledge Area Description Specifications A- -- Body of Knowledge (SWEBOK) - Appendix B: IEEE and ISO/IEC Standards -Supporting the Software Engineering -- Appendix C: Consolidated Reference List C- - - -**FOREWORD** - -Every profession is based on a body of knowl- edge, although that knowledge is -not always defined in a concise manner. In cases where no formality exists, the -body of knowledge is “gen- erally recognized” by practitioners and may be -codified in a variety of ways for a variety of different uses. But in many -cases, a guide to a body of knowledge is formally documented, usu- ally in a -form that permits it to be used for such purposes as development and -accreditation of academic and training programs, certification of specialists, -or professional licensing. Generally, a professional society or similar body -maintains stewardship of the formal definition of a body of knowledge. - -During the past forty-five years, software engi neering has evolved from a -conference catch phrase into an engineering profession, characterized by 1) a -professional society, 2) standards that specify generally accepted professional -practices, 3) a code of ethics, 4) conference proceedings, 5) textbooks, 6) -curriculum guidelines and curricula, 7) accreditation criteria and accredited -degree programs, 8) certification and licensing, and 9) this Guide to the Body -of Knowledge. In this _Guide to the Software Engineering Body of Knowledge_ , -the IEEE Computer Society pres ents a revised and updated version of the body -of knowledge formerly documented as SWEBOK 2004; this revised and updated -version is denoted SWEBOK V3. This work is in partial fulfillment of the -Society’s responsibility to promote the advancement of both theory and practice -for the profession of software engineering. - -It should be noted that this _Guide_ does not 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 evolv- ing. Nevertheless, this -_Guide_ constitutes a valuable characterization of the software engineering -profession. - -In 1958, John Tukey, the world-renowned statistician, coined the term software. -The term soft ware engineering was used in the title of a NATO conference held -in Germany in 1968. The IEEE Computer Society first published its Transactions -on Software Engineering in 1972, and a commit- tee for developing software -engineering standards was established within the IEEE Computer Society in 1976. - -In 1990, planning was begun for an international standard to provide an overall -view of soft- ware engineering. The standard was completed in 1995 with -designation ISO/IEC 12207 and given the title of Standard for Software Life -Cycle Processes. The IEEE version of 12207 was published in 1996 and provided a -major foundation for the body of knowledge captured in SWEBOK 2004. The -current version of 12207 is designated as ISO/IEC 12207:2008 and IEEE -12207-2008; it provides the basis for this SWEBOK V3. - -This Guide to the Software Engineering Body of Knowledge is presented to you, -the reader, as a mechanism for acquiring the knowledge you need in your -lifelong career development as a software engineering professional. - -Dick Fairley, Chair -Software and Systems Engineering Committee -IEEE Computer Society - -Don Shafer, Vice President -Professional Activities Board -IEEE Computer Society - -**FOREWORD TO THE 2004 EDITION** - -In this _Guide_ , the IEEE Computer Society establishes for the first time a -baseline for the body of knowledge for the field of software engineering, and -the work partially fulfills the Society’s responsibility to promote the -advancement of both theory and practice in this field. In so doing, the Society -has been guided by the experience of disciplines with longer histories but was -not bound either by their problems or their solutions. - -It should be noted that the _Guide_ does not purport to define the body of -knowledge but rather to serve as a compendium and guide to the body of -knowledge that has been developing and evolving over the past four decades. -Furthermore, this body of knowledge is not static. The _Guide_ must, -necessarily, develop and evolve as software engineering matures. It -nevertheless constitutes a valuable element of the software engineering -infrastructure. - -In 1958, John Tukey, the world-renowned statistician, coined the term -_software_. The term _soft- ware engineering_ was used in the title of a NATO -conference held in Germany in 1968. The IEEE Computer Society first published -its _Transactions on Software Engineering_ in 1972. The committee established -within the IEEE Computer Society for developing software engineering standards -was founded in 1976. - -The first holistic view of software engineering to emerge from the IEEE -Computer Society resulted from an effort led by Fletcher Buckley to develop -IEEE standard 730 for software quality assurance, which was completed in -1979. - -The purpose of IEEE Std. 730 was to provide uniform, minimum acceptable -requirements for preparation and content of software quality assurance plans. -This standard was influential in com- pleting the developing standards in the -following topics: configuration management, software testing, software -requirements, software design, and software verification and validation. - -During the period 1981–1985, the IEEE Computer Society held a series of -workshops con- cerning the application of software engineering standards. These -workshops involved practitio- ners sharing their experiences with existing -standards. The workshops also held sessions on plan- ning for future standards, -including one involving measures and metrics for software engineer- ing -products and processes. The planning also resulted in IEEE Std. 1002, Taxonomy -of Software Engineering Standards (1986), which provided a new, holistic view -of software engineering. The standard describes the form and content of a -software engineering standards taxonomy. It explains the various types of -software engineering standards, their functional and external relationships, -and the role of various functions participating in the software life cycle. - -In 1990, planning for an international standard with an overall view was begun. -The plan- ning focused on reconciling the software process views from IEEE Std. -1074 and the revised US DoD standard 2167A. The revision was eventually -published as DoD Std. 498. The international standard was completed in 1995 -with designation, ISO/IEC 12207, and given the title of Stan- dard for Software -Life Cycle Processes. Std. ISO/IEC 12207 provided a major point of departure -for the body of knowledge captured in this book. - -It was the IEEE Computer Society Board of Governors’ approval of the motion put -forward in May 1993 by Fletcher Buckley which resulted in the writing of this -book. The Association for Computing Machinery (ACM) Council approved a related -motion in August 1993. The two motions led to a joint committee under the -leadership of Mario Barbacci and Stuart Zweben who served as cochairs. The -mission statement of the joint committee was “To establish the appropriate -sets(s) of criteria and norms for professional practice of software engineering -upon which industrial decisions, professional certification, and educational -curricula can be based.” The steering committee organized task forces in the -following areas: - -1. Define Required Body of Knowledge and Recommended Practices. -2. Define Ethics and Professional Standards. -3. Define Educational Curricula for undergraduate, graduate, and continuing -education. - -This book supplies the first component: required body of knowledge and -recommend practices. The code of ethics and professional practice for software -engineering was completed in 1998 and approved by both the ACM Council and the -IEEE Computer Society Board of Governors. It has been adopted by numerous -corporations and other organizations and is included in several recent -textbooks. - -The educational curriculum for undergraduates is being completed by a joint -effort of the IEEE Computer Society and the ACM and is expected to be completed -in 2004. - -Every profession is based on a body of knowledge and recommended practices, -although they are not always defined in a precise manner. In many cases, these -are formally documented, usually 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. - -It is hoped that readers will find this book useful in guiding them toward the -knowledge and resources they need in their lifelong career development as -software engineering professionals. The book is dedicated to Fletcher Buckley -in recognition of his commitment to promoting software engineering as a -professional discipline and his excellence as a software engineering -practitioner in radar applications. - -Leonard L. Tripp, IEEE Fellow 2003 -Chair, Professional Practices Committee, IEEE -Computer Society (2001–2003) - -Chair, Joint IEEE Computer Society and ACM -Steering Committee for the Establishment of -Software Engineering as a Profession (1998–1999) - -Chair, Software Engineering Standards Committee, -IEEE Computer Society (1992–1998) - -**EDITORS** - -Pierre Bourque, Department of Software and IT Engineering, École de technologie -supérieure (ÉTS), Canada, pierre.bourque@etsmtl.ca -Richard E. (Dick) Fairley, Software and Systems Engineering Associates (S2EA), -USA, dickfairley@gmail.com - -**COEDITORS** - -Alain Abran, Department of Software and IT Engineering, École de technologie -supérieure (ÉTS), Canada, alain.abran@etsmtl.ca -Juan Garbajosa, Universidad Politecnica de Madrid (Technical University of -Madrid, UPM), Spain, juan.garbajosa@upm.es -Gargi Keeni, Tata Consultancy Services, India, gargi@ieee.org Beijun Shen, -School of Software, Shanghai Jiao Tong University, China, bjshen@sjtu.edu.cn - -**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 - -**KNOWLEDGE AREA EDITORS** - -Software Requirements -Gerald Kotonya, School of Computing and Communications, Lancaster University, -UK, gerald@comp.lancs.ac.uk -Peter Sawyer, School of Computing and Communications, Lancaster University, UK, -sawyer@comp.lancs.ac.uk - -**Software Design** - -Yanchun Sun, School of Electronics Engineering and Computer Science, Peking -University, China, sunyc@pku.edu.cn - -Software Construction -Xin Peng, Software School, Fudan University, China, pengxin@fudan.edu.cn - -Software Testing -Antonia Bertolino, ISTI-CNR, Italy, antonia.bertolino@isti.cnr.it -Eda Marchetti, ISTI-CNR, Italy, eda.marchetti@isti.cnr.it - -Software Maintenance -Alain April, École de technologie supérieure (ÉTS), Canada, -alain.april@etsmtl.ca -Mira Kajko-Mattsson, School of Information and Communication Technology, -KTH Royal Institute of Technology, mekm2@kth.se - -Software Configuration Management -Roger Champagne, École de technologie supérieure (ÉTS), Canada, -roger.champagne@etsmtl.ca -Alain April, École de technologie supérieure (ÉTS), Canada, -alain.april@etsmtl.ca - -Software Engineering Management -James McDonald, Department of Computer Science and Software Engineering, -Monmouth University, USA, jamesmc@monmouth.edu - -Software Engineering Process -Annette Reilly, Lockheed Martin Information Systems & Global Solutions, USA, -annette.reilly@computer.org -Richard E. Fairley, Software and Systems Engineering Associates (S2EA), USA, -dickfairley@gmail.com - -Software Engineering Models and Methods -Michael F. Siok, Lockheed Martin Aeronautics Company, USA, mike.f.siok@lmco.com - -Software Quality -J. David Blaine, USA, jdavidblaine@gmail.com -Durba Biswas, Tata Consultancy Services, India, durba.biswas@tcs.com - -Software Engineering Professional Practice -Aura Sheffield, USA, arsheff@acm.org -Hengming Zou, Shanghai Jiao Tong University, China, zou@sjtu.edu.cn - -Software Engineering Economics -Christof Ebert, Vector Consulting Services, Germany, christof.ebert@vector.com - -Computing Foundations -Hengming Zou, Shanghai Jiao Tong University, China, zou@sjtu.edu.cn - -Mathematical Foundations -Nabendu Chaki, University of Calcutta, India, nabendu@ieee.org - -Engineering Foundations -Amitava Bandyopadhayay, Indian Statistical Institute, India, -bamitava@isical.ac.in -Mary Jane Willshire, Software and Systems Engineering Associates (S2EA), USA, -mj.fairley@gmail.com - -Appendix B: IEEE and ISO/IEC Standards Supporting SWEBOK -James W. Moore, USA, James.W.Moore@ieee.org - -**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 - -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. Membership 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 -Mark Ardis, USA -Mora-Soto Arturo, Spain -Ohad Barzilay, Israel -Gianni Basaglia, Italy -Denis J. Bergquist, USA -Alexander Bogush, UK -Christopher Bohn, USA -Steve Bollweg, USA -Reto Bonderer, Switzerland -Alexei Botchkarev, Canada -Pieter Botman, Canada -Robert Bragner, USA -Kevin Brune, USA -Ogihara Bryan, USA -Luigi Buglione, Italy -Rick Cagle, USA -Barbara Canody, USA -Rogerio A. Carvalho, Brazil -Daniel Cerys, USA -Philippe Cohard, France -Ricardo Colomo-Palacios, Spain -Mauricio Coria, Argentina -Marek Cruz, UK -Stephen Danckert, USA -Bipul K. Das, Canada -James D. Davidson, USA -Jon Dehn, USA -Lincoln P. Djang, USA -Andreas Doblander, Austria -Yi-Ben Doo, USA -Scott J. Dougherty, UK -Regina DuBord, USA -Fedor Dzerzhinskiy, Russia -Ann M. Eblen, Australia -David M. Endres, USA -Marilyn Escue, USA -Varuna Eswer, India -Istvan Fay, Hungary -Jose L. Fernandez-Sanchez, Spain -Dennis J. Frailey, USA -Tihana Galinac Grbac, Croatia -Colin Garlick, New Zealand -Garth J.G. Glynn, UK -Jill Gostin, USA -Christiane Gresse von Wangenheim, Brazil -Thomas Gust, USA -H.N. Mok, Singapore -Jon D. Hagar, USA -Anees Ahmed Haidary, India -Duncan Hall, New Zealand -James Hart, USA -Jens H.J. Heidrich, Germany -Rich Hilliard, USA -Bob Hillier, Canada -Norman M. Hines, USA -Dave Hirst, USA -Theresa L. Hunt, USA -Kenneth Ingham, USA -Masahiko Ishikawa, Japan -Michael A. Jablonski, USA -G. Jagadeesh, India -Sebastian Justicia, Spain -Umut Kahramankaptan, Belgium -Pankaj Kamthan, Canada -Perry Kapadia, USA -Tarig A. Khalid, Sudan -Michael K.A. Klaes, Germany -Maged Koshty, Egypt -Claude C. Laporte, Canada -Dong Li, China -Ben Linders, Netherlands -Claire Lohr, USA -Vladimir Mandic, Serbia -Matt Mansell, New Zealand -John Marien, USA -Stephen P. Masticola, USA -Nancy Mead, USA -Fuensanta Medina-Dominguez, Spain -Silvia Judith Meles, Argentina -Oscar A. Mondragon, Mexico -David W. Mutschler, USA -Maria Nelson, Brazil -John Noblin, USA -Bryan G. Ogihara, USA -Takehisa Okazaki, Japan -Hanna Oktaba, Mexico -Chin Hwee Ong, Hong Kong -Venkateswar Oruganti, India -Birgit Penzenstadler, Germany -Larry Peters, USA -S.K. Pillai, India -Vaclav Rajlich, USA -Kiron Rao, India -Luis Reyes, USA -Hassan Reza, USA -Steve Roach, USA -Teresa L. Roberts, USA -Dennis Robi, USA -Warren E. Robinson, USA -Jorge L. Rodriguez, USA -Alberto C. Sampaio, Portugal -Ed Samuels, USA -Maria-Isabel Sanchez-Segura, Spain -Vineet Sawant, USA -R. Schaaf, USA -James C. Schatzman, USA -Oscar A. Schivo, Argentina -Florian Schneider, Germany -Thom Schoeffling, USA -Reinhard Schrage, Germany -Neetu Sethia, India -Cindy C. Shelton, USA -Alan Shepherd, Germany -Katsutoshi Shintani, Japan -Erik Shreve, USA -Jaguaraci Silva, Brazil -M. Somasundaram, India -Peraphon Sophatsathit, Thailand -John Standen, UK -Joyce Statz, USA -Perdita P. Stevens, UK -David Struble, USA -Ohno Susumu, Japan -Urcun Tanik, USA -Talin Tasciyan, USA -J. Barrie Thompson, UK -Steve Tockey, USA -Miguel Eduardo Torres Moreno, Colombia -Dawid Trawczynski, USA -Adam Trendowicz, Germany -Norio Ueno, Japan -Cenk Uyan, Turkey -Chandra Sekar Veerappan, Singapore -Oruganti Venkateswar, India -Jochen Vogt, Germany -Hironori Washizaki, Japan -Ulf Westermann, Germany -Don Wilson, USA -Aharon Yadin, Israel -Hong Zhou, UK - -**ACKNOWLEDGEMENTS** - -Funding for the development of _SWEBOK Guide_ V3 has been provided by the IEEE -Computer Society. The editors and coeditors appreciate the important work -performed by the KA editors and the contributing editors as well as by the the -members of the Change Control Board. The editorial team must also acknowledge -the indispensable contribution of reviewers. - -The editorial team also wishes to thank the following people who contributed to -the project in various ways: Pieter Botman, Evan Butterfield, Carine Chauny, -Pierce Gibbs, Diane Girard, John Keppler, Dorian McClenahan, Kenza Meridji, -Sam- uel Redwine, Annette Reilly, and Pam Thompson. Finally, there are surely -other people who have contributed to this Guide , either directly or -indirectly, whose names we have inadvertently omit- ted. To those people, we -offer our tacit appreciation and apologize for having omitted explicit -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 - -**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 ini- tiated 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 - -SWEBOK -Software Engineering Body of -Knowledge - -Publication of the 2004 version of this _Guide to the Software Engineering Body -of Knowledge_ (SWEBOK 2004) was a major milestone in establishing software -engineering as a recognized engineering discipline. The goal in developing this -update to SWEBOK is to improve the currency, readability, consistency, and -usability of the _Guide_. - -All knowledge areas (KAs) have been updated to reflect changes in software -engineering since publication of SWEBOK 2004. Four new foundation KAs and a -Software Engineering Profes sional Practices KA have been added. The Software -Engineering Tools and Methods KA has been revised as Software Engineering -Models and Methods. Software engineering tools is now a topic in each of the -KAs. Three appendices provide the specifications for the KA description, an -annotated set of relevant standards for each KA, and a listing of the -references cited in the _Guide_. - -This _Guide_, written under the auspices of the Professional Activities Board -of the IEEE Computer Society, represents a next step in the evolution of the -software engineering profession. - -**WHAT IS SOFTWARE ENGINEERING?** - -ISO/IEC/IEEE Systems and Software Engineering Vocabulary (SEVOCAB) defines -software engineering as “the application of a systematic, disciplined, -quantifiable approach to the development, operation, and maintenance of -software; that is, the application of engineering to software).”^1 - -**WHAT ARE THE OBJECTIVES OF THE SWEBOK GUIDE?** - -The _Guide_ should not be confused with the Body of Knowledge itself, which -exists in the published - -1 See [http://www.computer.org/sevocab.](http://www.computer.org/sevocab.) - -literature. The purpose of the Guide is to describe the portion of the Body of -Knowledge that is generally accepted, to organize that portion, and to provide -topical access to it. - -The Guide to the Software Engineering Body of Knowledge ( SWEBOK Guide ) was -established with the following five objectives: - -1. To promote a consistent view of software engineering worldwide -2. To specify the scope of, and clarify the place of software engineering with -respect to other disciplines such as computer science, project management, -computer engineering, and mathematics -3. To characterize the contents of the software engineering discipline -4. To provide a topical access to the Software Engineering Body of Knowledge -5. To provide a foundation for curriculum development and for individual -certification and licensing material - -The first of these objectives, a consistent worldwide view of software -engineering, was supported by a development process which engaged approximately -150 reviewers from 33 countries. More information regarding the development -process can be found on the website (www.swebok.org). Professional and learned -societies and public agencies involved in software engineering were contacted, -made aware of this project to update SWEBOK, and invited to participate in the -review process. KA editors were recruited from North America, the Pacific Rim, -and Europe. Presentations on the project were made at various international -venues. The second of the objectives, the desire to specify the scope of -software engineering, motivates the fundamental organization of the Guide. The -material that is recognized as being within this discipline is organized into -the fifteen KAs listed in Table I.1. Each of these KAs is treated in a chapter -in this Guide. - -Table I.1. The 15 SWEBOK KAs - -Software Requirements -Software Design -Software Construction -Software Testing -Software Maintenance -Software Configuration Management -Software Engineering Management -Software Engineering Process -Software Engineering Models and Methods -Software Quality -Software Engineering Professional Practice -Software Engineering Economics -Computing Foundations -Mathematical Foundations -Engineering Foundations - -In specifying scope, it is also important to identify the disciplines that -intersect with software engineering. To this end, SWEBOK V3 also recognizes -seven related disciplines, listed in Table I.2. Software engineers should, of -course, have knowledge of material from these disciplines (and the KA -descriptions in this _Guide_ may make reference to them). It is not, however, -an objective of the _SWEBOK Guide_ to characterize the knowledge of the related -disciplines. - -Table I.2. Related Disciplines - -Computer Engineering -Computer Science -General Management -Mathematics -Project Management -Quality Management -Systems Engineering - -The relevant elements of computer science and mathematics are presented in the -Computing Foundations and Mathematical Foundations KAs of the _Guide_ (Chapters -13 and 14). - -##### HIERARCHICAL ORGANIZATION - -The organization of the KA chapters supports the third of the project’s -objectives - a characterization of the contents of software engineering. The -detailed specifications provided by the project’s editorial team to the -associate editors regarding the contents of the KA descriptions can be found in -Appendix A. - -The Guide uses a hierarchical organization to decompose each KA into a set of -topics with recognizable labels. A two (sometime three) level breakdown -provides a reasonable way to find topics of interest. The Guide treats the -selected topics in a manner compatible with major schools of thought and with -breakdowns generally found in industry and in software engineering literature -and standards. The breakdowns of topics do not presume particular application -domains, business uses, management philosophies, development methods, and so -forth. The extent of each topic’s description is only that needed to understand -the generally accepted nature of the topics and for the reader to successfully -find reference material; the Body of Knowledge is found in the reference -materials themselves, not in the Guide. - -REFERENCE MATERIAL AND MATRIX - -To provide topical access to the knowledge-the fourth of the project’s -objectives-the Guide identifies authoritative reference material for each KA. -Appendix C provides a Consolidated Reference List for the Guide. Each KA -includes relevant references from the Consolidated Reference List and also -includes a matrix relating the reference material to the included topics. It -should be noted that the Guide does not attempt to be comprehensive in its -citations. Much material that is both suitable and excellent is not -referenced. Material included in the Consolidated Reference List provides -coverage of the topics described. - -DEPTH OF TREATMENT - -To achieve the SWEBOK fifth objective-providing a foundation for curriculum -development, - -Introduction - -certification, and licensing, the criterion of _generally accepted_ knowledge -has been applied, to be distinguished from advanced and research knowledge (on -the grounds of maturity) and from specialized knowledge (on the grounds of -generality of application). - -The equivalent term _generally recognized_ comes from the Project Management -Institute: “Generally recognized means the knowledge and practices described -are applicable to most projects most of the time, and there is consensus about -their value and usefulness.”^2 However, the terms “generally accepted” or -“generally recognized” do not imply that the designated knowledge should be -uniformly applied to all software engineering endeavors—each project’s needs -determine that—but it does imply that competent, capable software engineers -should be equipped with this knowledge for potential application. More -precisely, generally accepted knowledge should be included in the study -material for the software engineering licensing exami- nation that graduates -would take after gaining four years of work experience. Although this criterion -is specific to the US style of education and does not necessarily apply to -other countries, we deem it useful. - -**STRUCTURE OF THE KA DESCRIPTIONS** - -The KA descriptions are structured as follows. In the introduction, a brief -definition of the KA and an overview of its scope and of its relationship -with other KAs are presented. - -_A Guide to the Project Management Body of Knowledge_, 5th ed., Project -Management Institute, 2013; [http://www.pmi.org.](http://www.pmi.org.) - -The breakdown of topics in each KA constitutes the core the KA description, -describing the decomposition of the KA into subareas, topics, and sub-topics. -For each topic or subtopic, a short description is given, along with one or -more references. - -The reference material was chosen because it is considered to constitute the -best presentation of the knowledge relative to the topic. A matrix links the -topics to the reference material. The last part of each KA description is the -list of recommended references and (optionally) further readings. Relevant -standards for each KA are presented in Appendix B of the Guide. - -APPENDIX A. KA DESCRIPTION SPECIFICATIONS - -Appendix A describes the specifications provided by the editorial team to the -associate editors for the content, recommended references, format, and style of -the KA descriptions. - -APPENDIX B. ALLOCATION OF STANDARDS TO KAS - -Appendix B is an annotated list of the relevant standards, mostly from the IEEE -and the ISO, for each of the KAs of the SWEBOK Guide. - -APPENDIX C. CONSOLIDATED -REFERENCE LIST - -Appendix C contains the consolidated list of recommended references cited in -the KAs (these references are marked with an asterisk (*) in the text). blob - cf1bd037eb2e63e4c5f1c34e1f9a0a4c999ddcc6 (mode 644) blob + /dev/null --- 10_software_quality.markdown +++ /dev/null @@ -1,1584 +0,0 @@ -**CHAPTER 10** - -**SOFTWARE QUALITY** - -##### ACRONYMS - -##### CMMI - -Capability Maturity Model -Integration -CoSQ Cost of Software Quality - -COTS -Commercial Off-the-Shelf -Software -FMEA Failure Mode and Effects Analysis -FTA Fault Tree Analysis -PDCA Plan-Do-Check-Act -PDSA Plan-Do-Study-Act -QFD Quality Function Deployment -SPI Software Process Improvement -SQA Software Quality Assurance -SQC Software Quality Control -SQM Software Quality Management -TQM Total Quality Management -V&V Verification and Validation - -##### INTRODUCTION - -What is software quality, and why is it so impor- tant that it is included in -many knowledge areas (KAs) of the _SWEBOK Guide_? - -One reason is that the term _software quality_ is overloaded. Software quality -may refer: to desirable characteristics of software products, to the extent to -which a particular software product possess those characteristics, and to -processes, tools, and techniques used to achieve those characteristics. Over -the years, authors and organizations have defined the term quality differently. -To Phil Crosby, it was “conformance to requirements” [1]. Watts Humphrey refers -to it as “achieving excellent levels of “fitness for use” [2]. Meanwhile, IBM -coined the phrase “market-driven quality,” where the “customer is the final arbiter” -[3*, p8]. - -More recently, software quality is defined as the -“capability of software product to satisfy stated -and implied needs under specified conditions” [4] -and as “the degree to which a software product -meets established requirements; however, quality -depends upon the degree to which those estab- -lished requirements accurately represent stake- -holder needs, wants, and expectations” [5]. Both -definitions embrace the premise of conformance -to requirements. Neither refers to types of require- -ments (e.g., functional, reliability, performance, -dependability, or any other characteristic). Signifi- -cantly, however, these definitions emphasize that -quality is dependent upon requirements. -These definitions also illustrate another reason -for the prevalence of software quality through- -out this Guide : a frequent ambiguity of software -quality versus software quality requirements -(“the -ilities ” is a common shorthand). Software -quality requirements are actually attributes of (or -constraints on) functional requirements (what -the system does). Software requirements may -also specify resource usage, a communication -protocol, or many other characteristics. This KA -attempts clarity by using software quality in the -broadest sense from the definitions above and -by using software quality requirements as con- -straints on functional requirements. Software -quality is achieved by conformance to all require- -ments regardless of what characteristic is speci- -fied or how requirements are grouped or named. -Software quality is also considered in many of -the SWEBOK KAs because it is a basic param- -eter of a software engineering effort. For all engi- -neered products, the primary goal is delivering -maximum stakeholder value, while balancing the -constraints of development cost and schedule; -this is sometimes characterized as “fitness for -``` - -**10-2** **_SWEBOK® Guide_** **V3.0** - -use.” Stakeholder value is expressed in require- -ments. For software products, stakeholders could -value price (what they pay for the product), lead -time (how fast they get the product), and software -quality. -This KA addresses definitions and provides an -overview of practices, tools, and techniques for -defining software quality and for appraising the -state of software quality during development, -maintenance, and deployment. Cited references -provide additional details. - -**BREAKDOWN OF TOPICS FOR -SOFTWARE QUALITY** - -The breakdown of topics for the Software Quality -KA is presented in Figure 10.1. - -**1. Software Quality Fundamentals** - -Reaching agreement on what constitutes quality -for all stakeholders and clearly communicating -that agreement to software engineers require that - -``` -the many aspects of quality be formally defined -and discussed. -A software engineer should understand qual- -ity concepts, characteristics, values, and their -application to the software under development or -maintenance. The important concept is that the -software requirements define the required quality -attributes of the software. Software requirements -influence the measurement methods and accep- -tance criteria for assessing the degree to which -the software and related documentation achieve -the desired quality levels. -``` -``` -1.1. Software Engineering Culture and Ethics -[3*, c1s4] [6*, c2s3.5] -``` -``` -Software engineers are expected to share a com- -mitment to software quality as part of their culture. -A healthy software engineering culture includes -many characteristics, including the understanding -that tradeoffs among cost, schedule, and quality -are a basic tenant of the engineering of any prod- -uct. A strong software engineering ethic assumes -``` -``` -Figure 10.1. Breakdown of Topics for the Software Quality KA -``` - -``` -Software Quality 10-3 -``` -that engineers accurately report information, con- -ditions, and outcomes related to quality. -Ethics also play a significant role in software -quality, the culture, and the attitudes of software -engineers. The IEEE Computer Society and the -ACM have developed a code of ethics and pro- -fessional practice (see Codes of Ethics and Pro- -fessional Conduct in the Software Engineering -Professional Practice KA). - -_1.2. Value and Costs of Quality_ -[7*, c17, c22] - -Defining and then achieving software quality is -not simple. Quality characteristics may or may -not be required, or they may be required to a -greater or lesser degree, and tradeoffs may be -made among them. To help determine the level -of software quality, i.e., achieving stakeholder -value, this section presents cost of software qual- -ity (CoSQ): a set of measurements derived from -the economic assessment of software quality -development and maintenance processes. The -CoSQ measurements are examples of process -measurements that may be used to infer charac- -teristics of a product. -The premise underlying the CoSQ is that the -level of quality in a software product can be -inferred from the cost of activities related to deal- -ing with the consequences of poor quality. Poor -quality means that the software product does not -fully “satisfy stated and implied needs” or “estab- -lished requirements.” There are four cost of qual- -ity categories: prevention, appraisal, internal fail- -ure, and external failure. -Prevention costs include investments in software -process improvement efforts, quality infrastruc- -ture, quality tools, training, audits, and manage- -ment reviews. These costs are usually not specific -to a project; they span the organization. Appraisal -costs arise from project activities that find defects. -These appraisal activities can be categorized into -costs of reviews (design, peer) and costs of test- -ing (software unit testing, software integration, -system level testing, acceptance testing); appraisal -costs would be extended to subcontracted software -suppliers. Costs of internal failures are those that -are incurred to fix defects found during appraisal -activities and discovered prior to delivery of the - -``` -software product to the customer. External fail- -ure costs include activities to respond to software -problems discovered after delivery to the customer. -Software engineers should be able to use CoSQ -methods to ascertain levels of software quality -and should also be able to present quality alter- -natives and their costs so that tradeoffs between -cost, schedule, and delivery of stakeholder value -can be made. -``` -``` -1.3. Models and Quality Characteristics -[3*, c24s1] [7*, c2s4] [8*, c17] -``` -``` -Terminology for software quality characteristics -differs from one taxonomy (or model of software -quality) to another, each model perhaps having -a different number of hierarchical levels and a -different total number of characteristics. Various -authors have produced models of software qual- -ity characteristics or attributes that can be useful -for discussing, planning, and rating the quality -of software products. ISO/IEC 25010: 2011 [4] -defines product quality and quality in use as two -related quality models. Appendix B in the SWE- -BOK Guide provides a list of applicable standards -for each KA. Standards for this KA cover various -ways of characterizing software quality. -``` -``` -1.3.1. Software Process Quality -``` -``` -Software quality management and software engi- -neering process quality have a direct bearing on -the quality of the software product. -Models and criteria that evaluate the capabili- -ties of software organizations are primarily proj- -ect organization and management considerations -and, as such, are covered in the Software Engi- -neering Management and Software Engineering -Process KAs. -It is not possible to completely distinguish pro- -cess quality from product quality because process -outcomes include products. Determining whether -a process has the capability to consistently pro- -duce products of desired quality is not simple. -The software engineering process, discussed -in the Software Engineering Process KA, influ- -ences the quality characteristics of software prod- -ucts, which in turn affect quality as perceived by -stakeholders. -``` - -**10-4** **_SWEBOK® Guide_** **V3.0** - -``` -1.3.2. Software Product Quality -``` -The software engineer, first of all, must determine -the real purpose of the software. In this regard, -stakeholder requirements are paramount, and they -include quality requirements in addition to func- -tional requirements. Thus, software engineers -have a responsibility to elicit quality requirements -that may not be explicit at the outset and to under- -stand their importance as well as the level of diffi- -culty in attaining them. All software development -processes (e.g., eliciting requirements, designing, -constructing, building, checking, improving qual- -ity) are designed with these quality requirements -in mind and may carry additional development -costs if attributes such as safety, security, and -dependability are important. The additional devel- -opment costs help ensure that quality obtained can -be traded off against the anticipated benefits. -The term work-product means any artifact that -is the outcome of a process used to create the -final software product. Examples of a work-prod- -uct include a system/subsystem specification, a -software requirements specification for a soft- -ware component of a system, a software design -description, source code, software test documen- -tation, or reports. While some treatments of qual- -ity are described in terms of final software and -system performance, sound engineering practice -requires that intermediate work-products relevant -to quality be evaluated throughout the software -engineering process. - -_1.4. Software Quality Improvement_ -[3*, c1s4] [9*, c24] [10*, c11s2.4] - -The quality of software products can be improved -through preventative processes or an itera- -tive process of continual improvement, which -requires management control, coordination, and -feedback from many concurrent processes: (1) -the software life cycle processes, (2) the process -of fault/defect detection, removal, and preven- -tion, and (3) the quality improvement process. -The theory and concepts behind qual- -ity improvement—such as building in quality -through the prevention and early detection of -defects, continual improvement, and stakeholder -focus—are pertinent to software engineering. -These concepts are based on the work of experts - -``` -in quality who have stated that the quality of a -product is directly linked to the quality of the -process used to create it. Approaches such as the -Deming improvement cycle of Plan-Do-Check- -Act (PDCA), evolutionary delivery, kaizen, and -quality function deployment (QFD) offer tech- -niques to specify quality objectives and determine -whether they are met. The Software Engineering -Institute’s IDEAL is another method [7*]. Qual- -ity management is now recognized by the SWE- -BOK Guide as an important discipline. -Management sponsorship supports process and -product evaluations and the resulting findings. -Then an improvement program is developed -identifying detailed actions and improvement -projects to be addressed in a feasible time frame. -Management support implies that each improve- -ment project has enough resources to achieve the -goal defined for it. Management sponsorship is -solicited frequently by implementing proactive -communication activities. -``` -``` -1.5. Software Safety -[9*, c11s3] -``` -``` -Safety-critical systems are those in which a sys- -tem failure could harm human life, other living -things, physical structures, or the environment. -The software in these systems is safety-critical. -There are increasing numbers of applications -of safety-critical software in a growing number -of industries. Examples of systems with safety- -critical software include mass transit systems, -chemical manufacturing plants, and medical -devices. The failure of software in these systems -could have catastrophic effects. There are indus- -try standards, such as DO-178C [11], and emerg- -ing processes, tools, and techniques for develop- -ing safetycritical software. The intent of these -standards, tools, and techniques is to reduce the -risk of injecting faults into the software and thus -improve software reliability. -Safety-critical software can be categorized as -direct or indirect. Direct is that software embed- -ded in a safety-critical system, such as the flight -control computer of an aircraft. Indirect includes -software applications used to develop safety- -critical software. Indirect software is included in -software engineering environments and software -test environments. -``` - -``` -Software Quality 10-5 -``` -Three complementary techniques for reduc- -ing the risk of failure are avoidance, detection -and removal, and damage limitation. These -techniques impact software functional require- -ments, software performance requirements, and -development processes. Increasing levels of risk -imply increasing levels of software quality assur- -ance and control techniques such as inspections. -Higher risk levels may necessitate more thorough -inspections of requirements, design, and code -or the use of more formal analytical techniques. -Another technique for managing and control- -ling software risk is building assurance cases. An -assurance case is a reasoned, auditable artifact -created to support the contention that its claim -or claims are satisfied. It contains the following -and their relationships: one or more claims about -properties; arguments that logically link the evi- -dence and any assumptions to the claims; and a -body of evidence and assumptions supporting -these arguments [12]. - -**2. Software Quality Management Processes** - -Software quality management is the collection of -all processes that ensure that software products, -services, and life cycle process implementations -meet organizational software quality objectives -and achieve stakeholder satisfaction [13, 14]. -SQM defines processes, process owners, require- -ments for the processes, measurements of the -processes and their outputs, and feedback chan- -nels throughout the whole software life cycle. -SQM comprises four subcategories: software -quality planning, software quality assurance -(SQA), software quality control (SQC), and soft- -ware process improvement (SPI). Software qual- -ity planning includes determining which quality -standards are to be used, defining specific quality -goals, and estimating the effort and schedule of -software quality activities. In some cases, soft- -ware quality planning also includes defining the -software quality processes to be used. SQA activ- -ities define and assess the adequacy of software -processes to provide evidence that establishes -confidence that the software processes are appro- -priate for and produce software products of suit- -able quality for their intended purposes [5]. SQC -activities examine specific project artifacts (docu- -ments and executables) to determine whether they - -``` -comply with standards established for the project -(including requirements, constraints, designs, -contracts, and plans). SQC evaluates intermedi- -ate products as well as the final products. -The fourth SQM category dealing with improve- -ment has various names within the software indus- -try, including SPI, software quality improvement, -and software corrective and preventive action. The -activities in this category seek to improve process -effectiveness, efficiency, and other characteris- -tics with the ultimate goal of improving software -quality. Although SPI could be included in any of -the first three categories, an increasing number -of organizations organize SPI into a separate cat- -egory that may span across many projects (see the -Software Engineering Process KA). -Software quality processes consist of tasks -and techniques to indicate how software plans -(e.g., software management, development, qual- -ity management, or configuration management -plans) are being implemented and how well the -intermediate and final products are meeting their -specified requirements. Results from these tasks -are assembled in reports for management before -corrective action is taken. The management of -an SQM process is tasked with ensuring that the -results of these reports are accurate. -Risk management can also play an important -role in delivering quality software. Incorporating -disciplined risk analysis and management tech- -niques into the software life cycle processes can -help improve product quality (see the Software -Engineering Management KA for related mate- -rial on risk management). -``` -``` -2.1. Software Quality Assurance -[7*, c4–c6, c11, c12, c26–27] -``` -``` -To quell a widespread misunderstanding, soft- -ware quality assurance is not testing. software -quality assurance (SQA) is a set of activities that -define and assess the adequacy of software pro- -cesses to provide evidence that establishes confi- -dence that the software processes are appropriate -and produce software products of suitable qual- -ity for their intended purposes. A key attribute of -SQA is the objectivity of the SQA function with -respect to the project. The SQA function may -also be organizationally independent of the proj- -ect; that is, free from technical, managerial, and -``` - -**10-6** **_SWEBOK® Guide_** **V3.0** - -financial pressures from the project [5]. SQA has -two aspects: product assurance and process assur- -ance, which are explained in section 2.3. -The software quality plan (in some industry -sectors it is termed the software quality assurance -plan) defines the activities and tasks employed -to ensure that software developed for a specific -product satisfies the project’s established require- -ments and user needs within project cost and -schedule constraints and is commensurate with -project risks. The SQAP first ensures that quality -targets are clearly defined and understood. -The SQA plan’s quality activities and tasks are -specified with their costs, resource requirements, -objectives, and schedule in relation to related -objectives in the software engineering manage- -ment, software development, and software main- -tenance plans. The SQA plan should be consis- -tent with the software configuration management -plan (see the Software Configuration Manage- -ment KA). The SQA plan identifies documents, -standards, practices, and conventions governing -the project and how these items are checked and -monitored to ensure adequacy and compliance. -The SQA plan also identifies measures; statistical -techniques; procedures for problem reporting and -corrective action; resources such as tools, tech- -niques, and methodologies; security for physical -media; training; and SQA reporting and docu- -mentation. Moreover, the SQA plan addresses -the software quality assurance activities of any -other type of activity described in the software -plans—such as procurement of supplier software -for the project, commercial off-the-shelf software -(COTS) installation, and service after delivery of -the software. It can also contain acceptance crite- -ria as well as reporting and management activi- -ties that are critical to software quality. - -_2.2. Verification & Validation_ -[9*, c2s2.3, c8, c15s1.1, c21s3.3] - -As stated in [15], - -``` -The purpose of V&V is to help the devel- -opment organization build quality into the -system during the life cycle. V&V pro- -cesses provide an objective assessment -of products and processes throughout the -``` -``` -life cycle. This assessment demonstrates -whether the requirements are correct, com- -plete, accurate, consistent, and testable. -The V&V processes determine whether -the development products of a given activ- -ity conform to the requirements of that -activity and whether the product satisfies -its intended use and user needs. -``` -``` -Verification is an attempt to ensure that the -product is built correctly, in the sense that the -output products of an activity meet the specifi- -cations imposed on them in previous activities. -Validation is an attempt to ensure that the right -product is built—that is, the product fulfills its -specific intended purpose. Both the verification -process and the validation process begin early -in the development or maintenance phase. They -provide an examination of key product features -in relation to both the product’s immediate prede- -cessor and the specifications to be met. -The purpose of planning V&V is to ensure that -each resource, role, and responsibility is clearly -assigned. The resulting V&V plan documents -describe the various resources and their roles and -activities, as well as the techniques and tools to be -used. An understanding of the different purposes of -each V&V activity helps in the careful planning of -the techniques and resources needed to fulfill their -purposes. The plan also addresses the manage- -ment, communication, policies, and procedures of -the V&V activities and their interaction, as well as -defect reporting and documentation requirements. -``` -``` -2.3. Reviews and Audits -[9*, c24s3] [16*] -``` -``` -Reviews and audit processes are broadly defined -as static—meaning that no software programs or -models are executed—examination of software -engineering artifacts with respect to standards that -have been established by the organization or proj- -ect for those artifacts. Different types of reviews -and audits are distinguished by their purpose, lev- -els of independence, tools and techniques, roles, -and by the subject of the activity. Product assur- -ance and process assurance audits are typically -conducted by software quality assurance (SQA) -personnel who are independent of development -``` - -``` -Software Quality 10-7 -``` -teams. Management reviews are conducted by -organizational or project management. The engi- -neering staff conducts technical reviews. - -- Management reviews evaluate actual project - results with respect to plans. -- Technical reviews (including inspections, - walkthrough, and desk checking) examine - engineering work-products. -- Process assurance audits. SQA process - assurance activities make certain that the - processes used to develop, install, operate, - and maintain software conform to contracts, - comply with any imposed laws, rules, and - regulations and are adequate, efficient and - effective for their intended purpose [5]. -- Product assurance audits. SQA product - assurance activities make certain to provide - evidence that software products and related - documentation are identified in and comply - with contracts; and ensure that nonconfor- - mances are identified and addressed [5]. - -``` -2.3.1. Management Reviews -``` -As stated in [16*], - -``` -The purpose of a management review is to -monitor progress, determine the status of -plans and schedules, and evaluate the effec- -tiveness of management processes, tools -and techniques. Management reviews com- -pare actual project results against plans to -determine the status of projects or mainte- -nance efforts. The main parameters of man- -agement reviews are project cost, schedule, -scope, and quality. Management reviews -evaluate decisions about corrective actions, -changes in the allocation of resources, or -changes to the scope of the project. -``` -Inputs to management reviews may include -audit reports, progress reports, V&V reports, and -plans of many types, including risk management, -project management, software configuration -management, software safety, and risk assess- -ment, among others. (Refer to the Software Engi- -neering Management and the Software Configu- -ration Management KAs for related material.) - -``` -2.3.2. Technical Reviews -``` -``` -As stated in [16*], -``` -``` -The purpose of a technical review is to -evaluate a software product by a team of -qualified personnel to determine its suit- -ability for its intended use and identify -discrepancies from specifications and -standards. It provides management with -evidence to confirm the technical status of -the project. -``` -``` -Although any work-product can be reviewed, -technical reviews are performed on the main -software engineering work-products of software -requirements and software design. -Purpose, roles, activities, and most importantly -the level of formality distinguish different types -of technical reviews. Inspections are the most for- -mal, walkthroughs less, and pair reviews or desk -checks are the least formal. -Examples of specific roles include a decision -maker (i.e., software lead), a review leader, a -recorder, and checkers (technical staff members -who examine the work-products). Reviews are -also distinguished by whether meetings (face to -face or electronic) are included in the process. In -some review methods checkers solitarily exam- -ine work-products and send their results back to -a coordinator. In other methods checkers work -cooperatively in meetings. A technical review -may require that mandatory inputs be in place in -order to proceed: -``` -- Statement of objectives -- Specific software product -- Specific project management plan -- Issues list associated with this product -- Technical review procedure. - -``` -The team follows the documented review pro- -cedure. The technical review is completed once -all the activities listed in the examination have -been completed. -Technical reviews of source code may include a -wide variety of concerns such as analysis of algo- -rithms, utilization of critical computer resources, -adherence to coding standards, structure and -``` - -**10-8** **_SWEBOK® Guide_** **V3.0** - -organization of code for testability, and safety- -critical considerations. -Note that technical reviews of source code or -design models such as UML are also termed static -analysis (see topic 3, Practical Considerations). - -``` -2.3.3. Inspections -``` -“The purpose of an inspection is to detect and -identify software product anomalies” [16*]. -Some important differentiators of inspections as -compared to other types of technical reviews are -these: - -1. Rules. Inspections are based upon examining - a work-product with respect to a defined set - of criteria specified by the organization. Sets - of rules can be defined for different types of - workproducts (e.g., rules for requirements, - architecture descriptions, source code). -2. Sampling. Rather that attempt to examine - every word and figure in a document, the - inspection process allows checkers to evalu- - ate defined subsets (samples) of the docu- - ments under review. -3. Peer. Individuals holding management posi- - tions over members of the inspection team - do not participate in the inspection. This is - a key distinction between peer review and - management review. -4. Led. An impartial moderator who is trained - in inspection techniques leads inspection - meetings. -5. Meeting. The inspection process includes - meetings (face to face or electronic) con- - ducted by a moderator according to a formal - procedure in which inspection team mem- - bers report the anomalies they have found - and other issues. - -Software inspections always involve the author -of an intermediate or final product; other reviews -might not. Inspections also include an inspection -leader, a recorder, a reader, and a few (two to five) -checkers (inspectors). The members of an inspec- -tion team may possess different expertise, such as -domain expertise, software design method exper- -tise, or programming language expertise. Inspec- -tions are usually conducted on one relatively - -``` -small section of the product at a time (samples). -Each team member examines the software prod- -uct and other review inputs prior to the review -meeting, perhaps by applying an analytical tech- -nique (see section 3.3.3) to a small section of -the product or to the entire product with a focus -on only one aspect—e.g., interfaces. During the -inspection, the moderator conducts the session -and verifies that everyone has prepared for the -inspection and conducts the session. The inspec- -tion recorder documents anomalies found. A set -of rules, with criteria and questions germane to -the issues of interest, is a common tool used in -inspections. The resulting list often classifies the -anomalies (see section 3.2, Defect Characteriza- -tion) and is reviewed for completeness and accu- -racy by the team. The inspection exit decision -corresponds to one of the following options: -``` -1. Accept with no or, at most, minor reworking -2. Accept with rework verification -3. Reinspect. - -``` -2.3.4. Walkthroughs -``` -``` -As stated in [16*], -``` -``` -The purpose of a systematic walk-through -is to evaluate a software product. A walk- -through may be conducted for the purpose -of educating an audience regarding a soft- -ware product. -``` -``` -Walkthroughs are distinguished from inspec- -tions. The main difference is that the author pres- -ents the work-product to the other participants in -a meeting (face to face or electronic). Unlike an -inspection, the meeting participants may not have -necessarily seen the material prior to the meet- -ing. The meetings may be conducted less for- -mally. The author takes the role of explaining and -showing the material to participants and solicits -feedback. Like inspections, walkthroughs may be -conducted on any type of work-product including -project plan, requirements, design, source code, -and test reports. -``` - -``` -Software Quality 10-9 -``` -``` -2.3.5. Process Assurance and Product Assur- -ance Audits -``` -As stated in [16*], - -``` -The purpose of a software audit is to pro- -vide an independent evaluation of the con- -formance of software products and pro- -cesses to applicable regulations, standards, -guidelines, plans, and procedures. -``` -Process assurance audits determine the adequacy -of plans, schedules, and requirements to achieve -project objectives [5]. The audit is a formally -organized activity with participants having spe- -cific roles—such as lead auditor, another auditor, a -recorder, or an initiator—and including a represen- -tative of the audited organization. Audits identify -instances of nonconformance and produce a report -requiring the team to take corrective action. -While there may be many formal names for -reviews and audits, such as those identified in the -standard [16*], the important point is that they -can occur on almost any product at any stage of -the development or maintenance process. - -**3. Practical Considerations** - -_3.1. Software Quality Requirements_ -[9*, c11s1] [18*, c12] -[17*, c15s3.2.2, c15s3.3.1, c16s9.10] - -``` -3.1.1. Influence Factors -``` -Various factors influence planning, management, -and selection of SQM activities and techniques, -including - -- the domain of the system in which the soft- - ware resides; the system functions could be - safety-critical, mission-critical, business- - critical, security-critical -- the physical environment in which the soft- - ware system resides -- system and software functional (what the - system does) and quality (how well the sys- - tem performs its functions) requirements -- the commercial (external) or standard (inter- - nal) components to be used in the system - - the specific software engineering standards - applicable - - the methods and software tools to be used for - development and maintenance and for qual- - ity evaluation and improvement - - the budget, staff, project organization, plans, - and scheduling of all processes - - the intended users and use of the system - - the integrity level of the system. - -``` -Information on these factors influences how -the SQM processes are organized and docu- -mented, how specific SQM activities are selected, -what resources are needed, and which of those -resources impose bounds on the efforts. -``` -``` -3.1.2. Dependability -``` -``` -In cases where system failure may have extremely -severe consequences, overall dependability (hard- -ware, software, and human or operational) is the -main quality requirement over and above basic -functionality. This is the case for the following -reasons: system failures affect a large number of -people; users often reject systems that are unre- -liable, unsafe, or insecure; system failure costs -may be enormous; and undependable systems -may cause information loss. System and soft- -ware dependability include such characteristics -as availability, reliability, safety, and security. -When developing dependable software, tools and -techniques can be applied to reduce the risk of -injecting faults into the intermediate deliverables -or the final software product. Verification, valida- -tion, and testing processes, techniques, methods, -and tools identify faults that impact dependability -as early as possible in the life cycle. Addition- -ally, mechanisms may need to be in place in the -software to guard against external attacks and to -tolerate faults. -``` -``` -3.1.3. Integrity Levels of Software -``` -``` -Defining integrity levels is a method of risk -management. -``` -``` -Software integrity levels are a range of -values that represent software complexity, -criticality, risk, safety level, security level, -``` - -**10-10** **_SWEBOK® Guide_** **V3.0** - -``` -desired performance, reliability, or other -project-unique characteristics that define -the importance of the software to the user -and acquirer. The characteristics used to -determine software integrity level vary -depending on the intended application and -use of the system. The software is a part of -the system, and its integrity level is to be -determined as a part of that system. -``` -The assigned software integrity levels may -change as the software evolves. Design, coding, -procedural, and technology features implemented -in the system or software can raise or lower the -assigned software integrity levels. The software -integrity levels established for a project result -from agreements among the acquirer, supplier, -developer, and independent assurance authorities. -A software integrity level scheme is a tool used in -determining software integrity levels. [5] -As noted in [17*], “the integrity levels can be -applied during development to allocate additional -verification and validation efforts to high-integ- -rity components.” - -_3.2. Defect Characterization_ -[3*, c3s3, c8s8, c10s2] - -Software quality evaluation (i.e., software quality -control) techniques find defects, faults and fail- -ures. Characterizing these techniques leads to an -understanding of the product, facilitates correc- -tions to the process or the product, and informs -management and other stakeholders of the sta- -tus of the process or product. Many taxonomies -exist and, while attempts have been made to gain -consensus, the literature indicates that there are -quite a few in use. Defect characterization is also -used in audits and reviews, with the review leader -often presenting a list of issues provided by team -members for consideration at a review meeting. -As new design methods and languages evolve, -along with advances in overall software technolo- -gies, new classes of defects appear, and a great -deal of effort is required to interpret previously -defined classes. When tracking defects, the soft- -ware engineer is interested in not only the number -of defects but also the types. Information alone, -without some classification, may not be sufficient -to identify the underlying causes of the defects. - -``` -Specific types of problems need to be grouped to -identify trends over time. The point is to establish -a defect taxonomy that is meaningful to the orga- -nization and to software engineers. -Software quality control activities discover infor- -mation at all stages of software development and -maintenance. In some cases, the word defect is -overloaded to refer to different types of anomalies. -However, different engineering cultures and stan- -dards may use somewhat different meanings for -these terms. The variety of terms prompts this sec- -tion to provide a widely used set of definitions [19]: -``` -- _Computational Error_ : “the difference - between a computed, observed, or measured - value or condition and the true, specified, or - theoretically correct value or condition.” -- _Error_ : “A human action that produces an - incorrect result.” A slip or mistake that a per- - son makes. Also called human error. -- _Defect_ : An “imperfection or deficiency in a - work product where that work product does - not meet its requirements or specifications - and needs to be either repaired or replaced.” - A defect is caused by a person committing - an error. -- _Fault_ : A defect in source code. An “incorrect - step, process, or data definition in computer - program.” The encoding of a human error in - source code. Fault is the formal name of a bug_._ -- _Failure_ : An “event in which a system or sys- - tem component does not perform a required - function within specified limits.” A failure is - produced when a fault is encountered by the - processor under specified conditions. - -``` -Using these definitions three widely used soft- -ware quality measurements are defect density -(number of defects per unit size of documents), -fault density (number of faults per 1K lines of -code), and failure intensity (failures per use-hour -or per test-hour). Reliability models are built -from failure data collected during software test- -ing or from software in service and thus can be -used to estimate the probability of future failures -and to assist in decisions on when to stop testing. -One probable action resulting from SQM find- -ings is to remove the defects from the product -under examination (e.g., find and fix bugs, create -new build). Other activities attempt to eliminate -``` - -``` -Software Quality 10-11 -``` -the causes of the defects—for example, root cause -analysis (RCA). RCA activities include analyzing -and summarizing the findings to find root causes -and using measurement techniques to improve -the product and the process as well as to track the -defects and their removal. Process improvement -is primarily discussed in the Software Engineer- -ing Process KA, with the SQM process being a -source of information. -Data on inadequacies and defects found by -software quality control techniques may be lost -unless they are recorded. For some techniques -(e.g., technical reviews, audits, inspections), -recorders are present to set down such informa- -tion, along with issues and decisions. When auto- -mated tools are used (see topic 4, Software Qual- -ity Tools), the tool output may provide the defect -information. Reports about defects are provided -to the management of the organization. - -_3.3. Software Quality Management Techniques_ -[7*, c7s3] [8*, c17] [9*, c12s5, c15s1, p417] -[16*] - -Software quality control techniques can be cat- -egorized in many ways, but a straightforward -approach uses just two categories: static and -dynamic. Dynamic techniques involve executing -the software; static techniques involve analyzing -documents and source code but not executing the -software. - -``` -3.3.1. Static Techniques -``` -Static techniques examine software documenta- -tion (including requirements, interface specifica- -tions, designs, and models) and software source -code without executing the code. There are many -tools and techniques for statically examining soft- -ware work-products (see section 2.3.2). In addi- -tion, tools that analyze source code control flow -and search for dead code are considered to be -static analysis tools because they do not involve -executing the software code. -Other, more formal, types of analytical tech- -niques are known as formal methods_._ They are -notably used to verify software requirements and -designs. They have mostly been used in the veri- -fication of crucial parts of critical systems, such -as specific security and safety requirements. (See - -``` -also Formal Methods in the Software Engineer- -ing Models and Methods KA.) -``` -``` -3.3.2. Dynamic Techniques -``` -``` -Dynamic techniques involve executing the soft- -ware code. Different kinds of dynamic techniques -are performed throughout the development and -maintenance of software. Generally, these are -testing techniques, but techniques such as simu- -lation and model analysis may be considered -dynamic (see the Software Engineering Models -and Methods KA). Code reading is considered a -static technique, but experienced software engi- -neers may execute the code as they read through -it. Code reading may utilize dynamic techniques. -This discrepancy in categorizing indicates that -people with different roles and experience in the -organization may consider and apply these tech- -niques differently. -Different groups may perform testing during -software development, including groups inde- -pendent of the development team. The Software -Testing KA is devoted entirely to this subject. -``` -``` -3.3.3. Testing -``` -``` -Two types of testing may fall under V&V because -of their responsibility for the quality of the mate- -rials used in the project: -``` -- Evaluation and tests of tools to be used on - the project -- Conformance tests (or review of confor- - mance tests) of components and COTS prod- - ucts to be used in the product. - -``` -Sometimes an independent (third-party or -IV&V) organization may be tasked to perform -testing or to monitor the test process V&V may -be called upon to evaluate the testing itself: ade- -quacy of plans, processes, and procedures, and -adequacy and accuracy of results. -The third party is not the developer, nor is it -associated with the development of the product. -Instead, the third party is an independent facil- -ity, usually accredited by some body of authority. -Their purpose is to test a product for conformance -to a specific set of requirements (see the Software -Testing KA). -``` - -**10-12** **_SWEBOK® Guide_** **V3.0** - -_3.4. Software Quality Measurement_ -[3*, c4] [8*, c17] [9*, p90] - -Software quality measurements are used to -support decision-making. With the increasing -sophistication of software, questions of quality -go beyond whether or not the software works to -how well it achieves measurable quality goals. -Decisions supported by software quality mea- -surement include determining levels of software -quality (notably because models of software -product quality include measures to determine -the degree to which the software product achieves -quality goals); managerial questions about effort, -cost, and schedule; determining when to stop test- -ing and release a product (see Termination under -section 5.1, Practical Considerations, in the Soft- -ware Testing KA); and determining the efficacy -of process improvement efforts. -The cost of SQM processes is an issue fre- -quently raised in deciding how a project or a soft- -ware development and maintenance group should -be organized. Often, generic models of cost are -used, which are based on when a defect is found -and how much effort it takes to fix the defect rela- -tive to finding the defect earlier in the develop- -ment process. Software quality measurement data -collected internally may give a better picture of -cost within this project or organization. -While the software quality measurement data -may be useful in itself (e.g., the number of defec- -tive requirements or the proportion of defective -requirements), mathematical and graphical tech- -niques can be applied to aid in the interpretation -of the measures (see the Engineering Foundations -KA). These techniques include - -- descriptive statistics based (e.g., Pareto - analysis, run charts, scatter plots, normal - distribution) -- statistical tests (e.g., the binomial test, chi- - squared test) -- trend analysis (e.g., control charts; see - _The Quality Toolbox_ in the list of further - readings) -- prediction (e.g., reliability models). - -Descriptive statistics-based techniques and -tests often provide a snapshot of the more - -``` -troublesome areas of the software product under -examination. The resulting charts and graphs -are visualization aids, which the decision mak- -ers can use to focus resources and conduct pro- -cess improvements where they appear to be most -needed. Results from trend analysis may indicate -that a schedule is being met, such as in testing, or -that certain classes of faults may become more -likely to occur unless some corrective action is -taken in development. The predictive techniques -assist in estimating testing effort and schedule -and in predicting failures. More discussion on -measurement in general appears in the Software -Engineering Process and Software Engineering -Management KAs. More specific information on -testing measurement is presented in the Software -Testing KA. -Software quality measurement includes mea- -suring defect occurrences and applying statistical -methods to understand the types of defects that -occur most frequently. This information may be -used by software process improvement for deter- -mining methods to prevent, reduce, or eliminate -their recurrence. They also aid in understanding -trends, how well detection and containment tech- -niques are working, and how well the develop- -ment and maintenance processes are progressing. -From these measurement methods, defect -profiles can be developed for a specific applica- -tion domain. Then, for the next software project -within that organization, the profiles can be used -to guide the SQM processes—that is, to expend -the effort where problems are most likely to occur. -Similarly, benchmarks, or defect counts typical of -that domain, may serve as one aid in determining -when the product is ready for delivery. Discus- -sion on using data from SQM to improve devel- -opment and maintenance processes appears in the -Software Engineering Management and Software -Engineering Process KAs. -``` -**4. Software Quality Tools** - -``` -Software quality tools include static and dynamic -analysis tools. Static analysis tools input source -code, perform syntactical and semantic analysis -without executing the code, and present results to -users. There is a large variety in the depth, thor- -oughness, and scope of static analysis tools that -``` - -``` -Software Quality 10-13 -``` -can be applied to artifacts including models, in -addition to source code. (See the Software Con- -struction, Software Testing, and Software Main- -tenance KAs for descriptions of dynamic analysis -tools.) -Categories of static analysis tools include the -following: - -- Tools that facilitate and partially automate - reviews and inspections of documents and - code. These tools can route work to differ- - ent participants in order to partially automate - and control a review process. They allow - users to enter defects found during inspec- - tions and reviews for later removal. -- Some tools help organizations perform soft- - ware safety hazard analysis. These tools - provide, e.g., automated support for failure - mode and effects analysis (FMEA) and fault - tree analysis (FTA). - - Tools that support tracking of software prob- - lems provide for entry of anomalies discov- - ered during software testing and subsequent - analysis, disposition, and resolution. Some - tools include support for workflow and for - tracking the status of problem resolution. - - Tools that analyze data captured from soft- - ware engineering environments and soft- - ware test environments and produce visual - displays of quantified data in the form of - graphs, charts, and tables. These tools some- - times include the functionality to perform - statistical analysis on data sets (for the pur- - pose of discerning trends and making fore- - casts). Some of these tools provide defect - and removal injection rates; defect densities; - yields; distribution of defect injection and - removal for each of the life cycle phases. - - -**10-14** **_SWEBOK® Guide_** **V3.0** - -##### MATRIX OF TOPICS VS. REFERENCE MATERIAL - -``` -Kan 2002 -``` -##### [3*] - -``` -Bott et al. 2000 -``` -##### [6*] - -``` -Galin 2004 -``` -##### [7*] - -``` -Naik and Tripathy 2008 -``` -##### [8*] - -``` -Sommerville 2011 -``` -##### [9*] - -``` -Voland 2003 -``` -##### [10*] - -``` -IEEE Std. 1028-2008 -``` -##### [16*] - -``` -Moore 2006 -``` -##### [17*] - -``` -Wiegers 2003 -``` -##### [18*] - -**1. Software -Quality -Fundamentals** - 1.1. Software - Engineering - Culture and - Ethics - -``` -c1s4 c2s3.5 -``` -``` -1.2. Va lue a nd -Cost of Quality -``` -``` -c17, -c22 -1.3. Models -and Quality -Characteristics -``` -``` -c24s1 c2s4 c17 -``` -``` -1.4. Software -Quality -Improvement -``` -``` -c1s4 c24 -c11 -s2.4 -``` -``` -1.5. Software -Safety -c11s3 -``` -**2. Software -Quality -Management -Processes** - 2.1. Software - Quality - Assurance - -``` -c4–c6, -c11, -c26–27 -``` -``` -2.2. Verification -and Validation -``` -``` -c2 -s2.3, -c8, c15 -s1.1, -c21 -s3.3 -2.3. Reviews -and Audits -c24s3 * -``` - -``` -Software Quality 10-15 -``` -``` -Kan 2002 -``` -##### [3*] - -``` -Bott et al. 2000 -``` -##### [6*] - -``` -Galin 2004 -``` -##### [7*] - -``` -Naik and Tripathy 2008 -``` -##### [8*] - -``` -Sommerville 2011 -``` -##### [9*] - -``` -Voland 2003 -``` -##### [10*] - -``` -IEEE Std. 1028-2008 -``` -##### [16*] - -``` -Moore 2006 -``` -##### [17*] - -``` -Wiegers 2003 -``` -##### [18*] - -**3. Software -Quality Practical -Considerations** - -``` -3.1. Software -Quality -Requirements -``` -``` -c11s1 -``` -``` -c15 -s3.2.2, -c15 -s3.3.1, -c16 -s9.10 -``` -``` -c12 -``` -``` -3.2. Defect -Characterization -``` -``` -c3s3, -c8s8, -c10 s2 -``` -``` -3.3. SQM -Te c h n i q u e s -c7s3 c17 -``` -``` -c12s5, -c15s1, -p417 -``` -##### * - -``` -3.4. Software -Quality -Measurement -``` -``` -c4 c17 p90 -``` -**4. Software -Q u a l i t y To o l s** - -##### FURTHER READINGS - -N. Leveson, _Safeware: System Safety and Computers_ [20]. - -This book describes the importance of software safety practices and how these -practices can be incorporated into software development projects. - -T. Gilb, _Principles of Software Engineering Management_ [21]. - -This is one of the first books on iterative and incremental development -techniques. The Evo Method defines quantified goals, frequent timeboxed -iterations, measurements of progress toward goals, and adaptation of plans -based on actual results. - -T. Gilb and D. Graham, _Software Inspection_ [22]. - -This book introduces measurement and statistical sampling for reviews and -defects. It presents techniques that produce quantified results for reducing -defects, improving productivity, tracking projects, and creating -documentation. - -K.E. Wiegers, Peer Reviews in Software: A Practical Guide [23]. - -This book provides clear, succinct explanations of different peer review -methods distinguished by level of formality and effectiveness. Pragmatic -guidance for implementing the methods and how to select which methods are -appropriate for given circumstances is provided. - -N.R. Tague, The Quality Toolbox , 2nd ed., [24]. - -Provides a pragmatic how-to explanation of a comprehensive set of methods, -tools, and techniques for solving quality improvement problems. Includes -the seven basic quality control tools and many others. - -IEEE Std. P730-2013 Draft Standard for Software Quality Assurance Processes -[5]. - -This draft standard expands the SQA processes identified in IEEE/ISO/IEC -12207-2008. P730 establishes standards for initiating, planning, 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, 1979. -[2] W. Humphrey, _Managing the Software Process_ , Addison-Wesley, 1989. -[3*] S.H. Kan, _Metrics and Models in Software Quality Engineering_ , 2nd ed., -Addison- Wesley, 2002. -[4] _ISO/IEC 25010:2011 Systems and Software Engineering—Systems and Software -Quality Requirements and Evaluation (SQuaRE)—Systems and Software Quality -Models_ , ISO/IEC, 2011. -[5] _IEEE P730™/D8 Draft Standard for Software Quality Assurance Processes_ , -IEEE, 2012. -[6*] F. Bott et al., _Professional Issues in Software Engineering_ , 3rd ed., -Taylor & Francis, 2000. -[7*] D. Galin, _Software Quality Assurance: From Theory to Implementation_ , -Pearson Education Limited, 2004. -[8*] S. Naik and P. Tripathy, _Software Testing and Quality Assurance: Theory -and Practice_ , Wiley-Spektrum, 2008. -[9*] P. Clements et al., _Documenting Software Architectures: Views and Beyond_ -, 2nd ed., Pearson Education, 2010. -[10*] G. Voland, _Engineering by Design_ , 2nd ed., Prentice Hall, 2003. -[11] _RTCA DO-178C, Software Considerations in Airborne Systems and Equipment -Certification_ , Radio Technical Commission for Aeronautics, 2011. -[12] _IEEE Std. 15026.1-2011 Trial-Use Standard Adoption of ISO/IEC TR -15026-1:2010 Systems and Software Engineering— Systems and Software -Assurance—Part 1: Concepts and Vocabulary_ , IEEE, 2011. -[13] IEEE Std. 12207-2008 (a.k.a. ISO/IEC 12207:2008) Standard for Systems and -Software Engineering—Software Life Cycle Processes , IEEE, 2008. -[14] ISO 9000:2005 Quality Management Systems—Fundamentals and Vocabulary , -ISO, 2005. -[15] IEEE Std. 1012-2012 Standard for System and Software Verification and -Validation , IEEE, 2012. -[16*] IEEE Std. 1028-2008, Software Reviews and Audits , IEEE, 2008. -[17*] J.W. Moore, The Road Map to Software Engineering: A Standards-Based Guide -, Wiley-IEEE Computer Society Press, 2006. -[18*] K.E. Wiegers, Software Requirements , 2nd ed., Microsoft Press, 2003. -[19] ISO/IEC/IEEE 24765:2010 Systems and Software Engineering—Vocabulary , ISO/ -IEC/IEEE, 2010. -[20] N. Leveson, Safeware: System Safety and Computers , Addison-Wesley -Professional, 1995. -[21] T. Gilb, Principles of Software Engineering Management , Addison-Wesley -Professional, 1988. -[22] T. Gilb and D. Graham, Software Inspection , Addison-Wesley Professional, -1993. -[23] K. Wiegers, Peer Reviews in Software: A Practical Guide , Addison-Wesley -Professional, 2001. -[24] N.R. Tague, The Quality Toolbox , 2nd ed., ASQ Quality Press, 2010. blob - 0140bdbcb735c65f2282f2b68ae6b26d665c3983 (mode 644) blob + /dev/null --- 11_software_engineering.markdown +++ /dev/null @@ -1,1459 +0,0 @@ -``` -11-1 -``` -**CHAPTER 11** - -**SOFTWARE ENGINEERING** - -**PROFESSIONAL PRACTICE** - -##### ACRONYMS - -##### ACM - -``` -Association for Computing -Machinery -BCS British Computer Society -``` -``` -CSDA -Certified Software Development -Associate -``` -``` -CSDP -Certified Software Development -Professional -``` -``` -IEC -International Electrotechnical -Commission -IEEE CS IEEE Computer Society -``` -``` -IFIP -International. Federation for -Information Processing -IP Intellectual Property -``` -``` -ISO -International Organization for -Standardization -N DA Non-Disclosure Agreement -``` -``` -WIPO -World Intellectual Property -Organization -WTO World Trade Organization -``` -##### INTRODUCTION - -The Software Engineering Professional Prac- -tice knowledge area (KA) is concerned with the -knowledge, skills, and attitudes that software -engineers must possess to practice software engi- -neering in a professional, responsible, and ethi- -cal manner. Because of the widespread applica- -tions of software products in social and personal -life, the quality of software products can have -profound impact on our personal well-being -and societal harmony. Software engineers must -handle unique engineering problems, producing - -``` -software with known characteristics and reliabil- -ity. This requirement calls for software engineers -who possess a proper set of knowledge, skills, -training, and experience in professional practice. -The term “professional practice” refers to a -way of conducting services so as to achieve cer- -tain standards or criteria in both the process of -performing a service and the end product result- -ing from the service. These standards and crite- -ria can include both technical and nontechnical -aspects. The concept of professional practice can -be viewed as being more applicable within those -professions that have a generally accepted body -of knowledge; codes of ethics and professional -conduct with penalties for violations; accepted -processes for accreditation, certification, and -licensing; and professional societies to provide -and administer all of these. Admission to these -professional societies is often predicated on a pre- -scribed combination of education and experience. -A software engineer maintains a professional -practice by performing all work in accordance -with generally accepted practices, standards, and -guidelines notably set forth by the applicable pro- -fessional society. For example, the Association for -Computing Machinery (ACM) and IEEE Com- -puter Society (IEEE CS) have established a Soft- -ware Engineering Code of Ethics and Professional -Practice. Both the British Computer Society (BCS) -and the International Federation for Information -Processing (IFIP) have established similar profes- -sional practice standards. ISO/IEC and IEEE have -further provided internationally accepted software -engineering standards (see Appendix B of this -Guide ). IEEE CS has established two international -certification programs (CSDA, CSDP) and a corre- -sponding Guide to the Software Engineering Body -of Knowledge ( SWEBOK Guide ). All of these are -``` - -**11-2** **_SWEBOK® Guide_** **V3.0** - -elements that lay the foundation for of the profes- -sional practice of software engineering. - -**BREAKDOWN OF TOPICS FOR -SOFTWARE ENGINEERING -PROFESSIONAL PRACTICE** - -The Software Engineering Professional Practice -KA’s breakdown of topics is shown in Figure - -``` -11.1. The subareas presented in this KA are pro- -fessionalism, group dynamics and psychology, -and communication skills. -``` -**1. Professionalism** - -``` -A software engineer displays professionalism -notably through adherence to codes of ethics -and professional conduct and to standards and -``` -``` -Figure 11.1. Breakdown of Topics for the Software Engineering Professional Practice KA -``` - -``` -Software Engineering Professional Practice 11-3 -``` -practices that are established by the engineer’s -professional community. -The professional community is often repre- -sented by one or more professional societies; -those societies publish codes of ethics and profes- -sional conduct as well as criteria for admittance -to the community. Those criteria form the basis -for accreditation and licensing activities and may -be used as a measure to determine engineering -competence or negligence. - -_1.1. Accreditation, Certification, and Licensing_ -[1*, c1s4.1, c1s5.1–c1s5.4] - -``` -1.1.1. Accreditation -``` -Accreditation is a process to certify the compe- -tency, authority, or credibility of an organization. -Accredited schools or programs are assured to -adhere to particular standards and maintain cer- -tain qualities. In many countries, the basic means -by which engineers acquire knowledge is through -completion of an accredited course of study. -Often, engineering accreditation is performed by -a government organization, such as the ministry -of education. Such countries with government -accreditations include China, France, Germany, -Israel, Italy, and Russia. -In other countries, however, the accredita- -tion process is independent of government and -performed by private membership associations. -For example, in the United States, engineer- -ing accreditation is performed by an organiza- -tion known as ABET. An organization known as -CSAB serving as a participating body of ABET -is the lead society within ABET for the accredita- -tion of degree programs in software engineering. -While the process of accreditation may be dif- -ferent for each country and jurisdiction, the general -meaning is the same. For an institution’s course of -study to be accredited means that “the accredita- -tion body recognizes an educational institution as -maintaining standards that qualify the graduates -for admission to higher or more specialized insti- -tutions or for professional practice” [2]. - -``` -1.1.2. Certification -``` -Certification refers to the confirmation of a per- -son’s particular characteristics. A common type - -``` -of certification is professional certification, where -a person is certified as being able to complete an -activity in a certain discipline at a stated level -of competency. Professional certification also -can also verify the holder’s ability to meet pro- -fessional standards and to apply professional -judgment in solving or addressing problems. -Professional certification can also involve the -verification of prescribed knowledge, the master- -ing of best practice and proven methodologies, -and the amount of professional experience. -An engineer usually obtains certification by -passing an examination in conjunction with other -experience-based criteria. These examinations -are often administered by nongovernmental orga- -nizations, such as professional societies. -In software engineering, certification testi- -fies to one’s qualification as a software engineer. -For example, the IEEE CS has enacted two cer- -tification programs (CSDA and CSDP) designed -to confirm a software engineer’s knowledge of -standard software engineering practices and to -advance one’s career. A lack of certification does -not exclude the individual from working as a -software engineer. Currently certification in soft- -ware engineering is completely voluntary. In fact, -most software engineers are not certified under -any program. -``` -``` -1.1.3. Licensing -``` -``` -“Licensing” is the action of giving a person the -authorization to perform certain kinds of activi- -ties and take responsibility for resultant engineer- -ing products. The noun “license” refers to both -that authorization and the document recording -that authorization. Governmental authorities or -statutory bodies usually issue licenses. -Obtaining a license to practice requires not only -that an individual meets a certain standard, but -also that they do so with a certain ability to prac- -tice or operate. Sometimes there is an entry-level -requirement which sets the minimum skills and -capabilities to practice, but as the professional -moves through his or her career, the required -skills and capabilities change and evolve. -In general, engineers are licensed as a means of -protecting the public from unqualified individuals. -In some countries, no one can practice as a pro- -fessional engineer unless licensed; or further, no -``` - -**11-4** **_SWEBOK® Guide_** **V3.0** - -company may offer “engineering services” unless -at least one licensed engineer is employed there. - -_1.2. Codes of Ethics and Professional Conduct_ -[1*, c1s6–c1s9] [3*, c8] [4*, c1s2] [5*, c33] -[6*] - -Codes of ethics and professional conduct com- -prise the values and behavior that an engineer’s -professional practice and decisions should -embody. -The professional community establishes codes -of ethics and professional conduct. They exist -in the context of, and are adjusted to agree with, -societal norms and local laws. Therefore, codes -of ethics and professional conduct present guid- -ance in the face of conflicting imperatives. -Once established, codes of ethics and profes- -sional conduct are enforced by the profession, -as represented by professional societies or by a -statutory body. -Violations may be acts of commission, such -as concealing inadequate work, disclosing con- -fidential information, falsifying information, or -misrepresenting one’s abilities. They may also -occur through omission, including failure to dis- -close risks or to provide important information, -failure to give proper credit or to acknowledge -references, and failure to represent client inter- -ests. Violations of codes of ethics and profes- -sional conduct may result in penalties and pos- -sible expulsion from professional status. -A code of ethics and professional conduct for -software engineering was approved by the ACM -Council and the IEEE CS Board of Governors in -1999 [6*]. According to the short version of this -code: - -``` -Software engineers shall commit them- -selves to making the analysis, specifica- -tion, design, development, testing and -maintenance of software a beneficial and -respected profession. In accordance with -their commitment to the health, safety and -welfare of the public, software engineers -shall adhere to the eight principles con- -cerning the public, client and employer, -product, judgment, management, profes- -sion, colleagues, and self, respectively. -``` -``` -Since standards and codes of ethics and pro- -fessional conduct may be introduced, modified, -or replaced at any time, individual software engi- -neers bear the responsibility for their own con- -tinuing study to stay current in their professional -practice. -``` -``` -1.3. Nature and Role of Professional Societies -[1*, c1s1–c1s2] [4*, c1s2] [5*, c35s1] -``` -``` -Professional societies are comprised of a mix -of practitioners and academics. These societies -serve to define, advance, and regulate their cor- -responding professions. Professional societies -help to establish professional standards as well -as codes of ethics and professional conduct. For -this reason, they also engage in related activities, -which include -``` -- establishing and promulgating a body of gen- - erally accepted knowledge; -- accrediting, certifying, and licensing; -- dispensing disciplinary actions; -- advancing the profession through confer- - ences, training, and publications. - -``` -Participation in professional societies assists -the individual engineer in maintaining and sharp- -ening their professional knowledge and relevancy -and in expanding and maintaining their profes- -sional network. -``` -``` -1.4. Nature and Role of Software Engineering -Standards -[1*, c5s3.2, c10s2.1] [5*, c32s6] [7*, c1s2] -``` -``` -Software engineering standards cover a remark- -able variety of topics. They provide guidelines for -the practice of software engineering and processes -to be used during development, maintenance, and -support of software. By establishing a consensual -body of knowledge and experience, software engi- -neering standards establish a basis upon which fur- -ther guidelines may be developed. Appendix B of -this Guide provides guidance on IEEE and ISO/ -IEC software engineering standards that support -the knowledge areas of this Guide. -The benefits of software engineering standards -are many and include improving software quality, -``` - -``` -Software Engineering Professional Practice 11-5 -``` -helping avoid errors, protecting both software -producers and users, increasing professional dis- -cipline, and helping technology transition. - -_1.5. Economic Impact of Software_ -[3*, c10s8] [4*, c1s1.1] [8*, c1] - -Software has economic effects at the individual, -business, and societal levels. Software “success” -may be determined by the suitability of a product -for a recognized problem as well as by its effec- -tiveness when applied to that problem. -At the individual level, an engineer’s continu- -ing employment may depend on their ability -and willingness to interpret and execute tasks -in meeting customers’ or employers’ needs and -expectations. The customer or employer’s finan- -cial situation may in turn be positively or nega- -tively affected by the purchase of software. -At the business level, software properly applied -to a problem can eliminate months of work -and translate to elevated profits or more effec- -tive organizations. Moreover, organizations that -acquire or provide successful software may be a -boon to the society in which they operate by pro- -viding both employment and improved services. -However, the development or acquisition costs of -software can also equate to those of any major -acquisition. -At the societal level, direct impacts of software -success or failure include or exclude accidents, -interruptions, and loss of service. Indirect impacts -include the success or failure of the organization -that acquired or produced the software, increased -or decreased societal productivity, harmonious -or disruptive social order, and even the saving or -loss of property and life. - -_1.6. Employment Contracts_ -[1*, c7] - -Software engineering services may be provided -under a variety of client-engineer relationships. -The software engineering work may be solic- -ited as company-to-customer supplier, engineer- -to-customer consultancy, direct hire, or even -volunteering. In all of these situations, the cus- -tomer and supplier agree that a product or ser- -vice will be provided in return for some sort of - -``` -consideration. Here, we are most concerned with -the engineer-to-customer arrangement and its -attendant agreements or contracts, whether they -are of the direct-hire or consultant variety, and -the issues they typically address. -A common concern in software engineering -contracts is confidentiality. Employers derive -commercial advantage from intellectual property, -so they strive to protect that property from dis- -closure. Therefore, software engineers are often -required to sign non-disclosure (NDA) or intel- -lectual property (IP) agreements as a precondi- -tion to work. These agreements typically apply -to information the software engineer could only -gain through association with the customer. The -terms of these agreements may extend past termi- -nation of the association. -Another concern is IP ownership. Rights to -software engineering assets—products, innova- -tions, inventions, discoveries, and ideas—may -reside with the employer or customer, either under -explicit contract terms or relevant laws, if those -assets are obtained during the term of the soft- -ware engineer’s relationship with that employer -or customer. Contracts differ in the ownership of -assets created using non-employer-owned equip- -ment or information. -Finally, contracts can also specify among -other elements the location at which work is to -be performed; standards to which that work will -be held; the system configuration to be used for -development; limitations of the software engi- -neer’s and employer’s liability; a communication -matrix and/or escalation plan; and administrative -details such as rates, frequency of compensation, -working hours, and working conditions. -``` -``` -1.7. Legal Issues -[1*, c6, c11] [3*, c5s3–c5s4] [9*, c1s10] -``` -``` -Legal issues surrounding software engineering -professional practice notably include matters -related to standards, trademarks, patents, copy- -rights, trade secrets, professional liability, legal -requirements, trade compliance, and cybercrime. -It is therefore beneficial to possess knowledge of -these issues and their applicability. -Legal issues are jurisdictionally based; soft- -ware engineers must consult attorneys who -``` - -**11-6** **_SWEBOK® Guide_** **V3.0** - -specialize in the type and jurisdiction of any iden- -tified legal issues. - -``` -1.7.1. Standards -``` -Software engineering standards establish guide- -lines for generally accepted practices and mini- -mum requirements for products and services pro- -vided by a software engineer. Appendix B of this -_Guide_ provides guidance on software engineer- -ing standards that are applicable to each KA. -Standards are valuable sources of requirements -and assistance during the everyday conduct of -software engineering activities. Adherence to -standards facilitates discipline by enumerating -minimal characteristics of products and practice. -That discipline helps to mitigate subconscious -assumptions or overconfidence in a design. For -these reasons, organizations performing software -engineering activities often include conformance -to standards as part of their organizational poli- -cies. Further, adherence to standards is a major -component of defense from legal action or from -allegations of malpractice. - -``` -1.7.2. Trademarks -``` -A trademark relates to any word, name, symbol, -or device that is used in business transactions. -It is used “to indicate the source or origin of the -goods” [2]. -Trademark protection protects names, logos, -images, and packaging. However, if a name, image, -or other trademarked asset becomes a generic term, -then trademark protection is nullified. -The World Intellectual Property Organization -(WIPO) is the authority that frames the rules and -regulations on trademarks. WIPO is the United -Nations agency dedicated to the use of intellec- -tual property as a means of stimulating innova- -tion and creativity. - -``` -1.7.3. Patents -``` -Patents protect an inventor’s right to manufac- -ture and sell an idea. A patent consists of a set -of exclusive rights granted by a sovereign gov- -ernment to an individual, group of individuals, or -organization for a limited period of time. Patents - -``` -are an old form of idea-ownership protection and -date back to the 15th century. -Application for a patent entails careful records -of the process that led to the invention. Patent -attorneys are helpful in writing patent disclosure -claims in a manner most likely to protect the soft- -ware engineer’s rights. -Note that, if inventions are made during the -course of a software engineering contract, owner- -ship may belong to the employer or customer or -be jointly held, rather than belong to the software -engineer. -There are rules concerning what is and is not -patentable. In many countries, software code is -not patentable, although software algorithms may -be. Existing and filed patent applications can be -searched at WIPO. -``` -``` -1.7.4. Copyrights -``` -``` -Most governments in the world give exclusive -rights of an original work to its creator, usually -for a limited time, enacted as a copyright. Copy- -rights protect the way an idea is presented—not -the idea itself. For example, they may protect the -particular wording of an account of an historical -event, whereas the event itself is not protected. -Copyrights are long-term and renewable; they -date back to the 17th century. -``` -``` -1.7.5. Trade Secrets -``` -``` -In many countries, an intellectual asset such as -a formula, algorithm, process, design, method, -pattern, instrument, or compilation of informa- -tion may be considered a “trade secret,” provided -that these assets are not generally known and may -provide a business some economic advantage. -The designation of “trade secret” provides legal -protection if the asset is stolen. This protection -is not subject to a time limit. However, if another -party derives or discovers the same asset legally, -then the asset is no longer protected and the other -party will also possess all rights to use it. -``` -``` -1.7.6. Professional Liability -``` -``` -It is common for software engineers to be con- -cerned with matters of professional liability. As -``` - -``` -Software Engineering Professional Practice 11-7 -``` -an individual provides services to a client or -employer, it is vital to adhere to standards and -generally accepted practices, thereby protecting -against allegations or proceedings of or related to -malpractice, negligence, or incompetence. -For engineers, including software engineers, -professional liability is related to product liabil- -ity. Under the laws and rules governing in their -jurisdiction, engineers may be held to account -for failing to fully and conscientiously follow -recommended practice; this is known as “negli- -gence.” They may also be subject to laws govern- -ing “strict liability” and either implied or express -warranty, where, by selling the product, the engi- -neer is held to warrant that the product is both -suitable and safe for use. In some countries (for -example, in the US), “privity” (the idea that one -could only sue the person selling the product) is -no longer a defense against liability actions. -Legal suits for liability can be brought under -tort law in the US allowing anyone who is harmed -to recover their loss even if no guarantees were -made. Because it is difficult to measure the suit- -ability or safety of software, failure to take due -care can be used to prove negligence on the part -of software engineers. A defense against such an -allegation is to show that standards and generally -accepted practices were followed in the develop- -ment of the product. - -``` -1.7.7. Legal Requirements -``` -Software engineers must operate within the con- -fines of local, national, and international legal -frameworks. Therefore, software engineers must -be aware of legal requirements for - -- registration and licensing—including exami- - nation, education, experience, and training - requirements; -- contractual agreements; -- noncontractual legalities, such as those gov- - erning liability; -- Basic information on the international legal - framework can be accessed from the World - Trade Organization (WTO). - -``` -1.7.8. Trade Compliance -``` -``` -All software professionals must be aware of -legal restrictions on import, export, or reexport -of goods, services, and technology in the juris- -dictions in which they work. The considerations -include export controls and classification, transfer -of goods, acquisition of necessary governmental -licenses for foreign use of hardware and software, -services and technology by sanctioned nation, -enterprise or individual entities, and import -restrictions and duties. Trade experts should be -consulted for detailed compliance guidance. -``` -``` -1.7.9. Cybercrime -``` -``` -Cybercrime refers to any crime that involves -a computer, computer software, computer net- -works, or embedded software controlling a sys- -tem. The computer or software may have been -used in the commission of a crime or it may have -been the target. This category of crime includes -fraud, unauthorized access, spam, obscene or -offensive content, threats, harassment, theft of -sensitive personal data or trade secrets, and use -of one computer to damage or infiltrate other -networked computers and automated system -controls. -Computer and software users commit fraud by -altering electronic data to facilitate illegal activ- -ity. Forms of unauthorized access include hack- -ing, eavesdropping, and using computer systems -in a way that is concealed from their owners. -Many countries have separate laws to cover -cybercrimes, but it has sometimes been difficult -to prosecute cybercrimes due to a lack of pre- -cisely framed statutes. The software engineer has -a professional obligation to consider the threat of -cybercrime and to understand how the software -system will protect or endanger software and user -information from accidental or malicious access, -use, modification, destruction, or disclosure. -``` -``` -1.8. Documentation -[1*, c10s5.8] [3*, c1s5] [5*, c32] -``` -``` -Providing clear, thorough, and accurate docu- -mentation 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 -the various stakeholder audiences. -Good documentation complies with accepted -standards and guidelines. In particular, software -engineers should document - -- relevant facts, -- significant risks and tradeoffs, and -- warnings of undesirable or dangerous conse- - quences from use or misuse of the software. - -``` -Software engineers should avoid -``` -- certifying or approving unacceptable products, -- disclosing confidential information, or -- falsifying facts or data. - -In addition, software engineers and their man- -agers should notably provide the following docu- -mentation for use by other elements of the soft- -ware development organization: - -- software requirements specifications, soft- - ware design documents, details on the soft- - ware engineering tools used, software test - specifications and results, and details on the - adopted software engineering methods; -- problems encountered during the develop- - ment process. - -For external stakeholders (customer, users, -others) software documentation should notably -provide - -- information needed to determine if the soft- - ware is likely to meet the customer’s and - users’ needs, -- description of the safe, and unsafe, use of the - software, -- description of the protection of sensitive - information created by or stored using the - software, and -- clear identification of warnings and critical - procedures. - -Use of software may include installation, oper- -ation, administration, and performance of other -functions by various groups of users and support -personnel. If the customer will acquire ownership - -``` -of the software source code or the right to modify -the code, the software engineer should provide -documentation of the functional specifications, -the software design, the test suite, and the neces- -sary operating environment for the software. -The minimum length of time documents should -be kept is the duration of the software products’ -life cycle or the time required by relevant organi- -zational or regulatory requirements. -``` -``` -1.9. Tradeoff Analysis -[3*, c1s2, c10] [9*, c9s5.10] -``` -``` -Within the practice of software engineering, a -software engineer often has to choose between -alternative problem solutions. The outcome of -these choices is determined by the software engi- -neer’s professional evaluation of the risks, costs, -and benefits of alternatives, in cooperation with -stakeholders. The software engineer’s evaluation -is called “tradeoff analysis.” Tradeoff analysis -notably enables the identification of compet- -ing and complementary software requirements -in order to prioritize the final set of require- -ments defining the software to be constructed -(see Requirements Negotiation in the Software -Requirements KA and Determination and Nego- -tiation of Requirements in the Software Engi- -neering Management KA). -In the case of an ongoing software develop- -ment project that is late or over budget, tradeoff -analysis is often conducted to decide which soft- -ware requirements can be relaxed or dropped -given the effects thereof. -A first step in a tradeoff analysis is establish- -ing design goals (see Engineering Design in the -Engineering Foundations KA) and setting the -relative importance of those goals. This permits -identification of the solution that most nearly -meets those goals; this means that the way the -goals are stated is critically important. -Design goals may include minimization of -monetary cost and maximization of reliability, -performance, or some other criteria on a wide -range of dimensions. However, it is difficult to -formulate a tradeoff analysis of cost against risk, -especially where primary production and second- -ary risk-based costs must be traded against each -other. -``` - -``` -Software Engineering Professional Practice 11-9 -``` -A software engineer must conduct a tradeoff -analysis in an ethical manner—notably by being -objective and impartial when selecting criteria for -comparison of alternative problem solutions and -when assigning weights or importance to these -criteria. Any conflict of interest must be disclosed -up front. - -**2. Group Dynamics and Psychology** - -Engineering work is very often conducted in the -context of teamwork. A software engineer must -be able to interact cooperatively and construc- -tively with others to first determine and then -meet both needs and expectations. Knowledge of -group dynamics and psychology is an asset when -interacting with customers, coworkers, suppliers, -and subordinates to solve software engineering -problems. - -_2.1. Dynamics of Working in Teams/Groups_ -[3*, c1s6] [9*, c1s3.5, c10] - -Software engineers must work with others. On -one hand, they work internally in engineering -teams; on the other hand, they work with cus- -tomers, members of the public, regulators, and -other stakeholders. Performing teams—those -that demonstrate consistent quality of work and -progress toward goals—are cohesive and possess -a cooperative, honest, and focused atmosphere. -Individual and team goals are aligned so that the -members naturally commit to and feel ownership -of shared outcomes. -Team members facilitate this atmosphere by -being intellectually honest, making use of group -thinking, admitting ignorance, and acknowledg- -ing mistakes. They share responsibility, rewards, -and workload fairly. They take care to communi- -cate clearly, directly to each other and in docu- -ments, as well as in source code, so that informa- -tion is accessible to everyone. Peer reviews about -work products are framed in a constructive and -nonpersonal way (see Reviews and Audits in the -Software Quality KA). This allows all the mem- -bers to pursue a cycle of continuous improvement -and growth without personal risk. In general, -members of cohesive teams demonstrate respect -for each other and their leader. - -``` -One point to emphasize is that software engi- -neers must be able to work in multidisciplinary -environments and in varied application domains. -Since today software is everywhere, from a phone -to a car, software is impacting people’s lives far -beyond the more traditional concept of software -made for information management in a business -environment. -``` -``` -2.2. Individual Cognition -[3*, c1s6.5] [5*, c33] -``` -``` -Engineers desire to solve problems. The ability to -solve problems effectively and efficiently is what -every engineer strives for. However, the limits -and processes of individual cognition affect prob- -lem solving. In software engineering, notably due -to the highly abstract nature of software itself, -individual cognition plays a very prominent role -in problem solving. -In general, an individual’s (in particular, a software -engineer’s) ability to decompose a problem and cre- -atively develop a solution can be inhibited by -``` -- need for more knowledge, -- subconscious assumptions, -- volume of data, -- fear of failure or consequence of failure, -- culture, either application domain or - organizational, -- lack of ability to express the problem, -- perceived working atmosphere, and -- emotional status of the individual. - -``` -The impact of these inhibiting factors can be -reduced by cultivating good problem solving -habits that minimize the impact of misleading -assumptions. The ability to focus is vital, as is -intellectual humility: both allow a software engi- -neer to suspend personal considerations and con- -sult with others freely, which is especially impor- -tant when working in teams. -There is a set of basic methods engineers use -to facilitate problem solving (see Problem Solv- -ing Techniques in the Computing Foundations -KA). Breaking down problems and solving them -one piece at a time reduces cognitive overload. -Taking advantage of professional curiosity and -pursuing continuous professional development -``` - -**11-10** **_SWEBOK® Guide_** **V3.0** - -through training and study add skills and knowl- -edge to the software engineer’s portfolio; reading, -networking, and experimenting with new tools, -techniques, and methods are all valid means of -professional development. - -_2.3. Dealing with Problem Complexity_ -[3*, c3s2] [5*, c33] - -Many, if not most, software engineering prob- -lems are too complex and difficult to address as -a whole or to be tackled by individual software -engineers. When such circumstances arise, the -usual means to adopt is teamwork and problem -decomposition (see Problem Solving Techniques -in the Computing Foundations KA). -Teams work together to deal with complex and -large problems by sharing burdens and draw- -ing upon each other’s knowledge and creativity. -When software engineers work in teams, differ- -ent views and abilities of the individual engineers -complement each other and help build a solution -that is otherwise difficult to come by. Some spe- -cific teamwork examples to software engineering -are pair programming (see Agile Methods in the -Software Engineering Models and Methods KA) -and code review (see Reviews and Audits in the -Software Quality KA). - -_2.4. Interacting with Stakeholders_ -[9*, c2s3.1] - -Success of a software engineering endeavor -depends upon positive interactions with stake- -holders. They should provide support, informa- -tion, and feedback at all stages of the software -life cycle process. For example, during the early -stages, it is critical to identify all stakeholders and -discover how the product will affect them, so that -sufficient definition of the stakeholder require- -ments can be properly and completely captured. -During development, stakeholders may pro- -vide feedback on specifications and/or early -versions of the software, change of priority, as -well as clarification of detailed or new software -requirements. Last, during software maintenance -and until the end of product life, stakeholders pro- -vide feedback on evolving or new requirements -as well problem reports so that the software may -be extended and improved. - -``` -Therefore, it is vital to maintain open and pro- -ductive communication with stakeholders for the -duration of the software product’s lifetime. -``` -``` -2.5. Dealing with Uncertainty and Ambiguity -[4*, c24s4, c26s2] [9*, c9s4] -``` -``` -As with engineers of other fields, software engi- -neers must often deal with and resolve uncer- -tainty and ambiguities while providing services -and developing products. The software engineer -must attack and reduce or eliminate any lack of -clarity that is an obstacle to performing work. -Often, uncertainty is simply a reflection of lack -of knowledge. In this case, investigation through -recourse to formal sources such as textbooks and -professional journals, interviews with stakehold- -ers, or consultation with teammates and peers can -overcome it. -When uncertainty or ambiguity cannot be over- -come easily, software engineers or organizations -may choose to regard it as a project risk. In this -case, work estimates or pricing are adjusted to -mitigate the anticipated cost of addressing it (see -Risk Management in the Software Engineering -Management KA). -``` -``` -2.6. Dealing with Multicultural Environments -[9*, c10s7] -``` -``` -Multicultural environments can have an impact -on the dynamics of a group. This is especially -true when the group is geographically separated -or communication is infrequent, since such sepa- -ration elevates the importance of each contact. -Intercultural communication is even more dif- -ficult if the difference in time zones make oral -communication less frequent. -Multicultural environments are quite prevalent -in software engineering, perhaps more than in -other fields of engineering, due to the strong trend -of international outsourcing and the easy shipment -of software components instantaneously across -the globe. For example, it is rather common for a -software project to be divided into pieces across -national and cultural borders, and it is also quite -common for a software project team to consist of -people from diverse cultural backgrounds. -For a software project to be a success, team -members must achieve a level of tolerance, -``` - -``` -Software Engineering Professional Practice 11-11 -``` -acknowledging that some rules depend on soci- -etal norms and that not all societies derive the -same solutions and expectations. -This tolerance and accompanying understand- -ing can be facilitated by the support of leadership -and management. More frequent communication, -including face-to-face meetings, can help to miti- -gate geographical and cultural divisions, promote -cohesiveness, and raise productivity. Also, being -able to communicate with teammates in their -native language could be very beneficial. - -**3. Communication Skills** - -It is vital that a software engineer communicate -well, both orally and in reading and writing. Suc- -cessful attainment of software requirements and -deadlines depends on developing clear under- -standing between the software engineer and -customers, supervisors, coworkers, and suppli- -ers. Optimal problem solving is made possible -through the ability to investigate, comprehend, -and summarize information. Customer product -acceptance and safe product usage depend on the -provision of relevant training and documentation. -It follows that the software engineer’s own career -success is affected by the ability to consistently -provide oral and written communication effec- -tively and on time. - -_3.1. Reading, Understanding, and Summarizing_ -[5*, c33s3] - -Software engineers are able to read and under- -stand technical material. Technical material -includes reference books, manuals, research -papers, and program source code. -Reading is not only a primary way of improv- -ing skills, but also a way of gathering informa- -tion necessary for the completion of engineering -goals. A software engineer sifts through accu- -mulated information, filtering out the pieces that -will be most helpful. Customers may request that -a software engineer summarize the results of -such information gathering for them, simplifying -or explaining it so that they may make the final -choice between competing solutions. -Reading and comprehending source code is -also a component of information gathering and -problem solving. When modifying, extending, - -``` -or rewriting software, it is critical to understand -both its implementation directly derived from the -presented code and its design, which must often -be inferred. -``` -``` -3.2. Writing -[3*, c1s5] -``` -``` -Software engineers are able to produce written -products as required by customer requests or gen- -erally accepted practice. These written products -may include source code, software project plans, -software requirement documents, risk analyses, -software design documents, software test plans, -user manuals, technical reports and evaluations, -justifications, diagrams and charts, and so forth. -Writing clearly and concisely is very important -because often it is the primary method of com- -munication among relevant parties. In all cases, -written software engineering products must be -written so that they are accessible, understand- -able and relevant for their intended audience(s). -``` -``` -3.3. Team and Group Communication -[3*, c1s6.8] [4*, c22s3] [5*, c27s1] -[9*, c10s4] -``` -``` -Effective communication among team and group -members is essential to a collaborative software -engineering effort. Stakeholders must be con- -sulted, decisions must be made, and plans must -be generated. The greater the number of team -and group members, the greater the need to -communicate. -The number of communication paths, how- -ever, grows quadratically with the addition of -each team member. Further, team members -are unlikely to communicate with anyone per- -ceived to be removed from them by more than -two degrees (levels). This problem can be more -serious when software engineering endeavors or -organizations are spread across national and con- -tinental borders. -Some communication can be accomplished in -writing. Software documentation is a common -substitute for direct interaction. Email is another -but, although it is useful, it is not always enough; -also, if one sends too many messages, it becomes -difficult to identify the important information. -Increasingly, organizations are using enterprise -``` - -**11-12** **_SWEBOK® Guide_** **V3.0** - -collaboration tools to share information. In addi- -tion, the use of electronic information stores, -accessible to all team members, for organiza- -tional policies, standards, common engineering -procedures, and project-specific information, can -be most beneficial. -Some software engineering teams focus on -face-to-face interaction and promote such inter- -action by office space arrangement. Although -private offices improve individual productivity, -colocating team members in physical or virtual -forms and providing communal work areas is -important to collaborative efforts. - -_3.4. Presentation Skills_ -[3*, c1s5] [4*, c22] [9*, c10s7–c10s8] - -Software engineers rely on their presentation -skills during software life cycle processes. For -example, during the software requirements - -``` -phase, software engineers may walk customers -and teammates through software requirements -and conduct formal requirements reviews (see -Requirement Reviews in the Software Require- -ments KA). During and after software design, -software construction, and software maintenance, -software engineers lead reviews, product walk- -throughs (see Review and Audits in the Software -Quality KA), and training. All of these require the -ability to present technical information to groups -and solicit ideas or feedback. -The software engineer’s ability to convey -concepts effectively in a presentation therefore -influences product acceptance, management, -and customer support; it also influences the abil- -ity of stakeholders to comprehend and assist in -the product effort. This knowledge needs to be -archived in the form of slides, knowledge write- -up, technical whitepapers, and any other material -utilized for knowledge creation. -``` - -``` -Software Engineering Professional Practice 11-13 -``` -##### MATRIX OF TOPICS VS. REFERENCE MATERIAL - -``` -Bott et al. 2000 -``` -##### [1*] - -``` -Voland 2003 -``` -##### [3*] - -``` -Sommerville 2011 -``` -##### [4*] - -``` -McConnell 2004 -``` -##### [5*] - -##### IEEE-CS/ACM 1999 - -##### [6*] - -``` -Moore 2006 -``` -##### [7*] - -``` -Tockey 2004 -``` -##### [8*] - -``` -Fairley 2009 -``` -##### [9*] - -**1. Professionalism** - 1.1. Accreditation, - Certification, and - Licensing - -``` -c1s4.1, -c1s5.1– -c1s5.4 -1.2. Codes of Ethics -and Professional -Conduct -``` -``` -c1s6– -c1s9 -c8 c1s2 c33 * -``` -``` -1.3. Nature and -Role of Professional -Societies -``` -``` -c1s1– -c1s2 -c1s2 c35s1 -``` -``` -1.4. Nature and -Role of Software -Engineering -Standards -``` -``` -c5s3.2, -c10 s2.1 -c32s6 c1s2 -``` -``` -1.5. Economic -Impact of Software -c10 s8 c1s1.1 c1 -``` -``` -1.6. Employment -Contracts -c7 -``` -``` -1.7. Legal Issues c6, c11 -c5s3– -c5s4 -c1s10 -``` -``` -1.8. Documentation c10s5.8 c1s5 c32 -1.9. Tradeoff -Analysis -``` -``` -c1s2, -c10 -c9s5.10 -``` -**2. Group Dynamics -and Psychology** - 2.1. Dynamics of - Working in Teams/ - Groups - -``` -c1s6 -c1s3.5, -c10 -``` -``` -2.2. Individual -Cognition -c1s6.5 c33 -``` -``` -2.3. 2.3 Dealing with -Problem Complexity -c3s2 c33 -``` -``` -2.4. Interacting with -Stakeholders -c2s3.1 -``` - -**11-14** **_SWEBOK® Guide_** **V3.0** - -``` -Bott et al. 2000 -``` -##### [1*] - -``` -Voland 2003 -``` -##### [3*] - -``` -Sommerville 2011 -``` -##### [4*] - -``` -McConnell 2004 -``` -##### [5*] - -##### IEEE-CS/ACM 1999 - -##### [6*] - -``` -Moore 2006 -``` -##### [7*] - -``` -Tockey 2004 -``` -##### [8*] - -``` -Fairley 2009 -``` -##### [9*] - -``` -2.5. Dealing with -Uncertainty and -Ambiguity -``` -``` -c24s4, -c26s2 -c9s4 -``` -``` -2.6. Dealing with -Multicultural -Environments -``` -``` -c10s7 -``` -**3. Communication -Skills** - 3.1. Reading, - Understanding, and - Summarizing - -``` -c33s3 -``` -``` -3.2. Writing c1s5 -3.3. Team and Group -Communication -c1s6.8 c22s3 c27s1 c10s4 -``` -``` -3.4. Presentation -Skills -c1s5 c22 -c10s7– -c10 s8 -``` - -``` -Software Engineering Professional Practice 11-15 -``` -##### FURTHER READINGS - -Gerald M. Weinberg, _The Psychology of -Computer Programming_ [10]. - -This was the first major book to address program- -ming as an individual and team effort and became -a classic in the field. - -Kinney and Lange, P.A., _Intellectual Property -Law for Business Lawyers_ [11]. - -This book covers IP laws in the US. It not only -talks about what the IP law is; it also explains -why it looks the way it does. - -##### REFERENCES - -``` -[1*] F. Bott et al., Professional Issues in -Software Engineering , 3rd ed., Taylor & -Francis, 2000. -``` -``` -[2] Merriam-Webster’s Collegiate Dictionary , -11th ed., 2003. -``` -``` -[3*] G. Voland, Engineering by Design , 2nd ed., -Prentice Hall, 2003. -``` -``` -[4*] I. Sommerville, Software Engineering , 9th -ed., Addison-Wesley, 2011. -``` -``` -[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; -http://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. -``` blob - 7079e6f7a4b3bb22f1296147c941c9563ada53d4 (mode 644) blob + /dev/null --- 12_software_engineering_economics.markdown +++ /dev/null @@ -1,1515 +0,0 @@ -``` -12-1 -``` -**CHAPTER 12** - -**SOFTWARE ENGINEERING ECONOMICS** - -##### ACRONYMS - -``` -EVM Earned Value Management -IRR Internal Rate of Return -``` -``` -MARR -Minimum Acceptable Rate of -Return -SDLC Software Development Life Cycle -SPLC Software Product Life Cycle -ROI Return on Investment -ROCE Return on Capital Employed -TCO Total Cost of Ownership -``` -##### INTRODUCTION - -Software engineering economics is about mak- -ing decisions related to software engineering in a -business context. The success of a software prod- -uct, service, and solution depends on good busi- -ness management. Yet, in many companies and -organizations, software business relationships to -software development and engineering remain -vague. This knowledge area (KA) provides an -overview on software engineering economics. -Economics is the study of value, costs, -resources, and their relationship in a given context -or situation. In the discipline of software engi- -neering, activities have costs, but the resulting -software itself has economic attributes as well. -Software engineering economics provides a way -to study the attributes of software and software -processes in a systematic way that relates them -to economic measures. These economic measures -can be weighed and analyzed when making deci- -sions that are within the scope of a software orga- -nization and those within the integrated scope of -an entire producing or acquiring business. -Software engineering economics is concerned -with aligning software technical decisions with - -``` -the business goals of the organization. In all -types of organizations—be it “for-profit,” “not- -for-profit,” or governmental—this translates into -sustainably staying in business. In “for-profit” -organizations this additionally relates to achiev- -ing a tangible return on the invested capital— -both assets and capital employed. This KA has -been formulated in a way to address all types of -organizations independent of focus, product and -service portfolio, or capital ownership and taxa- -tion restrictions. -Decisions like “Should we use a specific compo- -nent?” may look easy from a technical perspective, -but can have serious implications on the business -viability of a software project and the resulting -product. Often engineers wonder whether such -concerns apply at all, as they are “only engi- -neers.” Economic analysis and decision-making -are important engineering considerations because -engineers are capable of evaluating decisions both -technically and from a business perspective. The -contents of this knowledge area are important top- -ics for software engineers to be aware of even if -they are never actually involved in concrete busi- -ness decisions; they will have a well-rounded view -of business issues and the role technical consid- -erations play in making business decisions. Many -engineering proposals and decisions, such as make -versus buy, have deep intrinsic economic impacts -that should be considered explicitly. -This KA first covers the foundations, key ter- -minology, basic concepts, and common practices -of software engineering economics to indicate -how decision-making in software engineering -includes, or should include a business perspec- -tive. It then provides a life cycle perspective, -highlights risk and uncertainty management, and -shows how economic analysis methods are used. -Some practical considerations finalize the knowl- -edge area. -``` - -**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 - -##### SOFTWARE ENGINEERING ECONOMICS - -The breakdown of topics for the Software Engi- -neering Economics KA is shown in Figure 12.1. - -**1. Software Engineering Economics -Fundamentals** - -_1.1. Finance_ -[1*, c2] - -Finance is the branch of economics concerned -with issues such as allocation, management, -acquisition, and investment of resources. Finance -is an element of every organization, including -software engineering organizations. -The field of finance deals with the concepts of -time, money, risk, and how they are interrelated. -It also deals with how money is spent and bud- -geted. Corporate finance is concerned with pro- -viding the funds for an organization’s activities. -Generally, this involves balancing risk and profit- -ability, while attempting to maximize an organi- -zation’s wealth and the value of its stock. This -holds primarily for “for-profit” organizations, -but also applies to “not-for-profit” organizations. -The latter needs finances to ensure sustainability, -while not targeting tangible profit. To do this, an -organization must - -- identify organizational goals, time horizons, - risk factors, tax considerations, and financial - constraints; -- identify and implement the appropriate busi- - ness strategy, such as which portfolio and - investment decisions to take, how to manage - cash flow, and where to get the funding; -- measure financial performance, such as - cash flow and ROI (see section 4.3, Return - on Investment), and take corrective actions - in case of deviation from objectives and - strategy. - -_1.2. Accounting_ -[1*, c15] - -Accounting is part of finance. It allows people -whose money is being used to run an organization - -``` -to know the results of their investment: did they -get the profit they were expecting? In “for-profit” -organizations, this relates to the tangible ROI -(see section 4.3, Return on Investment), while in -“not-for-profit” and governmental organizations -as well as “for-profit” organizations, it translates -into sustainably staying in business. The primary -role of accounting is to measure the organiza- -tion’s actual financial performance and to com- -municate financial information about a business -entity to stakeholders, such as shareholders, -financial auditors, and investors. Communication -is generally in the form of financial statements -that show in money terms the economic resources -to be controlled. It is important to select the right -information that is both relevant and reliable to -the user. Information and its timing are partially -governed by risk management and governance -policies. Accounting systems are also a rich -source of historical data for estimating. -``` -``` -1.3. Controlling -[1*, c15] -``` -``` -Controlling is an element of finance and account- -ing. Controlling involves measuring and correct- -ing the performance of finance and accounting. -It ensures that an organization’s objectives and -plans are accomplished. Controlling cost is a spe- -cialized branch of controlling used to detect vari- -ances of actual costs from planned costs. -``` -``` -1.4. Cash Flow -[1*, c3] -``` -``` -Cash flow is the movement of money into or out -of a business, project, or financial product over a -given period. The concepts of cash flow instances -and cash flow streams are used to describe the -business perspective of a proposal. To make a -meaningful business decision about any specific -proposal, that proposal will need to be evaluated -from a business perspective. In a proposal to -develop and launch product X, the payment for -new software licenses is an example of an outgo- -ing cash flow instance. Money would need to be -spent to carry out that proposal. The sales income -from product X in the 11th month after market -launch is an example of an incoming cash flow -``` - -**12-4** **_SWEBOK® Guide_** **V3.0** - -instance. Money would be coming in because of -carrying out the proposal. -The term _cash flow stream_ refers to the set of -cash flow instances over time that are caused by -carrying out some given proposal. The cash flow -stream is, in effect, the complete financial picture -of that proposal. How much money goes out? -When does it go out? How much money comes -in? When does it come in? Simply, if the cash -flow stream for Proposal A is more desirable than -the cash flow stream for Proposal B, then—all -other things being equal—the organization is bet- -ter off carrying out Proposal A than Proposal B. -Thus, the cash flow stream is an important input -for investment decision-making. A cash flow -instance is a specific amount of money flowing -into or out of the organization at a specific time -as a direct result of some activity. -A cash flow diagram is a picture of a cash flow -stream. It gives the reader a quick overview of -the financial picture of the subject organization or -project. Figure 12.2 shows an example of a cash -flow diagram for a proposal. - -_1.5. Decision-Making Process_ -[1*, c2, c4] - -If we assume that candidate solutions solve a -given technical problem equally well, why should -the organization care which one is chosen? The -answer is that there is usually a large differ- -ence in the costs and incomes from the different - -``` -solutions. A commercial, off-the-shelf, object- -request broker product might cost a few thousand -dollars, but the effort to develop a homegrown -service that gives the same functionality could -easily cost several hundred times that amount. -If the candidate solutions all adequately solve -the problem from a technical perspective, then -the selection of the most appropriate alternative -should be based on commercial factors such as -optimizing total cost of ownership (TCO) or -maximizing the short-term return on investment -(ROI). Life cycle costs such as defect correction, -field service, and support duration are also rel- -evant considerations. These costs need to be fac- -tored in when selecting among acceptable tech- -nical approaches, as they are part of the lifetime -ROI (see section 4.3, Return on Investment). -A systematic process for making decisions will -achieve transparency and allow later justifica- -tion. Governance criteria in many organizations -demand selection from at least two alternatives. -A systematic process is shown in Figure 12.3. -It starts with a business challenge at hand and -describes the steps to identify alternative solu- -tions, define selection criteria, evaluate the solu- -tions, implement one selected solution, and moni- -tor the performance of that solution. -Figure 12.3 shows the process as mostly step- -wise and serial. The real process is more fluid. -Sometimes the steps can be done in a different -order and often several of the steps can be done -in parallel. The important thing is to be sure that -``` -``` -Figure 12.2. A Cash Flow Diagram -``` - -``` -Software Engineering Economics 12-5 -``` -none of the steps are skipped or curtailed. It’s also -important to understand that this same process -applies at all levels of decision making: from a -decision as big as determining whether a software -project should be done at all, to a deciding on an -algorithm or data structure to use in a software -module. The difference is how financially sig- -nificant the decision is and, therefore, how much -effort should be invested in making that deci- -sion. The project-level decision is financially sig- -nificant and probably warrants a relatively high -level of effort to make the decision. Selecting an -algorithm is often much less financially signifi- -cant and warrants a much lower level of effort to -make the decision, even though the same basic -decision-making process is being used. -More often than not, an organization could -carry out more than one proposal if it wanted -to, and usually there are important relationships -among proposals. Maybe Proposal Y can only be -carried out if Proposal X is also carried out. Or -maybe Proposal P cannot be carried out if Pro- -posal Q is carried out, nor could Q be carried out -if P were. Choices are much easier to make when -there are mutually exclusive paths—for example, -either A or B or C or whatever is chosen. In pre- -paring decisions, it is recommended to turn any -given set of proposals, along with their various -interrelationships, into a set of mutually exclu- -sive alternatives. The choice can then be made -among these alternatives. - -``` -1.6. Valuation -[1*, c5, c8] -``` -``` -In an abstract sense, the decision-making pro- -cess—be it financial decision making or other— -is about maximizing value. The alternative that -maximizes total value should always be chosen. -A financial basis for value-based comparison is -comparing two or more cash flows. Several bases -of comparison are available, including -``` -- present worth -- future worth -- annual equivalent -- internal rate of return -- (discounted) payback period. - -``` -Based on the time-value of money, two or more -cash flows are equivalent only when they equal -the same amount of money at a common point -in time. Comparing cash flows only makes sense -when they are expressed in the same time frame. -Note that value can’t always be expressed in -terms of money. For example, whether an item -is a brand name or not can significantly affect -its perceived value. Relevant values that can’t -be expressed in terms of money still need to be -expressed in similar terms so that they can be -evaluated objectively. -``` -``` -Figure 12.3. The Basic Business Decision-Making Process -``` - -**12-6** **_SWEBOK® Guide_** **V3.0** - -_1.7. Inflation_ -[1*, c13] - -Inflation describes long-term trends in prices. -Inflation means that the same things cost more -than they did before. If the planning horizon of -a business decision is longer than a few years, or -if the inflation rate is over a couple of percentage -points annually, it can cause noticeable changes -in the value of a proposal. The present time value -therefore needs to be adjusted for inflation rates -and also for exchange rate fluctuations. - -_1.8. Depreciation_ -[1*, c14] - -Depreciation involves spreading the cost of a -tangible asset across a number of time periods; -it is used to determine how investments in capi- -talized assets are charged against income over -several years. Depreciation is an important part -of determining after-tax cash flow, which is criti- -cal for accurately addressing profit and taxes. If -a software product is to be sold after the devel- -opment costs are incurred, those costs should be -capitalized and depreciated over subsequent time -periods. The depreciation expense for each time -period is the capitalized cost of developing the -software divided across the number of periods -in which the software will be sold. A software -project proposal may be compared to other soft- -ware and nonsoftware proposals or to alternative -investment options, so it is important to deter- -mine how those other proposals would be depre- -ciated and how profits would be estimated. - -_1.9. Taxation_ -[1*, c16, c17] - -Governments charge taxes in order to finance -expenses that society needs but that no single orga- -nization would invest in. Companies have to pay -income taxes, which can take a substantial portion -of a corporation’s gross profit. A decision analysis -that does not account for taxation can lead to the -wrong choice. A proposal with a high pretax profit -won’t look nearly as profitable in posttax terms. -Not accounting for taxation can also lead to unre- -alistically high expectations about how profitable a -proposed product might be. - -``` -1.10. Time-Value of Money -[1*, c5, c11] -``` -``` -One of the most fundamental concepts in -finance—and therefore, in business decisions— -is that money has time-value: its value changes -over time. A specific amount of money right now -almost always has a different value than the same -amount of money at some other time. This con- -cept has been around since the earliest recorded -human history and is commonly known as time- -value. In order to compare proposals or portfo- -lio elements, they should be normalized in cost, -value, and risk to the net present value. Currency -exchange variations over time need to be taken -into account based on historical data. This is par- -ticularly important in cross-border developments -of all kinds. -``` -``` -1.11. Efficiency -[2*, c1] -``` -``` -Economic efficiency of a process, activity, or -task is the ratio of resources actually consumed to -resources expected to be consumed or desired to -be consumed in accomplishing the process, activ- -ity, or task. Efficiency means “doing things right.” -An efficient behavior, like an effective behavior, -delivers results—but keeps the necessary effort to -a minimum. Factors that may affect efficiency in -software engineering include product complex- -ity, quality requirements, time pressure, process -capability, team distribution, interrupts, feature -churn, tools, and programming language. -``` -``` -1.12. Effectiveness -[2*, c1] -``` -``` -Effectiveness is about having impact. It is the -relationship between achieved objectives to -defined objectives. Effectiveness means “doing -the right things.” Effectiveness looks only at -whether defined objectives are reached—not at -how they are reached. -``` -``` -1.13. Productivity -[2*, c23] -``` -``` -Productivity is the ratio of output over input from -an economic perspective. Output is the value -``` - -``` -Software Engineering Economics 12-7 -``` -delivered. Input covers all resources (e.g., effort) -spent to generate the output. Productivity com- -bines efficiency and effectiveness from a value- -oriented perspective: maximizing productivity -is about generating highest value with lowest -resource consumption. - -**2. Life Cycle Economics** - -_2.1. Product_ -[2*, c22] [3*, c6] - -A product is an economic good (or output) that is -created in a process that transforms product fac- -tors (or inputs) to an output. When sold, a prod- -uct is a deliverable that creates both a value and -an experience for its users. A product can be a -combination of systems, solutions, materials, -and services delivered internally (e.g., in-house -IT solution) or externally (e.g., software applica- -tion), either as-is or as a component for another -product (e.g., embedded software). - -_2.2. Project_ -[2*, c22] [3*, c1] - -A project is “a temporary endeavor undertaken -to create a unique product, service, or result”.^1 -In software engineering, different project types -are distinguished (e.g., product development, -outsourced services, software maintenance, ser- -vice creation, and so on). During its life cycle, a -software product may require many projects. For -example, during the product conception phase, -a project might be conducted to determine the -customer need and market requirements; during -maintenance, a project might be conducted to -produce a next version of a product. - -_2.3. Program_ - -A program is “a group of related projects, sub- -programs, and program activities managed in a -coordinated way to obtain benefits not available - -1 Project Management Institute, Inc., _PMI Lexicon -of Project Management Terms,_ 2012, [http://www.pmi.org/](http://www.pmi.org/) -PMBOK-Guide-and-Standards/~/media/Registered/ -PMI_Lexicon_Final.ashx. - -``` -from managing them individually.”^2 Programs -are often used to identify and manage different -deliveries to a single customer or market over a -time horizon of several years. -``` -``` -2.4. Portfolio -``` -``` -Portfolios are “projects, programs, subportfolios, -and operations managed as a group to achieve -strategic objectives.”^3 Portfolios are used to group -and then manage simultaneously all assets within -a business line or organization. Looking to an -entire portfolio makes sure that impacts of deci- -sions are considered, such as resource allocation -to a specific project—which means that the same -resources are not available for other projects. -``` -``` -2.5. Product Life Cycle -[2*, c2] [3*, c2] -``` -``` -A software product life cycle (SPLC) includes -all activities needed to define, build, operate, -maintain, and retire a software product or service -and its variants. The SPLC activities of “oper- -ate,” “maintain,” and “retire” typically occur in -a much longer time frame than initial software -development (the software development life -cycle—SDLC—see Software Life Cycle Mod- -els in the Software Engineering Process KA). -Also the operate-maintain-retire activities of an -SPLC typically consume more total effort and -other resources than the SDLC activities (see -Majority of Maintenance Costs in the Software -Maintenance KA). The value contributed by a -software product or associated services can be -objectively determined during the “operate and -maintain” time frame. Software engineering eco- -nomics should be concerned with all SPLC activ- -ities, including the activities after initial product -release. -``` -``` -2.6. Project Life Cycle -[2*, c2] [3*, c2] -``` -``` -Project life cycle activities typically involve five -process groups—Initiating, Planning, Execut- -ing, Monitoring and Controlling, and Closing [4] -``` -``` -2 Ibid. -3 Ibid. -``` - -**12-8** **_SWEBOK® Guide_** **V3.0** - -(see the Software Engineering Management KA). -The activities within a software project life cycle -are often interleaved, overlapped, and iterated -in various ways [3*, c2] [5] (see the Software -Engineering Process KA). For instance, agile -product development within an SPLC involves -multiple iterations that produce increments of -deliverable software. An SPLC should include -risk management and synchronization with dif- -ferent suppliers (if any), while providing audit- -able decision-making information (e.g., comply- -ing with product liability needs or governance -regulations). The software project life cycle and -the software product life cycle are interrelated; an -SPLC may include several SDLCs. - -_2.7. Proposals_ -[1*, c3] - -Making a business decision begins with the -notion of a _proposal_. Proposals relate to reaching -a business objective—at the project, product, or -portfolio level. A proposal is a single, separate -option that is being considered, like carrying out -a particular software development project or not. -Another proposal could be to enhance an exist- -ing software component, and still another might -be to redevelop that same software from scratch. -Each proposal represents a unit of choice—either -you can choose to carry out that proposal or you -can choose not to. The whole purpose of business -decision-making is to figure out, given the current -business circumstances, which proposals should -be carried out and which shouldn’t. - -_2.8. Investment Decisions_ -[1*, c4] - -Investors make investment decisions to spend -money and resources on achieving a target objec- -tive. Investors are either inside (e.g., finance, -board) or outside (e.g., banks) the organization. -The target relates to some economic criteria, such -as achieving a high return on the investment, -strengthening the capabilities of the organization, -or improving the value of the company. Intangi- -ble aspects such as goodwill, culture, and compe- -tences should be considered. - -``` -2.9. Planning Horizon -[1*, c11] -``` -``` -When an organization chooses to invest in a par- -ticular proposal, money gets tied up in that pro- -posal—so-called “frozen assets.” The economic -impact of frozen assets tends to start high and -decreases over time. On the other hand, operat- -ing and maintenance costs of elements associated -with the proposal tend to start low but increase -over time. The total cost of the proposal—that -is, owning and operating a product—is the sum -of those two costs. Early on, frozen asset costs -dominate; later, the operating and maintenance -costs dominate. There is a point in time where the -sum of the costs is minimized; this is called the -minimum cost lifetime. -To properly compare a proposal with a four- -year life span to a proposal with a six-year life -span, the economic effects of either cutting the -six-year proposal by two years or investing the -profits from the four-year proposal for another -two years need to be addressed. The planning -horizon, sometimes known as the study period, -is the consistent time frame over which propos- -als are considered. Effects such as software life- -time will need to be factored into establishing a -planning horizon. Once the planning horizon is -established, several techniques are available for -putting proposals with different life spans into -that planning horizon. -``` -``` -2.10. Price and Pricing -[1*, c13] -``` -``` -A price is what is paid in exchange for a good or -service. Price is a fundamental aspect of financial -modeling and is one of the four Ps of the marketing -mix. The other three Ps are product, promotion, -and place. Price is the only revenue-generating ele- -ment amongst the four Ps; the rest are costs. -Pricing is an element of finance and marketing. -It is the process of determining what a company -will receive in exchange for its products. Pricing -factors include manufacturing cost, market place- -ment, competition, market condition, and quality -of product. Pricing applies prices to products and -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, -combination of multiple orders, service offerings, -and many others. The needs of the consumer can -be converted into demand only if the consumer -has the willingness and capacity to buy the prod- -uct. Thus, pricing is very important in marketing. -Pricing is initially done during the project initia- -tion phase and is a part of “go” decision making. - -_2.11. Cost and Costing_ -[1*, c15] - -A cost is the value of money that has been used up -to produce something and, hence, is not available -for use anymore. In economics, a cost is an alter- -native that is given up as a result of a decision. -A sunk cost is the expenses before a certain -time, typically used to abstract decisions from -expenses in the past, which can cause emotional -hurdles in looking forward. From a traditional -economics point of view, sunk costs should not -be considered in decision making. Opportunity -cost is the cost of an alternative that must be for- -gone in order to pursue another alternative. -Costing is part of finance and product manage- -ment. It is the process to determine the cost based -on expenses (e.g., production, software engineer- -ing, distribution, rework) and on the target cost -to be competitive and successful in a market. -The target cost can be below the actual estimated -cost. The planning and controlling of these costs -(called _cost management_ ) is important and should -always be included in costing. -An important concept in costing is the total cost -of ownership (TCO). This holds especially for -software, because there are many not-so-obvious -costs related to SPLC activities after initial prod- -uct development. TCO for a software product is -defined as the total cost for acquiring, activating, -and keeping that product running. These costs -can be grouped as direct and indirect costs. TCO -is an accounting method that is crucial in making -sound economic decisions. - -_2.12. Performance Measurement_ -[3*, c7, c8] - -Performance measurement is the process whereby -an organization establishes and measures the - -``` -parameters used to determine whether programs, -investments, and acquisitions are achieving the -desired results. It is used to evaluate whether -performance objectives are actually achieved; to -control budgets, resources, progress, and deci- -sions; and to improve performance. -``` -``` -2.13. Earned Value Management -[3*, c8] -``` -``` -Earned value management (EVM) is a project -management technique for measuring progress -based on created value. At a given moment, the -results achieved to date in a project are com- -pared with the projected budget and the planned -schedule progress for that date. Progress relates -already-consumed resources and achieved -results at a given point in time with the respec- -tive planned values for the same date. It helps -to identify possible performance problems at an -early stage. A key principle in EVM is tracking -cost and schedule variances via comparison of -planned versus actual schedule and budget versus -actual cost. EVM tracking gives much earlier vis- -ibility to deviations and thus permits corrections -earlier than classic cost and schedule tracking that -only looks at delivered documents and products. -``` -``` -2.14. Termination Decisions -[1*, c11, c12] [2*, c9] -``` -``` -Termination means to end a project or product. -Termination can be preplanned for the end of a -long product lifetime (e.g., when foreseeing that a -product will reach its lifetime) or can come rather -spontaneously during product development -(e.g., when project performance targets are not -achieved). In both cases, the decision should be -carefully prepared, considering always the alter- -natives of continuing versus terminating. Costs of -different alternatives must be estimated—cover- -ing topics such as replacement, information col- -lection, suppliers, alternatives, assets, and utiliz- -ing resources for other opportunities. Sunk costs -should not be considered in such decision making -because they have been spent and will not reap- -pear as a value. -``` - -**12-10** **_SWEBOK® Guide_** **V3.0** - -_2.15. Replacement and Retirement Decisions_ -[1*, c12] [2*, c9] - -A replacement decision is made when an organi- -zation already has a particular asset and they are -considering replacing it with something else; for -example, deciding between maintaining and sup- -porting a legacy software product or redeveloping -it from the ground up. Replacement decisions use -the same business decision process as described -above, but there are additional challenges: sunk -cost and salvage value. Retirement decisions are -also about getting out of an activity altogether, -such as when a software company considers not -selling a software product anymore or a hardware -manufacturer considers not building and selling a -particular model of computer any longer. Retire- -ment decision can be influenced by lock-in fac- -tors such as technology dependency and high exit -costs. - -**3. Risk and Uncertainty** - -_3.1. Goals, Estimates, and Plans_ -[3*, c6] - -Goals in software engineering economics are -mostly business goals (or business objectives). - -``` -A business goal relates business needs (such as -increasing profitability) to investing resources -(such as starting a project or launching a prod- -uct with a given budget, content, and timing). -Goals apply to operational planning (for instance, -to reach a certain milestone at a given date or to -extend software testing by some time to achieve a -desired quality level—see Key Issues in the Soft- -ware Testing KA) and to the strategic level (such -as reaching a certain profitability or market share -in a stated time period). -An estimate is a well-founded evaluation of -resources and time that will be needed to achieve -stated goals (see Effort, Schedule, and Cost Esti- -mation in the Software Engineering Management -KA and Maintenance Cost Estimation in the Soft- -ware Maintenance KA). A software estimate is -used to determine whether the project goals can -be achieved within the constraints on schedule, -budget, features, and quality attributes. Estimates -are typically internally generated and are not -necessarily visible externally. Estimates should -not be driven exclusively by the project goals -because this could make an estimate overly opti- -mistic. Estimation is a periodic activity; estimates -should be continually revised during a project. -A plan describes the activities and milestones -that are necessary in order to reach the goals of -``` -``` -Figure 12.4. Goals, Estimates, and Plans -``` - -``` -Software Engineering Economics 12-11 -``` -a project (see Software Project Planning in the -Software Engineering Management KA). The -plan should be in line with the goal and the esti- -mate, which is not necessarily easy and obvi- -ous—such as when a software project with given -requirements would take longer than the target -date foreseen by the client. In such cases, plans -demand a review of initial goals as well as esti- -mates and the underlying uncertainties and inac- -curacies. Creative solutions with the underlying -rationale of achieving a win-win position are -applied to resolve conflicts. -To be of value, planning should involve con- -sideration of the project constraints and commit- -ments to stakeholders. Figure 12.4 shows how -goals are initially defined. Estimates are done -based on the initial goals. The plan tries to match -the goals and the estimates. This is an iterative -process, because an initial estimate typically does -not meet the initial goals. - -_3.2. Estimation Techniques_ -[3*, c6] - -Estimations are used to analyze and forecast the -resources or time necessary to implement require- -ments (see Effort, Schedule, and Cost Estimation -in the Software Engineering Management KA -and Maintenance Cost Estimation in the Software -Maintenance KA). Five families of estimation -techniques exist: - -- Expert judgment -- Analogy -- Estimation by parts -- Parametric methods -- Statistical methods. - -No single estimation technique is perfect, so -using multiple estimation technique is useful. -Convergence among the estimates produced by -different techniques indicates that the estimates -are probably accurate. Spread among the esti- -mates indicates that certain factors might have -been overlooked. Finding the factors that caused -the spread and then reestimating again to pro- -duce results that converge could lead to a better -estimate. - -``` -3.3. Addressing Uncertainty -[3*, c6] -``` -``` -Because of the many unknown factors during -project initiation and planning, estimates are -inherently uncertain; that uncertainty should be -addressed in business decisions. Techniques for -addressing uncertainty include -``` -- consider ranges of estimates -- analyze sensitivity to changes of assumptions -- delay final decisions. - -``` -3.4. Prioritization -[3*, c6] -``` -``` -Prioritization involves ranking alternatives based -on common criteria to deliver the best possible -value. In software engineering projects, software -requirements are often prioritized in order to -deliver the most value to the client within con- -straints of schedule, budget, resources, and tech- -nology, or to provide for building product incre- -ments, where the first increments provide the -highest value to the customer (see Requirements -Classification and Requirements Negotiation in -the Software Requirements KA and Software -Life Cycle Models in the Software Engineering -Process KA). -``` -``` -3.5. Decisions under Risk -[1*, c24] [3*, c9] -``` -``` -Decisions under risk techniques are used when -the decision maker can assign probabilities to the -different possible outcomes (see Risk Manage- -ment in the Software Engineering Management -KA). The specific techniques include -``` -- expected value decision making -- expectation variance and decision making -- Monte Carlo analysis -- decision trees -- expected value of perfect information. - - -**12-12** **_SWEBOK® Guide_** **V3.0** - -_3.6. Decisions under Uncertainty_ -[1*, c25] [3*, c9] - -Decisions under uncertainty techniques are used -when the decision maker cannot assign probabili- -ties to the different possible outcomes because -needed information is not available (see Risk -Management in the Software Engineering Man- -agement KA). Specific techniques include - -- Laplace Rule -- Maximin Rule -- Maximax Rule -- Hurwicz Rule -- Minimax Regret Rule. - **4. Economic Analysis Methods** - -``` -4.1. For-Profit Decision Analysis -[1*, c10] -``` -``` -Figure 12.5 describes a process for identifying -the best alternative from a set of mutually exclu- -sive alternatives. Decision criteria depend on the -business objectives and typically include ROI -(see section 4.3, Return on Investment) or Return -on Capital Employed (ROCE) (see section 4.4, -Return on Capital Employed). -For-profit decision techniques don’t apply for -government and nonprofit organizations. In these -cases, organizations have different goals—which -means that a different set of decision techniques -are needed, such as cost-benefit or cost-effective- -ness analysis. -``` -``` -Figure 12.5. The for-profit decision-making process -``` - -``` -Software Engineering Economics 12-13 -``` -_4.2. Minimum Acceptable Rate of Return_ -[1*, c10] - -The minimum acceptable rate of return (MARR) -is the lowest internal rate of return the organi- -zation would consider to be a good investment. -Generally speaking, it wouldn’t be smart to invest -in an activity with a return of 10% when there’s -another activity that’s known to return 20%. -The MARR is a statement that an organization -is confident it can achieve at least that rate of -return. The MARR represents the organization’s -opportunity cost for investments. By choosing -to invest in some activity, the organization is -explicitly deciding to not invest that same money -somewhere else. If the organization is already -confident it can get some known rate of return, -other alternatives should be chosen only if their -rate of return is at least that high. A simple way -to account for that opportunity cost is to use the -MARR as the interest rate in business decisions. -An alternative’s present worth evaluated at the -MARR shows how much more or less (in pres- -ent-day cash terms) that alternative is worth than -investing at the MARR. - -_4.3. Return on Investment_ -[1*, c10] - -Return on investment (ROI) is a measure of the -profitability of a company or business unit. It -is defined as the ratio of money gained or lost -(whether realized or unrealized) on an investment -relative to the amount of money invested. The -purpose of ROI varies and includes, for instance, -providing a rationale for future investments and -acquisition decisions. - -_4.4. Return on Capital Employed_ - -The return on capital employed (ROCE) is a mea- -sure of the profitability of a company or business -unit. It is defined as the ratio of a gross profit -before taxes and interest (EBIT) to the total assets -minus current liabilities. It describes the return on -the used capital. - -``` -4.5. Cost-Benefit Analysis -[1*, c18] -``` -``` -Cost-benefit analysis is one of the most widely -used methods for evaluating individual propos- -als. Any proposal with a benefit-cost ratio of less -than 1.0 can usually be rejected without further -analysis because it would cost more than the ben- -efit. Proposals with a higher ratio need to con- -sider the associated risk of an investment and -compare the benefits with the option of investing -the money at a guaranteed interest rate (see sec- -tion 4.2, Minimum Acceptable Rate of Return). -``` -``` -4.6. Cost-Effectiveness Analysis -[1*, c18] -``` -``` -Cost-effectiveness analysis is similar to cost- -benefit analysis. There are two versions of cost- -effectiveness analysis: the fixed-cost version -maximizes the benefit given some upper bound -on cost; the fixed-effectiveness version minimizes -the cost needed to achieve a fixed goal. -``` -``` -4.7. Break-Even Analysis -[1*, c19] -``` -``` -Break-even analysis identifies the point where -the costs of developing a product and the revenue -to be generated are equal. Such an analysis can -be used to choose between different proposals at -different estimated costs and revenue. Given esti- -mated costs and revenue of two or more propos- -als, break-even analysis helps in choosing among -them. -``` -``` -4.8. Business Case -[1*, c3] -``` -``` -The business case is the consolidated information -summarizing and explaining a business proposal -from different perspectives for a decision maker -(cost, benefit, risk, and so on). It is often used -to assess the potential value of a product, which -can be used as a basis in the investment decision- -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 -business objectives. - -_4.9. Multiple Attribute Evaluation_ -[1*, c26] - -The topics discussed so far are used to make deci- -sions based on a single decision criterion: money. -The alternative with the best present worth, the -best ROI, and so forth is the one selected. Aside -from technical feasibility, money is almost -always the most important decision criterion, but -it’s not always the only one. Quite often there are -other criteria, other “attributes,” that need to be -considered, and those attributes can’t be cast in -terms of money. Multiple attribute decision tech- -niques allow other, nonfinancial criteria to be fac- -tored into the decision. -There are two families of multiple attribute -decision techniques that differ in how they use -the attributes in the decision. One family is the -“compensatory,” or single-dimensioned, tech- -niques. This family collapses all of the attributes -onto a single figure of merit. The family is called -compensatory because, for any given alternative, -a lower score in one attribute can be compensated -by—or traded off against—a higher score in other -attributes. The compensatory techniques include - -- nondimensional scaling -- additive weighting -- analytic hierarchy process. - -In contrast, the other family is the “noncom- -pensatory,” or fully dimensioned, techniques. -This family does not allow tradeoffs among the -attributes. Each attribute is treated as a separate -entity in the decision process. The noncompensa- -tory techniques include - -- dominance -- satisficing -- lexicography. - -_4.10. Optimization Analysis_ -[1*, c20] - -The typical use of optimization analysis is to -study a cost function over a range of values to - -``` -find the point where overall performance is best. -Software’s classic space-time tradeoff is an -example of optimization; an algorithm that runs -faster will often use more memory. Optimization -balances the value of the faster runtime against -the cost of the additional memory. -Real options analysis can be used to quantify -the value of project choices, including the value -of delaying a decision. Such options are difficult -to compute with precision. However, awareness -that choices have a monetary value provides -insight in the timing of decisions such as increas- -ing project staff or lengthening time to market to -improve quality. -``` -**5. Practical Considerations** - -``` -5.1. The “Good Enough” Principle -[1*, c21] -``` -``` -Often software engineering projects and products -are not precise about the targets that should be -achieved. Software requirements are stated, but -the marginal value of adding a bit more function- -ality cannot be measured. The result could be late -delivery or too-high cost. The “good enough” -principle relates marginal value to marginal cost -and provides guidance to determine criteria when -a deliverable is “good enough” to be delivered. -These criteria depend on business objectives and -on prioritization of different alternatives, such as -ranking software requirements, measurable qual- -ity attributes, or relating schedule to product con- -tent and cost. -The RACE principle (reduce accidents and -control essence) is a popular rule towards good -enough software. Accidents imply unnecessary -overheads such as gold-plating and rework due -to late defect removal or too many requirements -changes. Essence is what customers pay for. Soft- -ware engineering economics provides the mech- -anisms to define criteria that determine when a -deliverable is “good enough” to be delivered. -It also highlights that both words are relevant: -“good” and “enough.” Insufficient quality or -insufficient quantity is not good enough. -Agile methods are examples of “good enough” -that try to optimize value by reducing the over- -head of delayed rework and the gold plating that -``` - -``` -Software Engineering Economics 12-15 -``` -results from adding features that have low mar- -ginal value for the users (see Agile Methods in -the Software Engineering Models and Methods -KA and Software Life Cycle Models in the Soft- -ware Engineering Process KA). In agile meth- -ods, detailed planning and lengthy development -phases are replaced by incremental planning and -frequent delivery of small increments of a deliv- -erable product that is tested and evaluated by user -representatives. - -_5.2. Friction-Free Economy_ - -Economic friction is everything that keeps mar- -kets from having perfect competition. It involves -distance, cost of delivery, restrictive regulations, -and/or imperfect information. In high-friction -markets, customers don’t have many suppliers -from which to choose. Having been in a business -for a while or owning a store in a good location -determines the economic position. It’s hard for -new competitors to start business and compete. -The marketplace moves slowly and predictably. -Friction-free markets are just the reverse. New -competitors emerge and customers are quick to -respond. The marketplace is anything but predict- -able. Theoretically, software and IT are friction- -free. New companies can easily create products -and often do so at a much lower cost than estab- -lished companies, since they need not consider -any legacies. Marketing and sales can be done -via the Internet and social networks, and basi- -cally free distribution mechanisms can enable a -ramp up to a global business. Software engineer- -ing economics aims to provide foundations to -judge how a software business performs and how -friction-free a market actually is. For instance, -competition among software app developers is -inhibited when apps must be sold through an app -store and comply with that store’s rules. - -_5.3. Ecosystems_ - -An ecosystem is an environment consisting of all -the mutually dependent stakeholders, business -units, and companies working in a particular area. - -``` -In a typical ecosystem, there are producers and -consumers, where the consumers add value to -the consumed resources. Note that a consumer is -not the end user but an organization that uses the -product to enhance it. A software ecosystem is, -for instance, a supplier of an application working -with companies doing the installation and sup- -port in different regions. Neither one could exist -without the other. Ecosystems can be permanent -or temporary. Software engineering economics -provides the mechanisms to evaluate alternatives -in establishing or extending an ecosystem—for -instance, assessing whether to work with a spe- -cific distributor or have the distribution done by a -company doing service in an area. -``` -``` -5.4. Offshoring and Outsourcing -``` -``` -Offshoring means executing a business activity -beyond sales and marketing outside the home -country of an enterprise. Enterprises typically -either have their offshoring branches in low- -cost countries or they ask specialized companies -abroad to execute the respective activity. Offshor- -ing should therefore not be confused with out- -sourcing. Offshoring within a company is called -captive offshoring. Outsourcing is the result-ori- -ented relationship with a supplier who executes -business activities for an enterprise when, tra- -ditionally, those activities were executed inside -the enterprise. Outsourcing is site-independent. -The supplier can reside in the neighborhood of -the enterprise or offshore (outsourced offshor- -ing). Software engineering economics provides -the basic criteria and business tools to evaluate -different sourcing mechanisms and control their -performance. For instance, using an outsourcing -supplier for software development and mainte- -nance might reduce the cost per hour of software -development, but increase the number of hours -and capital expenses due to an increased need for -monitoring and communication. (For more infor- -mation on offshoring and outsourcing, see “Out- -sourcing” in Management Issues in the Software -Maintenance KA.) -``` - -**12-16** **_SWEBOK® Guide_** **V3.0** - -##### MATRIX OF TOPICS VS. REFERENCE MATERIAL - -``` -Tockey 2005 -``` -##### [1*] - -``` -Sommerville 2011 -``` -##### [2*] - -``` -Fairley 2009 -``` -##### [3*] - -**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 -``` -``` -Tockey 2005 -``` -##### [1*] - -``` -Sommerville 2011 -``` -##### [2*] - -``` -Fairley 2009 -``` -##### [3*] - -**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 - -_A Guide to the Project Management Body of -Knowledge (PMBOK® Guide)_ [4]. - -The _PMBOK® Guide_ provides guidelines for -managing individual projects and defines project -management related concepts. It also describes -the project management life cycle and its related -processes, as well as the project life cycle. It is -a globally recognized guide for the project man- -agement profession. - -_Software Extension to the Guide to the Project -Management Body of Knowledge (SWX)_ [5]. - -_SWX_ provides adaptations and extensions to the -generic practices of project management docu- -mented in the _PMBOK® Guide_ for managing -software projects. The primary contribution of -this extension to the _PMBOK® Guide_ is descrip- -tion of processes that are applicable for managing -adaptive life cycle software projects. - -B.W. Boehm, _Software Engineering Economics_ -[6]. - -This book is the classic reading on software -engineering economics. It provides an overview -of business thinking in software engineering. -Although the examples and figures are dated, it -still is worth reading. - -C. Ebert and R. Dumke, _Software Measurement_ -[7]. - -This book provides an overview on quantita- -tive 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 busi- -ness case in the software and IT businesses. Many -useful examples illustrate how the business case -is formulated and quantified. - -##### REFERENCES - -``` -[1*] S. Tockey, Return on Software: Maximizing -the Return on Your Software Investment , -Addison-Wesley, 2004. -``` -``` -[2*] J.H. Allen et al., Software Security -Engineering: A Guide for Project -Managers , Addison-Wesley, 2008. -``` -``` -[3*] R.E. Fairley, Managing and Leading -Software Projects , Wiley-IEEE Computer -Society Press, 2009. -``` -``` -[4] Project Management Institute, A Guide -to the Project Management Body of -Knowledge (PMBOK(R) Guide) , 5th ed., -Project Management Institute, 2013. -``` -``` -[5] Project Management Institute and IEEE -Computer Society, Software Extension -to the PMBOK® Guide Fifth Edition , ed: -Project Management Institute, 2013. -``` -``` -[6] B.W. Boehm, Software Engineering -Economics , Prentice-Hall, 1981. -``` -``` -[7] C. Ebert and R. Dumke, Software -Measurement , Springer, 2007. -``` -``` -[8] D.J. Reifer, Making the Software Business -Case: Improvement by the Numbers , -Addison Wesley, 2002. -``` blob - 86a77882cf74a312b1123795dac386359c52e8cb (mode 644) blob + /dev/null --- 13_computing_foundations.markdown +++ /dev/null @@ -1,3452 +0,0 @@ -``` -13-1 -``` -**CHAPTER 13** - -**COMPUTING FOUNDATIONS** - -##### ACRONYMS - -``` -AOP Aspect-Oriented Programming -ALU Arithmetic and Logic Unit -``` -``` -API -Application Programming -Interface -ATM Asynchronous Transfer Mode -B/S Browser-Server -``` -``` -CERT -Computer Emergency Response -Te a m -COTS Commercial Off-The-Shelf -CRUD Create, Read, Update, Delete -C/S Client-Server -CS Computer Science -DBMS Database Management System -FPU Float Point Unit -I/O Input and Output -ISA Instruction Set Architecture -``` -``` -ISO -International Organization for -Standardization -ISP Internet Service Provider -LAN Local Area Network -MUX Multiplexer -NIC Network Interface Card -OOP Object-Oriented Programming -OS Operating System -OSI Open Systems Interconnection -PC Personal Computer -PDA Personal Digital Assistant -PPP Point-to-Point Protocol -RFID Radio Frequency Identification -RAM Random Access Memory -ROM Read Only Memory -``` -``` -SCSI Small Computer System Interface -SQL Structured Query Language -TCP Transport Control Protocol -UDP User Datagram Protocol -VPN Virtual Private Network -WA N Wide Area Network -``` -##### INTRODUCTION - -``` -The scope of the Computing Foundations knowl- -edge area (KA) encompasses the development -and operational environment in which software -evolves and executes. Because no software can -exist in a vacuum or run without a computer, the -core of such an environment is the computer and -its various components. Knowledge about the -computer and its underlying principles of hard- -ware and software serves as a framework on -which software engineering is anchored. Thus, all -software engineers must have good understand- -ing of the Computing Foundations KA. -It is generally accepted that software engi- -neering builds on top of computer science. For -example, “Software Engineering 2004: Cur- -riculum Guidelines for Undergraduate Degree -Programs in Software Engineering” [1] clearly -states, “One particularly important aspect is that -software engineering builds on computer science -and mathematics” (italics added). -Steve Tockey wrote in his book Return on -Software : -``` -``` -Both computer science and software engi- -neering deal with computers, computing, -and software. The science of computing, as -a body of knowledge, is at the core of both. -``` - -**13-2** **_SWEBOK® Guide_** **V3.0** - -``` -... Software engineering is concerned with -the application of computers, computing, -and software to practical purposes, specifi- -cally the design, construction, and opera- -tion of efficient and economical software -systems. -``` -Thus, at the core of software engineering is an -understanding of computer science. -While few people will deny the role computer -science plays in the development of software -engineering both as a discipline and as a body of -knowledge, the importance of computer science -to software engineering cannot be overempha- -sized; thus, this Computing Foundations KA is -being written. -The majority of topics discussed in the Com- -puting Foundations KA are also topics of discus- -sion in basic courses given in computer science -undergraduate and graduate programs. Such -courses include programming, data structure, -algorithms, computer organization, operating -systems, compilers, databases, networking, dis- -tributed systems, and so forth. Thus, when break- -ing down topics, it can be tempting to decompose -the Computing Foundations KA according to -these often-found divisions in relevant courses. -However, a purely course-based division of -topics suffers serious drawbacks. For one, not -all courses in computer science are related or -equally important to software engineering. Thus, -some topics that would otherwise be covered in a -computer science course are not covered in this - -``` -KA. For example, computer graphics—while an -important course in a computer science degree -program—is not included in this KA. -Second, some topics discussed in this guide- -line do not exist as standalone courses in under- -graduate or graduate computer science programs. -Consequently, such topics may not be adequately -covered in a purely course-based breakdown. For -example, abstraction is a topic incorporated into -several different computer science courses; it is -unclear which course abstraction should belong -to in a course-based breakdown of topics. -The Computing Foundations KA is divided into -seventeen different topics. A topic’s direct useful- -ness to software engineers is the criterion used for -selecting topics for inclusion in this KA (see Figure -13.1). The advantage of this topic-based breakdown -is its foundation on the belief that Computing Foun- -dations—if it is to be grasped firmly—must be con- -sidered as a collection of logically connected topics -undergirding software engineering in general and -software construction in particular. -The Computing Foundations KA is related -closely to the Software Design, Software Con- -struction, Software Testing, Software Main- -tenance, Software Quality, and Mathematical -Foundations KAs. -``` -``` -BREAKDOWN OF TOPICS FOR -COMPUTING FOUNDATIONS -``` -``` -The breakdown of topics for the Computing -Foundations KA is shown in Figure 13.1. -``` -``` -Figure 13.1. Breakdown of Topics for the Computing Foundations KA -``` - -``` -Computing Foundations 13-3 -``` -**1. Problem Solving Techniques** - [2*, s3.2, c4] [3*, c5] - -The concepts, notions, and terminology introduced -here form an underlying basis for understanding -the role and scope of problem solving techniques. - -_1.1. Definition of Problem Solving_ - -Problem solving refers to the thinking and activi- -ties conducted to answer or derive a solution to -a problem. There are many ways to approach a -problem, and each way employs different tools -and uses different processes. These different -ways of approaching problems gradually expand -and define themselves and finally give rise to dif- -ferent disciplines. For example, software engi- -neering focuses on solving problems using com- -puters and software. -While different problems warrant different -solutions and may require different tools and -processes, the methodology and techniques used -in solving problems do follow some guidelines -and can often be generalized as problem solving -techniques. For example, a general guideline for -solving a generic engineering problem is to use -the three-step process given below [2*]. - -- Formulate the real problem. -- Analyze the problem. -- Design a solution search strategy. - -_1.2. Formulating the Real Problem_ - -Gerard Voland writes, “It is important to recog- -nize that a specific problem should be formulated -if one is to develop a specific solution” [2*]. -This formulation is called the problem statement, -which explicitly specifies what both the problem -and the desired outcome are. -Although there is no universal way of stat- -ing a problem, in general a problem should be -expressed in such a way as to facilitate the devel- -opment of solutions. Some general techniques -to help one formulate the real problem include -statement-restatement, determining the source -and the cause, revising the statement, analyzing -present and desired state, and using the fresh eye -approach. - -``` -1.3. Analyze the Problem -``` -``` -Once the problem statement is available, the next -step is to analyze the problem statement or situ- -ation to help structure our search for a solution. -Four types of analysis include situation analysis, -in which the most urgent or critical aspects of a -situation are identified first; problem analysis, in -which the cause of the problem must be deter- -mined; decision analysis, in which the action(s) -needed to correct the problem or eliminate its -cause must be determined; and potential problem -analysis, in which the action(s) needed to prevent -any reoccurrences of the problem or the develop- -ment of new problems must be determined. -``` -``` -1.4. Design a Solution Search Strategy -``` -``` -Once the problem analysis is complete, we can -focus on structuring a search strategy to find the -solution. In order to find the “best” solution (here, -“best” could mean different things to different -people, such as faster, cheaper, more usable, dif- -ferent capabilities, etc.), we need to eliminate -paths that do not lead to viable solutions, design -tasks in a way that provides the most guidance in -searching for a solution, and use various attributes -of the final solution state to guide our choices in -the problem solving process. -``` -``` -1.5. Problem Solving Using Programs -``` -``` -The uniqueness of computer software gives prob- -lem solving a flavor that is distinct from general -engineering problem solving. To solve a problem -using computers, we must answer the following -questions. -``` -- How do we figure out what to tell the com- - puter to do? -- How do we convert the problem statement - into an algorithm? -- How do we convert the algorithm into - machine instructions? - -``` -The first task in solving a problem using a com- -puter is to determine what to tell the computer to -do. There may be many ways to tell the story, but -all should take the perspective of a computer such -``` - -**13-4** **_SWEBOK® Guide_** **V3.0** - -that the computer can eventually solve the prob- -lem. In general, a problem should be expressed -in such a way as to facilitate the development of -algorithms and data structures for solving it. -The result of the first task is a problem state- -ment. The next step is to convert the problem state- -ment into algorithms that solve the problem. Once -an algorithm is found, the final step converts the -algorithm into machine instructions that form the -final solution: software that solves the problem. -Abstractly speaking, problem solving using a -computer can be considered as a process of prob- -lem transformation—in other words, the step-by- -step transformation of a problem statement into -a problem solution. To the discipline of software -engineering, the ultimate objective of problem -solving is to transform a problem expressed in -natural language into electrons running around -a circuit. In general, this transformation can be -broken into three phases: - -``` -a) Development of algorithms from the prob- -lem statement. -b) Application of algorithms to the problem. -c) Transformation of algorithms to program -code. -``` -The conversion of a problem statement into -algorithms and algorithms into program codes -usually follows a “stepwise refinement” (a.k.a. -systematic decomposition) in which we start -with a problem statement, rewrite it as a task, -and recursively decompose the task into a few -simpler subtasks until the task is so simple that -solutions to it are straightforward. There are three -basic ways of decomposing: sequential, condi- -tional, and iterative. - -**2. Abstraction** - [3*, s5.2–5.4] - -Abstraction is an indispensible technique associ- -ated with problem solving. It refers to both the -process and result of generalization by reducing -the information of a concept, a problem, or an -observable phenomenon so that one can focus -on the “big picture.” One of the most important -skills in any engineering undertaking is framing -the levels of abstraction appropriately. - -``` -“Through abstraction,” according to Voland, -“we view the problem and its possible solution -paths from a higher level of conceptual under- -standing. As a result, we may become better pre- -pared to recognize possible relationships between -different aspects of the problem and thereby gen- -erate more creative design solutions” [2*]. This -is particularly true in computer science in general -(such as hardware vs. software) and in software -engineering in particular (data structure vs. data -flow, and so forth). -``` -``` -2.1. Levels of Abstraction -``` -``` -When abstracting, we concentrate on one “level” -of the big picture at a time with confidence that -we can then connect effectively with levels above -and below. Although we focus on one level, -abstraction does not mean knowing nothing about -the neighboring levels. Abstraction levels do not -necessarily correspond to discrete components -in reality or in the problem domain, but to well- -defined standard interfaces such as programming -APIs. The advantages that standard interfaces -provide include portability, easier software/hard- -ware integration and wider usage. -``` -``` -2.2. Encapsulation -``` -``` -Encapsulation is a mechanism used to imple- -ment abstraction. When we are dealing with one -level of abstraction, the information concerning -the levels below and above that level is encapsu- -lated. This information can be the concept, prob- -lem, or observable phenomenon; or it may be the -permissible operations on these relevant entities. -Encapsulation usually comes with some degree -of information hiding in which some or all of -the underlying details are hidden from the level -above the interface provided by the abstraction. -To an object, information hiding means we don’t -need to know the details of how the object is rep- -resented or how the operations on those objects -are implemented. -``` -``` -2.3. Hierarchy -``` -``` -When we use abstraction in our problem formula- -tion and solution, we may use different abstractions -``` - -``` -Computing Foundations 13-5 -``` -at different times—in other words, we work on dif- -ferent levels of abstraction as the situation calls. -Most of the time, these different levels of abstrac- -tion are organized in a hierarchy. There are many -ways to structure a particular hierarchy and the -criteria used in determining the specific content of -each layer in the hierarchy varies depending on the -individuals performing the work. -Sometimes, a hierarchy of abstraction is sequen- -tial, which means that each layer has one and only -one predecessor (lower) layer and one and only -one successor (upper) layer—except the upmost -layer (which has no successor) and the bottommost -layer (which has no predecessor). Sometimes, -however, the hierarchy is organized in a tree-like -structure, which means each layer can have more -than one predecessor layer but only one successor -layer. Occasionally, a hierarchy can have a many- -to-many structure, in which each layer can have -multiple predecessors and successors. At no time, -shall there be any loop in a hierarchy. -A hierarchy often forms naturally in task decom- -position. Often, a task analysis can be decomposed -in a hierarchical fashion, starting with the larger -tasks and goals of the organization and breaking -each of them down into smaller subtasks that can -again be further subdivided This continuous divi- -sion of tasks into smaller ones would produce a -hierarchical structure of tasks-subtasks. - -_2.4. Alternate Abstractions_ - -Sometimes it is useful to have multiple alternate -abstractions for the same problem so that one can -keep different perspectives in mind. For exam- -ple, we can have a class diagram, a state chart, -and a sequence diagram for the same software -at the same level of abstraction. These alternate -abstractions do not form a hierarchy but rather -complement each other in helping understanding -the problem and its solution. Though beneficial, it -is as times difficult to keep alternate abstractions -in sync. - -**3. Programming Fundamentals** - [3*, c6–19] - -Programming is composed of the methodologies -or activities for creating computer programs that - -``` -perform a desired function. It is an indispensible -part in software construction. In general, pro- -gramming can be considered as the process of -designing, writing, testing, debugging, and main- -taining the source code. This source code is writ- -ten in a programming language. -The process of writing source code often -requires expertise in many different subject -areas—including knowledge of the application -domain, appropriate data structures, special- -ized algorithms, various language constructs, -good programming techniques, and software -engineering. -``` -``` -3.1. The Programming Process -``` -``` -Programming involves design, writing, testing, -debugging, and maintenance. Design is the con- -ception or invention of a scheme for turning a -customer requirement for computer software into -operational software. It is the activity that links -application requirements to coding and debug- -ging. Writing is the actual coding of the design -in an appropriate programming language. Testing -is the activity to verify that the code one writes -actually does what it is supposed to do. Debug- -ging is the activity to find and fix bugs (faults) in -the source code (or design). Maintenance is the -activity to update, correct, and enhance existing -programs. Each of these activities is a huge topic -and often warrants the explanation of an entire -KA in the SWEBOK Guide and many books. -``` -``` -3.2. Programming Paradigms -``` -``` -Programming is highly creative and thus some- -what personal. Different people often write dif- -ferent programs for the same requirements. This -diversity of programming causes much difficulty -in the construction and maintenance of large -complex software. Various programming para- -digms have been developed over the years to put -some standardization into this highly creative and -personal activity. When one programs, he or she -can use one of several programming paradigms to -write the code. The major types of programming -paradigms are discussed below. -Unstructured Programming: In unstructured -programming, a programmer follows his/her -``` - -**13-6** **_SWEBOK® Guide_** **V3.0** - -hunch to write the code in whatever way he/she -likes as long as the function is operational. Often, -the practice is to write code to fulfill a specific -utility without regard to anything else. Programs -written this way exhibit no particular structure— -thus the name “unstructured programming.” -Unstructured programming is also sometimes -called ad hoc programming. -_Structured/Procedural/ Imperative Program- -ming:_ A hallmark of structured programming is -the use of well-defined control structures, includ- -ing procedures (and/or functions) with each pro- -cedure (or function) performing a specific task. -Interfaces exist between procedures to facilitate -correct and smooth calling operations of the pro- -grams. Under structured programming, program- -mers often follow established protocols and rules -of thumb when writing code. These protocols -and rules can be numerous and cover almost the -entire scope of programming—ranging from the -simplest issue (such as how to name variables, -functions, procedures, and so forth) to more com- -plex issues (such as how to structure an interface, -how to handle exceptions, and so forth). -_Object-Oriented Programming:_ While proce- -dural programming organizes programs around -procedures, object-oriented programming (OOP) -organize a program around objects, which are -abstract data structures that combine both data -and methods used to access or manipulate the -data. The primary features of OOP are that objects -representing various abstract and concrete entities -are created and these objects interact with each -other to collectively fulfill the desired functions. -_Aspect-Oriented Programming:_ Aspect-ori- -ented programming (AOP) is a programming -paradigm that is built on top of OOP. AOP aims -to isolate secondary or supporting functions from -the main program’s business logic by focusing -on the cross sections (concerns) of the objects. -The primary motivation for AOP is to resolve -the object tangling and scattering associated with -OOP, in which the interactions among objects -become very complex. The essence of AOP is -the greatly emphasized separation of concerns, -which separates noncore functional concerns or -logic into various aspects. -_Functional Programming_ : Though less popu- -lar, functional programming is as viable as -the other paradigms in solving programming - -``` -problems. In functional programming, all com- -putations are treated as the evaluation of math- -ematical functions. In contrast to the imperative -programming that emphasizes changes in state, -functional programming emphasizes the applica- -tion of functions, avoids state and mutable data, -and provides referential transparency. -``` -**4. Programming Language Basics** - [4*, c6] - -``` -Using computers to solve problems involves -programming—which is writing and organiz- -ing instructions telling the computer what to do -at each step. Programs must be written in some -programming language with which and through -which we describe necessary computations. In -other words, we use the facilities provided by a -programming language to describe problems, -develop algorithms, and reason about problem -solutions. To write any program, one must under- -stand at least one programming language. -``` -``` -4.1. Programming Language Overview -``` -``` -A programming language is designed to express -computations that can be performed by a com- -puter. In a practical sense, a programming lan- -guage is a notation for writing programs and thus -should be able to express most data structures and -algorithms. Some, but not all, people restrict the -term “programming language” to those languages -that can express all possible algorithms. -Not all languages have the same importance -and popularity. The most popular ones are often -defined by a specification document established -by a well-known and respected organization. For -example, the C programming language is speci- -fied by an ISO standard named ISO/IEC 9899. -Other languages, such as Perl and Python, do not -enjoy such treatment and often have a dominant -implementation that is used as a reference. -``` -``` -4.2. Syntax and Semantics of Programming -Languages -``` -``` -Just like natural languages, many programming -languages have some form of written specifica- -tion of their syntax (form) and semantics (mean- -ing). Such specifications include, for example, -``` - -``` -Computing Foundations 13-7 -``` -specific requirements for the definition of vari- -ables and constants (in other words, declara- -tion and types) and format requirements for the -instructions themselves. -In general, a programming language supports -such constructs as variables, data types, con- -stants, literals, assignment statements, control -statements, procedures, functions, and comments. -The syntax and semantics of each construct must -be clearly specified. - -_4.3. Low-Level Programming Languages_ - -Programming language can be classified into two -classes: low-level languages and high-level lan- -guages. Low-level languages can be understood -by a computer with no or minimal assistance and -typically include machine languages and assem- -bly languages. A machine language uses ones -and zeros to represent instructions and variables, -and is directly understandable by a computer. An -assembly language contains the same instructions -as a machine language but the instructions and -variables have symbolic names that are easier for -humans to remember. -Assembly languages cannot be directly under- -stood by a computer and must be translated into a -machine language by a utility program called an -_assembler._ There often exists a correspondence -between the instructions of an assembly language -and a machine language, and the translation from -assembly code to machine code is straightfor- -ward. For example, “add r1, r2, r3” is an assem- -bly instruction for adding the content of register -r2 and r3 and storing the sum into register r1. This -instruction can be easily translated into machine -code “0001 0001 0010 0011**.** ” (Assume the oper- -ation code for addition is 0001, see Figure 13.2). - -``` -add r1, r2, r3 -0001 0001 0010 0 011 -``` -``` -Figure 13.2. Assembly-to-Binary Translations -``` -One common trait shared by these two types -of language is their close association with the -specifics of a type of computer or instruction set -architecture (ISA). - -``` -4.4. High-Level Programming Languages -``` -``` -A high-level programming language has a strong -abstraction from the details of the computer’s -ISA. In comparison to low-level programming -languages, it often uses natural-language ele- -ments and is thus much easier for humans to -understand. Such languages allow symbolic nam- -ing of variables, provide expressiveness, and -enable abstraction of the underlying hardware. -For example, while each microprocessor has its -own ISA, code written in a high-level program- -ming language is usually portable between many -different hardware platforms. For these reasons, -most programmers use and most software are -written in high-level programming languages. -Examples of high-level programming languages -include C, C++, C#, and Java. -``` -``` -4.5. Declarative vs. Imperative Programming -Languages -``` -``` -Most programming languages (high-level or low- -level) allow programmers to specify the indi- -vidual instructions that a computer is to execute. -Such programming languages are called impera- -tive programming languages because one has to -specify every step clearly to the computer. But -some programming languages allow program- -mers to only describe the function to be per- -formed without specifying the exact instruction -sequences to be executed. Such programming -languages are called declarative programming -languages. Declarative languages are high-level -languages. The actual implementation of the -computation written in such a language is hidden -from the programmers and thus is not a concern -for them. -The key point to note is that declarative pro- -gramming only describes what the program -should accomplish without describing how to -accomplish it. For this reason, many people -believe declarative programming facilitates -easier software development. Declarative pro- -gramming languages include Lisp (also a func- -tional programming language) and Prolog, while -imperative programming languages include C, -C++, and JAVA. -``` - -**13-8** **_SWEBOK® Guide_** **V3.0** - -**5. Debugging Tools and Techniques** - [3*, c23] - -Once a program is coded and compiled (compila- -tion will be discussed in section 10), the next step -is debugging, which is a methodical process of -finding and reducing the number of bugs or faults -in a program. The purpose of debugging is to find -out why a program doesn’t work or produces a -wrong result or output. Except for very simple -programs, debugging is always necessary. - -_5.1. Types of Errors_ - -When a program does not work, it is often because -the program contains bugs or errors that can be -either syntactic errors, logical errors, or data errors. -Logical errors and data errors are also known as -two categories of “faults” in software engineering -terminology (see topic 1.1, Testing-Related Ter- -minology, in the Software Testing KA). -_Syntax errors_ are simply any error that pre- -vents the translator (compiler/interpreter) from -successfully parsing the statement. Every state- -ment in a program must be parse-able before its -meaning can be understood and interpreted (and, -therefore, executed). In high-level programming -languages, syntax errors are caught during the -compilation or translation from the high-level -language into machine code. For example, in the -C/C++ programming language, the statement -“123=constant;” contains a syntax error that will -be caught by the compiler during compilation. -_Logic errors_ are semantic errors that result in -incorrect computations or program behaviors. -Your program is legal, but wrong! So the results -do not match the problem statement or user expec- -tations. For example, in the C/C++ programming -language, the inline function “int f(int _x_ ) {return -f( _x_ -1);}” for computing factorial x! is legal but -logically incorrect. This type of error cannot be -caught by a compiler during compilation and is -often discovered through tracing the execution of -the program (Modern static checkers do identify -some of these errors. However, the point remains -that these are not machine checkable in general). -_Data errors_ are input errors that result either in -input data that is different from what the program -expects or in the processing of wrong data. - -``` -5.2. Debugging Techniques -``` -``` -Debugging involves many activities and can be -static, dynamic, or postmortem. Static debug- -ging usually takes the form of code review, while -dynamic debugging usually takes the form of -tracing and is closely associated with testing. -Postmortem debugging is the act of debugging -the core dump (memory dump) of a process. Core -dumps are often generated after a process has ter- -minated due to an unhandled exception. All three -techniques are used at various stages of program -development. -The main activity of dynamic debugging is -tracing, which is executing the program one piece -at a time, examining the contents of registers and -memory, in order to examine the results at each -step. There are three ways to trace a program. -``` -- _Single-stepping:_ execute one instruction at - a time to make sure each instruction is exe- - cuted correctly. This method is tedious but - useful in verifying each step of a program. -- _Breakpoints:_ tell the program to stop execut- - ing when it reaches a specific instruction. - This technique lets one quickly execute - selected code sequences to get a high-level - overview of the execution behavior. -- _Watch points:_ tell the program to stop when a - register or memory location changes or when - it equals to a specific value. This technique - is useful when one doesn’t know where or - when a value is changed and when this value - change likely causes the error. - -``` -5.3. Debugging Tools -``` -``` -Debugging can be complex, difficult, and tedious. -Like programming, debugging is also highly cre- -ative (sometimes more creative than program- -ming). Thus some help from tools is in order. For -dynamic debugging, debuggers are widely used -and enable the programmer to monitor the execu- -tion of a program, stop the execution, restart the -execution, set breakpoints, change values in mem- -ory, and even, in some cases, go back in time. -For static debugging, there are many static -code analysis tools , which look for a specific -set of known problems within the source code. -``` - -``` -Computing Foundations 13-9 -``` -Both commercial and free tools exist in various -languages. These tools can be extremely useful -when checking very large source trees, where it is -impractical to do code walkthroughs. The UNIX -_lint_ program is an early example. - -**6. Data Structure and Representation** - [5*, s2.1–2.6] - -Programs work on data. But data must be -expressed and organized within computers before -being processed by programs. This organization -and expression of data for programs’ use is the -subject of data structure and representation. Sim- -ply put, a data structure tries to store and organize -data in a computer in such a way that the data can -be used efficiently. There are many types of data -structures and each type of structure is suitable -for some kinds of applications. For example, B/ -B+ trees are well suited for implementing mas- -sive file systems and databases. - -_6.1. Data Structure Overview_ - -Data structures are computer representations of -data. Data structures are used in almost every pro- -gram. In a sense, no meaningful program can be -constructed without the use of some sort of data -structure. Some design methods and program- -ming languages even organize an entire software -system around data structures. Fundamentally, -data structures are abstractions defined on a col- -lection of data and its associated operations. -Often, data structures are designed for improv- -ing program or algorithm efficiency. Examples of -such data structures include stacks, queues, and -heaps. At other times, data structures are used for -conceptual unity (abstract data type), such as the -name and address of a person. Often, a data struc- -ture can determine whether a program runs in a -few seconds or in a few hours or even a few days. -From the perspective of physical and logi- -cal ordering, a data structure is either linear or -nonlinear. Other perspectives give rise to dif- -ferent classifications that include homogeneous -vs. heterogeneous, static vs. dynamic, persistent -vs. transient, external vs. internal, primitive vs. -aggregate, recursive vs. nonrecursive; passive vs. -active; and stateful vs. stateless structures. - -``` -6.2. Types of Data Structure -``` -``` -As mentioned above, different perspectives can -be used to classify data structures. However, the -predominant perspective used in classification -centers on physical and logical ordering between -data items. This classification divides data struc- -tures into linear and nonlinear structures. Linear -structures organize data items in a single dimen- -sion in which each data entry has one (physical -or logical) predecessor and one successor with -the exception of the first and last entry. The first -entry has no predecessor and the last entry has -no successor. Nonlinear structures organize data -items in two or more dimensions, in which case -one entry can have multiple predecessors and -successors. Examples of linear structures include -lists, stacks, and queues. Examples of nonlinear -structures include heaps, hash tables, and trees -(such as binary trees, balance trees, B-trees, and -so forth). -Another type of data structure that is often -encountered in programming is the compound -structure. A compound data structure builds on -top of other (more primitive) data structures and, -in some way, can be viewed as the same structure -as the underlying structure. Examples of com- -pound structures include sets, graphs, and parti- -tions. For example, a partition can be viewed as -a set of sets. -``` -``` -6.3. Operations on Data Structures -``` -``` -All data structures support some operations that -produce a specific structure and ordering, or -retrieve relevant data from the structure, store data -into the structure, or delete data from the structure. -Basic operations supported by all data structures -include create, read, update, and delete (CRUD). -``` -- Create: Insert a new data entry into the - structure. -- Read: Retrieve a data entry from the structure. -- Update: Modify an existing data entry. -- Delete: Remove a data entry from the - structure. - -``` -Some data structures also support additional -operations: -``` - -**13-10** **_SWEBOK® Guide_** **V3.0** - -- Find a particular element in the structure. -- Sort all elements according to some ordering. -- Traverse all elements in some specific order. -- Reorganize or rebalance the structure. - -Different structures support different opera- -tions with different efficiencies. The difference -between operation efficiency can be significant. -For example, it is easy to retrieve the last item -inserted into a stack, but finding a particular ele- -ment within a stack is rather slow and tedious. - -**7. Algorithms and Complexity** - [5*, s1.1–1.3, s3.3–3.6, s4.1–4.8, s5.1–5.7, - s6.1–6.3, s7.1–7.6, s11.1, s12.1] - -Programs are not random pieces of code: they are -meticulously written to perform user-expected -actions. The guide one uses to compose programs -are algorithms, which organize various functions -into a series of steps and take into consideration -the application domain, the solution strategy, and -the data structures being used. An algorithm can -be very simple or very complex. - -_7.1. Overview of Algorithms_ - -Abstractly speaking, algorithms guide the opera- -tions of computers and consist of a sequence of -actions composed to solve a problem. Alternative -definitions include but are not limited to: - -- An algorithm is any well-defined computa- - tional procedure that takes some value or set - of values as input and produces some value - or set of values as output. -- An algorithm is a sequence of computational - steps that transform the input into the output. -- An algorithm is a tool for solving a well- - specified computation problem. - -Of course, different definitions are favored -by different people. Though there is no univer- -sally accepted definition, some agreement exists -that an algorithm needs to be correct, finite (in -other words, terminate eventually or one must be -able to write it in a finite number of steps), and -unambiguous. - -``` -7.2. Attributes of Algorithms -``` -``` -The attributes of algorithms are many and often -include modularity, correctness, maintainabil- -ity, functionality, robustness, user-friendliness -(i.e. easy to be understood by people), program- -mer time, simplicity, and extensibility. A com- -monly emphasized attribute is “performance” -or “efficiency” by which we mean both time -and resource-usage efficiency while generally -emphasizing the time axis. To some degree, effi- -ciency determines if an algorithm is feasible or -impractical. For example, an algorithm that takes -one hundred years to terminate is virtually use- -less and is even considered incorrect. -``` -``` -7.3. Algorithmic Analysis -``` -``` -Analysis of algorithms is the theoretical study -of computer-program performance and resource -usage; to some extent it determines the goodness -of an algorithm. Such analysis usually abstracts -away the particular details of a specific computer -and focuses on the asymptotic, machine-indepen- -dent analysis. -There are three basic types of analysis. In -worst-case analysis, one determines the maxi- -mum time or resources required by the algorithm -on any input of size n. In average-case analysis, -one determines the expected time or resources -required by the algorithm over all inputs of size -n ; in performing average-case analysis, one often -needs to make assumptions on the statistical dis- -tribution of inputs. The third type of analysis is -the best-case analysis, in which one determines -the minimum time or resources required by the -algorithm on any input of size n. Among the -three types of analysis, average-case analysis is -the most relevant but also the most difficult to -perform. -Besides the basic analysis methods, there are -also the amortized analysis, in which one deter- -mines the maximum time required by an algo- -rithm over a sequence of operations; and the -competitive analysis, in which one determines -the relative performance merit of an algorithm -against the optimal algorithm (which may not -be known) in the same category (for the same -operations). -``` - -``` -Computing Foundations 13-11 -``` -_7.4. Algorithmic Design Strategies_ - -The design of algorithms generally follows one -of the following strategies: brute force, divide -and conquer, dynamic programming, and greedy -selection. The _brute force strategy_ is actually a -no-strategy. It exhaustively tries every possible -way to tackle a problem. If a problem has a solu- -tion, this strategy is guaranteed to find it; however, -the time expense may be too high. The _divide and -conquer strategy_ improves on the brute force -strategy by dividing a big problem into smaller, -homogeneous problems. It solves the big prob- -lem by recursively solving the smaller problems -and combing the solutions to the smaller prob- -lems to form the solution to the big problem. The -underlying assumption for divide and conquer is -that smaller problems are easier to solve. -The _dynamic programming strategy_ improves -on the divide and conquer strategy by recogniz- -ing that some of the sub-problems produced by -division may be the same and thus avoids solving -the same problems again and again. This elimina- -tion of redundant subproblems can dramatically -improve efficiency. -The _greedy selection strategy_ further improves -on dynamic programming by recognizing that -not all of the sub-problems contribute to the solu- -tion of the big problem. By eliminating all but -one sub-problem, the greedy selection strategy -achieves the highest efficiency among all algo- -rithm design strategies. Sometimes the use of -_randomization_ can improve on the greedy selec- -tion strategy by eliminating the complexity in -determining the greedy choice through coin flip- -ping or randomization. - -_7.5. Algorithmic Analysis Strategies_ - -The analysis strategies of algorithms include -_basic counting analysis,_ in which one actually -counts the number of steps an algorithm takes to -complete its task; _asymptotic analysis,_ in which -one only considers the order of magnitude of -the number of steps an algorithm takes to com- -plete its task; _probabilistic analysis,_ in which -one makes use of probabilities in analyzing the -average performance of an algorithm; _amor- -tized analysis,_ in which one uses the methods of - -``` -aggregation, potential, and accounting to ana- -lyze the worst performance of an algorithm on a -sequence of operations; and competitive analysis, -in which one uses methods such as potential and -accounting to analyze the relative performance of -an algorithm to the optimal algorithm. -For complex problems and algorithms, one -may need to use a combination of the aforemen- -tioned analysis strategies. -``` -**8. Basic Concept of a System** - [6*, c10] - -``` -Ian Sommerville writes, “a system is a purposeful -collection of interrelated components that work -together to achieve some objective” [6*]. A sys- -tem can be very simple and include only a few -components, like an ink pen, or rather complex, -like an aircraft. Depending on whether humans -are part of the system, systems can be divided -into technical computer-based systems and socio- -technical systems. A technical computer-based -system functions without human involvement, -such as televisions, mobile phones, thermostat, -and some software; a sociotechnical system -will not function without human involvement. -Examples of such system include manned space -vehicles, chips embedded inside a human, and so -forth. -``` -``` -8.1. Emergent System Properties -``` -``` -A system is more than simply the sum of its parts. -Thus, the properties of a system are not simply the -sum of the properties of its components. Instead, -a system often exhibits properties that are proper- -ties of the system as a whole. These properties are -called emergent properties because they develop -only after the integration of constituent parts in -the system. Emergent system properties can be -either functional or nonfunctional. Functional -properties describe the things that a system does. -For example, an aircraft’s functional properties -include flotation on air, carrying people or cargo, -and use as a weapon of mass destruction. Non- -functional properties describe how the system -behaves in its operational environment. These -can include such qualities as consistency, capac- -ity, weight, security, etc. -``` - -**13-12** **_SWEBOK® Guide_** **V3.0** - -_8.2. Systems Engineering_ - -“Systems engineering is the interdisciplinary -approach governing the total technical and mana- -gerial effort required to transform a set of cus- -tomer needs, expectations, and constraints into -a solution and to support that solution through- -out its life.” [7]. The life cycle stages of systems -engineering vary depending on the system being -built but, in general, include system requirements -definition, system design, sub-system develop- -ment, system integration, system testing, sys- -tem installation, system evolution, and system -decommissioning. -Many practical guidelines have been produced -in the past to aid people in performing the activi- -ties of each phase. For example, system design -can be broken into smaller tasks of identification -of subsystems, assignment of system require- -ments to subsystems, specification of subsystem -functionality, definition of sub-system interfaces, -and so forth. - -_8.3. Overview of a Computer System_ - -Among all the systems, one that is obviously rel- -evant to the software engineering community is -the computer system. A computer is a machine -that executes programs or software. It consists of -a purposeful collection of mechanical, electrical, - -``` -and electronic components with each component -performing a preset function. Jointly, these com- -ponents are able to execute the instructions that -are given by the program. -Abstractly speaking, a computer receives some -input, stores and manipulates some data, and -provides some output. The most distinct feature -of a computer is its ability to store and execute -sequences of instructions called programs. An -interesting phenomenon concerning the computer -is the universal equivalence in functionality. -According to Turing, all computers with a certain -minimum capability are equivalent in their abil- -ity to perform computation tasks. In other words, -given enough time and memory, all computers— -ranging from a netbook to a supercomputer—are -capable of computing exactly the same things, -irrespective of speed, size, cost, or anything else. -Most computer systems have a structure that -is known as the “von Neumann model,” which -consists of five components: a memory for storing -instructions and data, a central processing unit -for performing arithmetic and logical operations, -a control unit for sequencing and interpreting -instructions, input for getting external informa- -tion into the memory, and output for producing -results for the user. The basic components of a -computer system based on the von Neumann -model are depicted in Figure 13.3. -``` -``` -Figure 13.3. Basic Components of a Computer System Based on the von Neumann Model -``` - -``` -Computing Foundations 13-13 -``` -**9. Computer Organization** - [8*, c1–c4] - -From the perspective of a computer, a wide -semantic gap exists between its intended behav- -ior and the workings of the underlying electronic -devices that actually do the work within the com- -puter. This gap is bridged through computer orga- -nization, which meshes various electrical, elec- -tronic, and mechanical devices into one device -that forms a computer. The objects that computer -organization deals with are the devices, connec- -tions, and controls. The abstraction built in com- -puter organization is the computer. - -_9.1. Computer Organization Overview_ - -A computer generally consists of a CPU, mem- -ory, input devices, and output devices. Abstractly -speaking, the organization of a computer can be -divided into four levels (Figure 13.4). The _macro -architecture_ level is the formal specification of all -the functions a particular machine can carry out -and is known as the instruction set architecture -(ISA). The _micro architecture_ level is the imple- -mentation of the ISA in a specific CPU—in other -words, the way in which the ISA’s specifications -are actually carried out. The _logic circuits_ level -is the level where each functional component -of the micro architecture is built up of circuits -that make decisions based on simple rules. The -_devices_ level is the level where, finally, each logic -circuit is actually built of electronic devices such -as complementary metal-oxide semiconductors -(CMOS), n-channel metal oxide semiconductors -(NMOS), or gallium arsenide (GaAs) transistors, -and so forth. - -``` -Macro Architecture Level (ISA) -Micro Architecture Level -Logic Circuits Level -Devices Level -``` -``` -Figure 13.4. Machine Architecture Levels -``` -Each level provides an abstraction to the level -above and is dependent on the level below. To a -programmer, the most important abstraction is - -``` -the ISA, which specifies such things as the native -data types, instructions, registers, addressing -modes, the memory architecture, interrupt and -exception handling, and the I/Os. Overall, the -ISA specifies the ability of a computer and what -can be done on the computer with programming. -``` -``` -9.2. Digital Systems -``` -``` -At the lowest level, computations are carried out -by the electrical and electronic devices within a -computer. The computer uses circuits and mem- -ory to hold charges that represents the presence -or absence of voltage. The presence of voltage -is equal to a 1 while the absence of voltage is a -zero. On disk the polarity of the voltage is repre- -sented by 0s and 1s that in turn represents the data -stored. Everything—including instruction and -data—is expressed or encoded using digital zeros -and ones. In this sense, a computer becomes a -digital system. For example, decimal value 6 can -be encoded as 110, the addition instruction may -be encoded as 0001, and so forth. The component -of the computer such as the control unit, ALU, -memory and I/O use the information to compute -the instructions. -``` -``` -9.3. Digital Logic -``` -``` -Obviously, logics are needed to manipulate data -and to control the operation of computers. This -logic, which is behind a computer’s proper func- -tion, is called digital logic because it deals with -the operations of digital zeros and ones. Digital -logic specifies the rules both for building various -digital devices from the simplest elements (such -as transistors) and for governing the operation of -digital devices. For example, digital logic spells -out what the value will be if a zero and one is -ANDed, ORed, or exclusively ORed together. It -also specifies how to build decoders, multiplex- -ers (MUX), memory, and adders that are used to -assemble the computer. -``` -``` -9.4. Computer Expression of Data -``` -``` -As mentioned before, a computer expresses data -with electrical signals or digital zeros and ones. -Since there are only two different digits used in -``` - -**13-14** **_SWEBOK® Guide_** **V3.0** - -data expression, such a system is called a _binary -expression system_. Due to the inherent nature of -a binary system, the maximum numerical value -expressible by an n-bits binary code is 2n − 1. -Specifically, binary number _a_ n _a_ n−1... _a_ 1 _a_ 0 corre- -sponds to _a_ n × 2 n + _a_ n−1 × 2 n−1 + ... + _a_ 1 × 21 + -_a_ 0 × 20. Thus, the numerical value of the binary -expression of 1011 is 1 × 8 + 0 × 4 + 1 × 2 + 1 -× 1 = 11. To express a nonnumerical value, we -need to decide the number of zeros and ones to -use and the order in which those zeros and ones -are arranged. -Of course, there are different ways to do the -encoding, and this gives rise to different data -expression schemes and subschemes. For example, -integers can be expressed in the form of unsigned, -one’s complement, or two’s complement. For -characters, there are ASCII, Unicode, and IBM’s -EBCDIC standards. For floating point numbers, -there are IEEE-754 FP 1, 2, and 3 standards. - -_9.5. The Central Processing Unit (CPU)_ - -The central processing unit is the place where -instructions (or programs) are actually executed. -The execution usually takes several steps, includ- -ing fetching the program instruction, decoding -the instruction, fetching operands, performing -arithmetic and logical operations on the oper- -ands, and storing the result. The main compo- -nents of a CPU consist of registers where instruc- -tions and data are often read from and written to, -the arithmetic and logic unit (ALU) that performs -the actual arithmetic (such as addition, subtrac- -tion, multiplication, and division) and logic (such -as AND, OR, shift, and so forth) operations, the -control unit that is responsible for producing -proper signals to control the operations, and vari- -ous (data, address, and control) buses that link the -components together and transport data to and -from these components. - -_9.6. Memory System Organization_ - -Memory is the storage unit of a computer. It con- -cerns the assembling of a large-scale memory -system from smaller and single-digit storage -units. The main topics covered by memory sys- -tem architecture include the following: - -- Memory cells and chips -- Memory boards and modules -- Memory hierarchy and cache -- Memory as a subsystem of the computer. - -``` -Memory cells and chips deal with single-digital -storage and the assembling of single-digit units -into one-dimensional memory arrays as well -as the assembling of one-dimensional storage -arrays into multi-dimensional storage memory -chips. Memory boards and modules concern the -assembling of memory chips into memory sys- -tems, with the focus being on the organization, -operation, and management of the individual -chips in the system. Memory hierarchy and cache -are used to support efficient memory operations. -Memory as a sub-system deals with the interface -between the memory system and other parts of -the computer. -``` -``` -9.7. Input and Output (I/O) -``` -``` -A computer is useless without I/O. Common -input devices include the keyboard and mouse; -common output devices include the disk, the -screen, the printer, and speakers. Different I/O -devices operate at different data rates and reli- -abilities. How computers connect and manage -various input and output devices to facilitate the -interaction between computers and humans (or -other computers) is the focus of topics in I/O. -The main issues that must be resolved in input -and output are the ways I/O can and should be -performed. -In general, I/O is performed at both hard- -ware and software levels. Hardware I/O can be -performed in any of three ways. Dedicated I/O -dedicates the CPU to the actual input and output -operations during I/O; memory-mapped I/O treats -I/O operations as memory operations; and hybrid -I/O combines dedicated I/O and memory-mapped -I/O into a single holistic I/O operation mode. -Coincidentally, software I/O can also be per- -formed in one of three ways. Programmed I/O -lets the CPU wait while the I/O device is doing -I/O; interrupt-driven I/O lets the CPU’s handling -of I/O be driven by the I/O device; and direct -memory access ( DMA) lets I/O be handled by a -secondary CPU embedded in a DMA device (or -``` - -``` -Computing Foundations 13-15 -``` -channel). (Except during the initial setup, the -main CPU is not disturbed during a DMA I/O -operation.) -Regardless of the types of I/O scheme being -used, the main issues involved in I/O include _I/O -addressing_ (which deals with the issue of how to -identify the I/O device for a specific I/O opera- -tion), _synchronization_ (which deals with the issue -of how to make the CPU and I/O device work -in harmony during I/O), and _error detection and -correction_ (which deals with the occurrence of -transmission errors). - -**10. Compiler Basics** - [4*, s6.4] [8*, s8.4] - -_10.1. Compiler/Interpreter Overview_ - -Programmers usually write programs in high -level language code, which the CPU cannot exe- -cute; so this source code has to be converted into -machine code to be understood by a computer. -Due to the differences between different ISAs, -the translation must be done for each ISA or spe- -cific machine language under consideration. -The translation is usually performed by a piece -of software called a compiler or an interpreter_._ -This process of translation from a high-level lan- -guage to a machine language is called compila- -tion, or, sometimes, interpretation. - -_10.2. Interpretation and Compilation_ - -There are two ways to translate a program writ- -ten in a higher-level language into machine code: -interpretation and compilation. _Interpretation_ -translates the source code one statement at a time -into machine language, executes it on the spot, -and then goes back for another statement. Both -the high-level-language source code and the inter- -preter are required every time the program is run. -_Compilation_ translates the high-level-language -source code into an entire machine-language pro- -gram (an executable image) by a program called a -compiler. After compilation, only the executable -image is needed to run the program. Most appli- -cation software is sold in this form. -While both compilation and interpretation con- -vert high level language code into machine code, - -``` -there are some important differences between the -two methods. First, a compiler makes the conver- -sion just once, while an interpreter typically con- -verts it every time a program is executed. Second, -interpreting code is slower than running the com- -piled code, because the interpreter must analyze -each statement in the program when it is executed -and then perform the desired action, whereas the -compiled code just performs the action within -a fixed context determined by the compilation. -Third, access to variables is also slower in an -interpreter because the mapping of identifiers to -storage locations must be done repeatedly at run- -time rather than at compile time. -The primary tasks of a compiler may include -preprocessing, lexical analysis, parsing, semantic -analysis, code generation, and code optimiza- -tion. Program faults caused by incorrect compiler -behavior can be very difficult to track down. For -this reason, compiler implementers invest a lot of -time ensuring the correctness of their software. -``` -``` -10.3. The Compilation Process -``` -``` -Compilation is a complex task. Most compilers -divide the compilation process into many phases. -A typical breakdown is as follows: -``` -- Lexical Analysis -- Syntax Analysis or Parsing -- Semantic Analysis -- Code Generation - -``` -Lexical analysis partitions the input text (the -source code), which is a sequence of characters, -into separate comments , which are to be ignored -in subsequent actions, and basic symbols, which -have lexical meanings. These basic symbols -must correspond to some terminal symbols of -the grammar of the particular programming lan- -guage. Here terminal symbols refer to the ele- -mentary symbols (or tokens) in the grammar that -cannot be changed. -Syntax analysis is based on the results of the -lexical analysis and discovers the structure in the -program and determines whether or not a text -conforms to an expected format. Is this a textu- -ally correct C++ program? or Is this entry tex- -tually correct? are typical questions that can be -``` - -**13-16** **_SWEBOK® Guide_** **V3.0** - -answered by syntax analysis. Syntax analysis -determines if the source code of a program is cor- -rect and converts it into a more structured rep- -resentation (parse tree) for semantic analysis or -transformation. -_Semantic analysis_ adds semantic information -to the parse tree built during the syntax analysis -and builds the symbol table. It performs vari- -ous semantic checks that include type checking, -object binding (associating variable and function -references with their definitions), and definite -assignment (requiring all local variables to be -initialized before use). If mistakes are found, the -semantically incorrect program statements are -rejected and flagged as errors. -Once semantic analysis is complete, the phase -of _code generation_ begins and transforms the -intermediate code produced in the previous -phases into the native machine language of the -computer under consideration. This involves -resource and storage decisions—such as deciding -which variables to fit into registers and memory -and the selection and scheduling of appropriate -machine instructions, along with their associated -addressing modes. -It is often possible to combine multiple phases -into one pass over the code in a compiler imple- -mentation. Some compilers also have a prepro- -cessing phase at the beginning or after the lexical -analysis that does necessary housekeeping work, -such as processing the program instructions for -the compiler (directives). Some compilers pro- -vide an optional optimization phase at the end of -the entire compilation to optimize the code (such -as the rearrangement of instruction sequence) -for efficiency and other desirable objectives -requested by the users. - -**11. Operating Systems Basics** - [4*, c3] - -Every system of meaningful complexity needs -to be managed. A computer, as a rather complex -electrical-mechanical system, needs its own man- -ager for managing the resources and activities -occurring on it. That manager is called an _operat- -ing system_ (OS)_._ - -``` -11.1. Operating Systems Overview -``` -``` -Operating systems is a collection of software and -firmware, that controls the execution of computer -programs and provides such services as computer -resource allocation, job control, input/output con- -trol, and file management in a computer system. -Conceptually, an operating system is a computer -program that manages the hardware resources -and makes it easier to use by applications by pre- -senting nice abstractions. This nice abstraction -is often called the virtual machine and includes -such things as processes, virtual memory, and -file systems. An OS hides the complexity of the -underlying hardware and is found on all modern -computers. -The principal roles played by OSs are manage- -ment and illusion. Management refers to the OS’s -management (allocation and recovery) of physi- -cal resources among multiple competing users/ -applications/tasks. Illusion refers to the nice -abstractions the OS provides. -``` -``` -11.2. Tasks of an Operating System -``` -``` -The tasks of an operating system differ signifi- -cantly depending on the machine and time of its -invention. However, modern operating systems -have come to agreement as to the tasks that must -be performed by an OS. These tasks include CPU -management, memory management, disk man- -agement (file system), I/O device management, -and security and protection. Each OS task man- -ages one type of physical resource. -Specifically, CPU management deals with the -allocation and releases of the CPU among com- -peting programs (called processes/threads in OS -jargon), including the operating system itself. The -main abstraction provided by CPU management is -the process/thread model. Memory management -deals with the allocation and release of memory -space among competing processes, and the main -abstraction provided by memory management -is virtual memory. Disk management deals with -the sharing of magnetic or optical or solid state -disks among multiple programs/users and its main -abstraction is the file system. I/O device manage- -ment 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 -computer resources from illegal use. - -_11.3. Operating System Abstractions_ - -The arsenal of OSs is abstraction. Corresponding -to the five physical tasks, OSs use five abstrac- -tions: process/thread, virtual memory, file sys- -tems, input/output, and protection domains. The -overall OS abstraction is the virtual machine. -For each task area of OS, there is both a physi- -cal reality and a conceptual abstraction. The phys- -ical reality refers to the hardware resource under -management; the conceptual abstraction refers -to the interface the OS presents to the users/pro- -grams above. For example, in the thread model -of the OS, the physical reality is the CPU and the -abstraction is multiple CPUs. Thus, a user doesn’t -have to worry about sharing the CPU with others -when working on the abstraction provided by an -OS. In the virtual memory abstraction of an OS, -the physical reality is the physical RAM or ROM -(whatever), the abstraction is multiple unlim- -ited memory space. Thus, a user doesn’t have to -worry about sharing physical memory with others -or about limited physical memory size. -Abstractions may be virtual or transparent; -in this context virtual applies to something that -appears to be there, but isn’t (like usable memory -beyond physical), whereas transparent applies -to something that is there, but appears not to be -there (like fetching memory contents from disk or -physical memory). - -_11.4. Operating Systems Classification_ - -Different operating systems can have different -functionality implementation. In the early days -of the computer era, operating systems were rela- -tively simple. As time goes on, the complexity -and sophistication of operating systems increases -significantly. From a historical perspective, an -operating system can be classified as one of the -following. - -- _Batching OS:_ organizes and processes work - in batches. Examples of such OSs include - IBM’s FMS, IBSYS, and University of - Michigan’s UMES. - - _Multiprogrammed batching OS:_ adds mul- - titask capability into earlier simple batching - OSs. An example of such an OS is IBM’s - OS/360. - - _Time-sharing OS:_ adds multi-task and inter- - active capabilities into the OS. Examples of - such OSs include UNIX, Linux, and NT. - - _Real-time OS:_ adds timing predictabil- - ity into the OS by scheduling individual - tasks according to each task’s completion - deadlines. Examples of such OS include - VxWorks (WindRiver) and DART (EMC). - - _Distributed OS:_ adds the capability of man- - aging a network of computers into the OS. - - _Embedded OS:_ has limited functionality and - is used for embedded systems such as cars - and PDAs. Examples of such OSs include - Palm OS, Windows CE, and TOPPER. - -``` -Alternatively, an OS can be classified by its -applicable target machine/environment into the -following. -``` -- _Mainframe OS:_ runs on the mainframe com- - puters and include OS/360, OS/390, AS/400, - MVS, and VM. -- _Server OS:_ runs on workstations or servers - and includes such systems as UNIX, Win- - dows, Linux, and VMS. -- _Multicomputer OS:_ runs on multiple com- - puters and include such examples as Novell - Netware. -- _Personal computers OS:_ runs on personal - computers and include such examples as - DOS, Windows, Mac OS, and Linux. -- _Mobile device OS:_ runs on personal devices - such as cell phones, IPAD and include such - examples of iOS, Android, Symbian, etc. -**12. Database Basics and Data Management** -[4*, c9] - -``` -A database consists of an organized collection of -data for one or more uses. In a sense, a database is -a generalization and expansion of data structures. -But the difference is that a database is usually -external to individual programs and permanent in -existence compared to data structures. Databases -are used when the data volume is large or logical -``` - -**13-18** **_SWEBOK® Guide_** **V3.0** - -relations between data items are important. The -factors considered in database design include per- -formance, concurrency, integrity, and recovery -from hardware failures. - -_12.1. Entity and Schema_ - -The things a database tries to model and store are -called entities. Entities can be real-world objects -such as persons, cars, houses, and so forth, or they -may be abstract concepts such as persons, salary, -names, and so forth. An entity can be primitive -such as a name or composite such as an employee -that consists of a name, identification number, -salary, address, and so forth. -The single most important concept in a database -is the _schema_ , which is a description of the entire -database structure from which all other database -activities are built. A schema defines the relation- -ships between the various entities that compose a -database. For example, a schema for a company -payroll system would consist of such things as -employee ID, name, salary rate, address, and so -forth. Database software maintains the database -according to the schema. -Another important concept in database is the -_database model_ that describes the type of rela- -tionship among various entities. The commonly -used models include relational, network, and -object models. - -_12.2. Database Management Systems (DBMS)_ - -Database Management System (DBMS) compo- -nents include database applications for the stor- -age of structured and unstructured data and the -required database management functions needed -to view, collect, store, and retrieve data from the -databases. A DBMS controls the creation, main- -tenance, and use of the database and is usually -categorized according to the database model it -supports—such as the relational, network, or -object model. For example, a relational database -management system (RDBMS) implements fea- -tures of the relational model. An object database -management system (ODBMS) implements fea- -tures of the object model. - -``` -12.3. Database Query Language -``` -``` -Users/applications interact with a database -through a database query language, which is a spe- -cialized programming language tailored to data- -base use. The database model tends to determine -the query languages that are available to access -the database. One commonly used query lan- -guage for the relational database is the structured -query language, more commonly abbreviated as -SQL. A common query language for object data- -bases is the object query language (abbreviated as -OQL). There are three components of SQL: Data -Definition Language (DDL), Data Manipulation -Language (DML), and Data Control Language -(DCL). An example of an DML query may look -like the following: -``` -``` -SELECT Component_No, Quantity -FROM COMPONENT -WHERE Item_No = 100 -``` -``` -The above query selects all the Component_No -and its corresponding quantity from a database -table called COMPONENT, where the Item_No -equals to 100. -``` -``` -12.4. Tasks of DBMS Packages -``` -``` -A DBMS system provides the following -capabilities: -``` -- _Database development_ is used to define and - organize the content, relationships, and struc- - ture of the data needed to build a database. -- _Database interrogation_ is used for accessing - the data in a database for information retrieval - and report generation. End users can selec- - tively retrieve and display information and - produce printed reports. This is the operation - that most users know about databases. -- _Database Maintenance_ is used to add, delete, - update, and correct the data in a database. -- _Application Development_ is used to develop - prototypes of data entry screens, queries, - forms, reports, tables, and labels for a proto- - typed application. It also refers to the use of - 4th Generation Language or application gen- - erators to develop or generate program code. - - -``` -Computing Foundations 13-19 -``` -_12.5. Data Management_ - -A database must manage the data stored in it. -This management includes both organization and -storage. -The organization of the actual data in a database -depends on the database model. In a relational -model, data are organized as tables with different -tables representing different entities or relations -among a set of entities. The storage of data deals -with the storage of these database tables on disks. -The common ways for achieving this is to use files. -Sequential, indexed, and hash files are all used in -this purpose with different file structures providing -different access performance and convenience. - -_12.6. Data Mining_ - -One often has to know what to look for before -querying a database. This type of “pinpointing” -access does not make full use of the vast amount -of information stored in the database, and in fact -reduces the database into a collection of discrete -records. To take full advantage of a database, one -can perform statistical analysis and pattern dis- -covery on the content of a database using a tech- -nique called _data mining._ Such operations can be -used to support a number of business activities -that include, but are not limited to, marketing, -fraud detection, and trend analysis. -Numerous ways for performing data mining -have been invented in the past decade and include -such common techniques as class description, -class discrimination, cluster analysis, association -analysis, and outlier analysis. - -**13. Network Communication Basics** - [8*, c12] - -A computer network connects a collection of -computers and allows users of different comput- -ers to share resources with other users. A network -facilitates the communications between all the -connected computers and may give the illusion -of a single, omnipresent computer. Every com- -puter or device connected to a network is called -a _network node._ -A number of computing paradigms have emerged -to benefit from the functions and capabilities - -``` -provided by computer networks. These paradigms -include distributed computing, grid computing, -Internet computing, and cloud computing. -``` -``` -13.1. Types of Network -``` -``` -Computer networks are not all the same and -may be classified according to a wide variety of -characteristics, including the network’s connec- -tion method, wired technologies, wireless tech- -nologies, scale, network topology, functions, and -speed. But the classification that is familiar to -most is based on the scale of networking. -``` -- _Personal Area Network/Home Network_ is a - computer network used for communication - among computer(s) and different informa- - tion technological devices close to one per- - son. The devices connected to such a net- - work may include PCs, faxes, PDAs, and - TVs. This is the base on which the Internet - of Things is built. -- _Local Area Network_ (LAN) connects com- - puters and devices in a limited geographical - area, such as a school campus, computer lab- - oratory, office building, or closely positioned - group of buildings. -- _Campus Network_ is a computer network made - up of an interconnection of local area networks - (LANs) within a limited geographical area. -- _Wide area network_ (WAN) is a computer - network that covers a large geographic area, - such as a city or country or even across inter- - continental distances. A WAN limited to a - city is sometimes called a Metropolitan Area - Network. -- _Internet_ is the global network that connects - computers located in many (perhaps all) - countries. - -``` -Other classifications may divide networks into -control networks, storage networks, virtual pri- -vate networks (VPN), wireless networks, point- -to-point networks, and Internet of Things. -``` -``` -13.2. Basic Network Components -``` -``` -All networks are made up of the same basic hard- -ware components, including computers, network -``` - -**13-20** **_SWEBOK® Guide_** **V3.0** - -interface cards (NICs), bridges, hubs, switches, -and routers. All these components are called _nodes_ -in the jargon of networking. Each component per- -forms a distinctive function that is essential for -the packaging, connection, transmission, amplifi- -cation, controlling, unpacking, and interpretation -of the data. For example, a repeater amplifies the -signals, a switch performs many-to-many connec- -tions, a hub performs one-to-many connections, -an interface card is attached to the computer and -performs data packing and transmission, a bridge -connects one network with another, and a router is -a computer itself and performs data analysis and -flow control to regulate the data from the network. -The functions performed by various network -components correspond to the functions specified -by one or more levels of the seven-layer Open -Systems Interconnect (OSI) networking model, -which is discussed below. - -_13.3. Networking Protocols and Standards_ - -Computers communicate with each other using -protocols, which specify the format and regula- -tions used to pack and un-pack data. To facilitate -easier communication and better structure, net- -work protocols are divided into different layers -with each layer dealing with one aspect of the -communication. For example, the physical lay- -ers deal with the physical connection between -the parties that are to communicate, the data link -layer deals with the raw data transmission and -flow control, and the network layer deals with the -packing and un-packing of data into a particular -format that is understandable by the relevant par- -ties. The most commonly used OSI networking -model organizes network protocols into seven -layers, as depicted in Figure 13.5. -One thing to note is that not all network proto- -cols implement all layers of the OSI model. For -example, the TCP/IP protocol implements neither -the presentation layer nor the session layer. -There can be more than one protocol for each -layer. For example, UDP and TCP both work on -the transport layer above IP’s network layer, pro- -viding best-effort, unreliable transport (UDP) vs. -reliable transport function (TCP). Physical layer -protocols include token ring, Ethernet, fast Ether- -net, gigabit Ethernet, and wireless Ethernet. Data - -``` -link layer protocols include frame-relay, asyn- -chronous transfer mode (ATM), and Point-to- -Point Protocol (PPP). Application layer protocols -include Fibre channel, Small Computer System -Interface (SCSI), and Bluetooth. For each layer -or even each individual protocol, there may be -standards established by national or international -organizations to guide the design and develop- -ment of the corresponding protocols. -``` -``` -Application Layer -Presentation Layer -Session Layer -Transport Layer -Network Layer -Data link Layer -Physical Layer -``` -``` -Figure 13.5. The Seven-Layer OSI Networking Model -``` -``` -13.4. The Internet -``` -``` -The Internet is a global system of interconnected -governmental, academic, corporate, public, and -private computer networks. In the public domain -access to the internet is through organizations -known as internet service providers (ISP). The -ISP maintains one or more switching centers -called a point of presence, which actually con- -nects the users to the Internet. -``` -``` -13.5. Internet of Things -``` -``` -The Internet of Things refers to the networking -of everyday objects—such as cars, cell phones, -PDAs, TVs, refrigerators, and even buildings— -using wired or wireless networking technologies. -The function and purpose of Internet of Things -is to interconnect all things to facilitate autono- -mous and better living. Technologies used in the -Internet of Things include RFID, wireless and -wired networking, sensor technology, and much -software of course. As the paradigm of Internet -of Things is still taking shape, much work is -needed for Internet of Things to gain wide spread -acceptance. -``` - -``` -Computing Foundations 13-21 -``` -_13.6. Virtual Private Network (VPN)_ - -A virtual private network is a preplanned virtual -connection between nodes in a LAN/WAN or on -the internet. It allows the network administrator -to separate network traffic into user groups that -have a common affinity for each other such as -all users in the same organization, or workgroup. -This circuit type may improve performance -and security between nodes and allows for eas- -ier maintenance of circuits when troubleshooting. - -**14. Parallel and Distributed Computing** - [8*, c9] - -Parallel computing is a computing paradigm that -emerges with the development of multi-func- -tional units within a computer. The main objec- -tive of parallel computing is to execute several -tasks simultaneously on different functional units -and thus improve throughput or response or both. -Distributed computing, on the other hand, is a -computing paradigm that emerges with the devel- -opment of computer networks. Its main objective -is to either make use of multiple computers in the -network to accomplish things otherwise not pos- -sible within a single computer or improve com- -putation efficiency by harnessing the power of -multiple computers. - -_14.1. Parallel and Distributed Computing -Overview_ - -Traditionally, parallel computing investigates -ways to maximize concurrency (the simultaneous -execution of multiple tasks) within the bound- -ary of a computer. Distributed computing studies -distributed systems, which consists of multiple -_autonomous_ computers that communicate through -a computer network. Alternatively, distributed -computing can also refer to the use of distributed -systems to solve computational or transactional -problems. In the former definition, distributed -computing investigates the protocols, mecha- -nisms, and strategies that provide the foundation -for distributed computation; in the latter definition, -distributed computing studies the ways of dividing -a problem into many tasks and assigning such tasks -to various computers involved in the computation. - -``` -Fundamentally, distributed computing is -another form of parallel computing, albeit on a -grander scale. In distributed computing, the func- -tional units are not ALU, FPU, or separate cores, -but individual computers. For this reason, some -people regard distributed computing as being the -same as parallel computing. Because both distrib- -uted and parallel computing involve some form -of concurrency, they are both also called concur- -rent computing. -``` -``` -14.2. Difference between Parallel and Distrib- -uted Computing -``` -``` -Though parallel and distributed computing resem- -ble each other on the surface, there is a subtle but -real distinction between them: parallel comput- -ing does not necessarily refer to the execution of -programs on different computers— instead, they -can be run on different processors within a single -computer. In fact, consensus among computing -professionals limits the scope of parallel comput- -ing to the case where a shared memory is used by -all processors involved in the computing, while -distributed computing refers to computations -where private memory exists for each processor -involved in the computations. -Another subtle difference between parallel and -distributed computing is that parallel computing -necessitates concurrent execution of several tasks -while distributed computing does not have this -necessity. -Based on the above discussion, it is possible -to classify concurrent systems as being “parallel” -or “distributed” based on the existence or nonex- -istence of shared memory among all the proces- -sor: parallel computing deals with computations -within a single computer; distributed computing -deals with computations within a set of comput- -ers. According to this view, multicore computing -is a form of parallel computing. -``` -``` -14.3. Parallel and Distributed Computing -Models -``` -``` -Since multiple computers/processors/cores are -involved in distributed/parallel computing, some -coordination among the involved parties is nec- -essary to ensure correct behavior of the system. -``` - -**13-22** **_SWEBOK® Guide_** **V3.0** - -Different ways of coordination give rise to differ- -ent computing models. The most common mod- -els in this regard are the shared memory (paral- -lel) model and the message-passing (distributed) -model. -In a _shared memory (parallel)_ model, all com- -puters have access to a shared central memory -where local caches are used to speed up the -processing power. These caches use a protocol -to insure the localized data is fresh and up to -date, typically the MESI protocol. The algorithm -designer chooses the program for execution by -each computer. Access to the central memory can -be synchronous or asynchronous, and must be -coordinated such that coherency is maintained. -Different access models have been invented for -such a purpose. -In a _message-passing (distributed)_ model, all -computers run some programs that collectively -achieve some purpose. The system must work -correctly regardless of the structure of the net- -work. This model can be further classified into -client-server (C/S), browser-server (B/S), and -n-tier models. In the C/S model, the server pro- -vides services and the client requests services -from the server. In the B/S model, the server pro- -vides services and the client is the browser. In the -n-tier model, each tier (i.e. layer) provides ser- -vices to the tier immediately above it and requests -services from the tier immediately below it. In -fact, the n-tier model can be seen as a chain of -client-server models. Often, the tiers between the -bottommost tier and the topmost tier are called -_middleware,_ which is a distinct subject of study -in its own right. - -_14.4. Main Issues in Distributed Computing_ - -Coordination among all the components in a dis- -tributed computing environment is often complex -and time-consuming. As the number of cores/ -CPUs/computers increases, the complexity of -distributed computing also increases. Among -the many issues faced, memory coherency and -consensus among all computers are the most dif- -ficult ones. Many computation paradigms have -been invented to solve these problems and are -the main discussion issues in distributed/parallel -computing. - -**15. Basic User Human Factors** - [3*, c8] [9*, c5] - -``` -Software is developed to meet human desires or -needs. Thus, all software design and develop- -ment must take into consideration human-user -factors such as how people use software, how -people view software, and what humans expect -from software. There are numerous factors in the -human-machine interaction, and ISO 9241 docu- -ment series define all the detailed standards of -such interactions.[10] But the basic human-user -factors considered here include input/output, the -handling of error messages, and the robustness of -the software in general. -``` -``` -15.1. Input and Output -``` -``` -Input and output are the interfaces between users -and software. Software is useless without input -and output. Humans design software to process -some input and produce desirable output. All -software engineers must consider input and out- -put as an integral part of the software product -they engineer or develop. Issues considered for -input include (but are not limited to): -``` -- What input is required? -- How is the input passed from users to - computers? -- What is the most convenient way for users to - enter input? -- What format does the computer require of - the input data? - -``` -The designer should request the minimum -data from human input, only when the data is not -already stored in the system. The designer should -format and edit the data at the time of entry to -reduce errors arising from incorrect or malicious -data entry. -For output, we need to consider what the users -wish to see: -``` -- In what format would users like to see - output? -- What is the most pleasing way to display - output? - - -``` -Computing Foundations 13-23 -``` -If the party interacting with the software isn’t -human but another software or computer or con- -trol system, then we need to consider the input/ -output type and format that the software should -produce to ensure proper data exchange between -systems. -There are many rules of thumb for developers -to follow to produce good input/output for a soft- -ware. These rules of thumb include simple and -natural dialogue, speaking users’ language, mini- -mizing user memory load, consistency, minimal -surprise, conformance to standards (whether -agreed to or not: e.g., automobiles have a stan- -dard interface for accelerator, brake, steering). - -_15.2. Error Messages_ - -It is understandable that most software con- -tains faults and fails from time to time. But -users should be notified if there is anything that -impedes the smooth execution of the program. -Nothing is more frustrating than an unexpected -termination or behavioral deviation of software -without any warning or explanation. To be user -friendly, the software should report all error con- -ditions to the users or upper-level applications -so that some measure can be taken to rectify the -situation or to exit gracefully. There are several -guidelines that define what constitutes a good -error message: error messages should be clear, to -the point, and timely. -First, error messages should clearly explain -what is happening so that users know what is -going on in the software. Second, error mes- -sages should pinpoint the cause of the error, if at -all possible, so that proper actions can be taken. -Third, error messages should be displayed right -when the error condition occurs. According to -Jakob Nielsen, “Good error messages should be -expressed in plain language (no codes), precisely -indicate the problem, and constructively suggest -a solution” [9*]. Fourth, error messages should -not overload the users with too much informa- -tion and cause them to ignore the messages all -together. -However, messages relating to security access -errors should not provide extra information that -would help unauthorized persons break in. - -``` -15.3. Software Robustness -``` -``` -Software robustness refers to the ability of soft- -ware to tolerate erroneous inputs. Software is said -to be robust if it continues to function even when -erroneous inputs are given. Thus, it is unaccept- -able for software to simply crash when encoun- -tering an input problem as this may cause unex- -pected consequences, such as the loss of valuable -data. Software that exhibits such behavior is con- -sidered to lack robustness. -Nielsen gives a simpler description of software -robustness: “The software should have a low -error rate, so that users make few errors during -the use of the system and so that if they do make -errors they can easily recover from them. Further, -catastrophic errors must not occur” [9*]. -There are many ways to evaluate the robust- -ness of software and just as many ways to make -software more robust. For example, to improve -robustness, one should always check the validity -of the inputs and return values before progress- -ing further; one should always throw an excep- -tion when something unexpected occurs, and -one should never quit a program without first -giving users/applications a chance to correct the -condition. -``` -**16. Basic Developer Human Factors** - [3*, c31–32] - -``` -Developer human factors refer to the consider- -ations of human factors taken when developing -software. Software is developed by humans, read -by humans, and maintained by humans. If any- -thing is wrong, humans are responsible for cor- -recting those wrongs. Thus, it is essential to write -software in a way that is easily understandable -by humans or, at the very least, by other software -developers. A program that is easy to read and -understand exhibits readability. -The means to ensure that software meet this -objective are numerous and range from proper -architecture at the macro level to the particular -coding style and variable usage at the micro level. -But the two prominent factors are structure (or -program layouts) and comments (documentation). -``` - -**13-24** **_SWEBOK® Guide_** **V3.0** - -_16.1. Structure_ - -Well-structured programs are easier to understand -and modify. If a program is poorly structured, then -no amount of explanation or comments is sufficient -to make it understandable. The ways to organize a -program are numerous and range from the proper -use of white space, indentation, and parentheses to -nice arrangements of groupings, blank lines, and -braces. Whatever style one chooses, it should be -consistent across the entire program. - -_16.2. Comments_ - -To most people, programming is coding. These -people do not realize that programming also -includes writing comments and that comments are -an integral part of programming. True, comments -are not used by the computer and certainly do not -constitute final instructions for the computer, but -they improve the readability of the programs by -explaining the meaning and logic of the statements -or sections of code. It should be remembered that -programs are not only meant for computers, they -are also read, written, and modified by humans. -The types of comments include repeat of the -code, explanation of the code, marker of the -code, summary of the code, description of the -code’s intent, and information that cannot possi- -bly be expressed by the code itself. Some com- -ments are good, some are not. The good ones -are those that explain the intent of the code and -justify why this code looks the way it does. The -bad ones are repeat of the code and stating irrel- -evant information. The best comments are self- -documenting code. If the code is written in such a -clear and precise manner that its meaning is self- -proclaimed, then no comment is needed. But this -is easier said than done. Most programs are not -self-explanatory and are often hard to read and -understand if no comments are given. -Here are some general guidelines for writing -good comments: - -- Comments should be consistent across the - entire program. -- Each function should be associated with - comments that explain the purpose of the - function and its role in the overall program. - - Within a function, comments should be - given for each logical section of coding to - explain the meaning and purpose (intention) - of the section. - - Comments should stipulate what freedom - does (or does not) the maintaining program- - mers have with respect to making changes to - that code. - - Comments are seldom required for indi- - vidual statements. If a statement needs com- - ments, one should reconsider the statement. -**17. Secure Software Development and -Maintenance** -[11*, c29] - -``` -Due to increasing malicious activities targeted -at computer systems, security has become a sig- -nificant issue in the development of software. In -addition to the usual correctness and reliability, -software developers must also pay attention to -the security of the software they develop. Secure -software development builds security in software -by following a set of established and/or recom- -mended rules and practices in software develop- -ment. Secure software maintenance complements -secure software development by ensuring the no -security problems are introduced during software -maintenance. -A generally accepted view concerning software -security is that it is much better to design security -into software than to patch it in after software is -developed. To design security into software, one -must take into consideration every stage of the soft- -ware development lifecycle. In particular, secure -software development involves software require- -ments security , software design security , software -construction security, and software testing secu- -rity. In addition, security must also be taken into -consideration when performing software mainte- -nance as security faults and loopholes can be and -often are introduced during maintenance. -``` -``` -17.1. Software Requirements Security -``` -``` -Software requirements security deals with the -clarification and specification of security policy -and objectives into software requirements, which -``` - -``` -Computing Foundations 13-25 -``` -lays the foundation for security considerations in -the software development. Factors to consider -in this phase include software requirements and -threats/risks. The former refers to the specific -functions that are required for the sake of secu- -rity; the latter refers to the possible ways that the -security of software is threatened. - -_17.2. Software Design Security_ - -Software Design security deals with the design -of software modules that fit together to meet -the security objectives specified in the security -requirements. This step clarifies the details of -security considerations and develops the specific -steps for implementation. Factors considered -may include frameworks and access modes that -set up the overall security monitoring/enforce- -ment strategies, as well as the individual policy -enforcement mechanisms. - -_17.3. Software Construction Security_ - -Software construction security concerns the ques- -tion of how to write actual programming code for -specific situations such that security considerations -are taken care of. The term “Software Construction -Security” could mean different things for different -people. It can mean the way a specific function is -coded, such that the coding itself is secure, or it can -mean the coding of security into software. -Most people entangle the two together without -distinction. One reason for such entanglement is -that it is not clear how one can make sure that a -specific coding is secure. For example, in C pro- -gramming language, the expression of i<<1 (shift -the binary representation of i’s value to the left by -one bit) and 2*i (multiply the value of variable i -by constant 2) mean the same thing semantically, -but do they have the same security ramification? -The answer could be different for different com- -binations of ISAs and compilers. Due to this lack -of understanding, software construction secu- -rity—in its current state of existence—mostly -refers to the second aspect mentioned above: the -coding of security into software. -Coding of security into software can be -achieved by following recommended rules. A few -such rules follow: - -- Structure the process so that all sections - requiring extra privileges are modules. The - modules should be as small as possible and - should perform only those tasks that require - those privileges. -- Ensure that any assumptions in the program - are validated. If this is not possible, docu- - ment them for the installers and maintainers - so they know the assumptions that attackers - will try to invalidate. -- Ensure that the program does not share - objects in memory with any other program. -- The error status of every function must be - checked. Do not try to recover unless neither - the cause of the error nor its effects affect - any security considerations. The program - should restore the state of the software to - the state it had before the process began, and - then terminate. - -``` -17.4. Software Testing Security -``` -``` -Software testing security determines that soft- -ware protects data and maintains security speci- -fication as given. For more information, please -refer to the Software Testing KA. -``` -``` -17.5. Build Security into Software Engineering -Process -``` -``` -Software is only as secure as its development -process goes. To ensure the security of software, -security must be built into the software engineer- -ing process. One trend that emerges in this regard -is the Secure Development Lifecycle (SDL) con- -cept, which is a classical spiral model that takes -a holistic view of security from the perspective -of software lifecycle and ensures that security is -inherent in software design and development, not -an afterthought later in production. The SDL pro- -cess is claimed to reduce software maintenance -costs and increase reliability of software concern- -ing software security related faults. -``` -``` -17.6. Software Security Guidelines -``` -``` -Although there are no bulletproof ways for secure -software development, some general guidelines -do exist that can be used to aid such effort. These -``` - -**13-26** **_SWEBOK® Guide_** **V3.0** - -guidelines span every phase of the software -development lifecycle. Some reputable guide- -lines are published by the Computer Emergency -Response Team (CERT) and below are its top -10 software security practices (the details can be -found in [12]: - -1. Validate input. -2. Heed compiler warnings. -3. Architect and design for security policies. -4. Keep it simple. -5. Default deny. -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 - -``` -Voland 2003 -``` -##### [2*] - -``` -McConnell 2004 -``` -##### [3*] - -``` -Brookshear 2008 -``` -##### [4*] - -``` -Horowitz et al. 2007 -``` -##### [5*] - -``` -Sommerville 2011 -``` -##### [6*] - -``` -Null and Lobur 2006 -``` -##### [8*] - -``` -Nielsen 1993 -``` -##### [9*] - -``` -Bishop 2002 -``` -##### [11*] - -**1. Problem Solving -Te c h n i que s** - -``` -s3.2, -s4.2 -1.1. Definition of -Problem Solving -s3.2 -``` -``` -1.2. Formulating the -Real Problem -s3.2 -``` -``` -1.3. Analyze the -Problem -s3.2 -``` -``` -1.4. Design a -Solution Search -Strategy -``` -``` -s4.2 -``` -``` -1.5. Problem Solving -Using Programs -c5 -``` -**2. Abstraction** - s5.2– - 5.4 -2.1. Levels of -Abstraction - -``` -s5.2– -5.3 -2.2. Encapsulation s5.3 -2.3. Hierarchy s5.2 -``` -**3. Programming -Fundamentals** - c6–19 - -``` -3.1. The -Programming -Process -``` -``` -c6–c19 -``` -``` -3.2. Programming -Paradigms -c6–c19 -``` -``` -3.3. Defensive -Programming -c8 -``` -**4. Programming -Language Basics** - c6 - -``` -4.1. Programming -Language Overview -s6.1 -``` -``` -4.2. Syntax and -Semantics of -Programming -Language -``` -``` -s6.2 -``` - -**13-28** **_SWEBOK® Guide_** **V3.0** - -``` -Voland 2003 -``` -##### [2*] - -``` -McConnell 2004 -``` -##### [3*] - -``` -Brookshear 2008 -``` -##### [4*] - -``` -Horowitz et al. 2007 -``` -##### [5*] - -``` -Sommerville 2011 -``` -##### [6*] - -``` -Null and Lobur 2006 -``` -##### [8*] - -``` -Nielsen 1993 -``` -##### [9*] - -``` -Bishop 2002 -``` -##### [11*] - -``` -4.3. Low Level -Programming -Language -``` -``` -s6.5– -6.7 -``` -``` -4.4. High Level -Programing -Language -``` -``` -s6.5– -6.7 -``` -``` -4.5. Declarative -vs. Imperative -Programming -Language -``` -``` -s6.5– -6.7 -``` -**5. Debugging Tools -and Techniques** - c23 - -``` -5.1. Types of Errors s23.1 -5.2. Debugging -Techniques: -s23.2 -``` -``` -5.3. Debugging -To ol s -s23.5 -``` -**6. Data Structure and -Representation** - -``` -s2.1– -2.6 -6.1. Data Structure -Overview -``` -``` -s2.1– -2.6 -6.2. Types of Data -Structure -``` -``` -s2.1– -2.6 -6.3. Operations on -Data Structures -``` -``` -s2.1– -2.6 -``` -**7. Algorithms and -Complexity** - -``` -s1.1– -1.3, -s3.3– -3.6, -s4.1– -4.8, -s5.1– -5.7, -s6.1– -6.3, -s7.1– -7.6, -s11.1, -s12.1 -``` - -``` -Computing Foundations 13-29 -``` -``` -Voland 2003 -``` -##### [2*] - -``` -McConnell 2004 -``` -##### [3*] - -``` -Brookshear 2008 -``` -##### [4*] - -``` -Horowitz et al. 2007 -``` -##### [5*] - -``` -Sommerville 2011 -``` -##### [6*] - -``` -Null and Lobur 2006 -``` -##### [8*] - -``` -Nielsen 1993 -``` -##### [9*] - -``` -Bishop 2002 -``` -##### [11*] - -``` -7.1. Overview of -Algorithms -s1.1–1.2 -``` -``` -7.2. Attributes of -Algorithms -s1.3 -``` -``` -7.3. Algorithmic -Analysis -s1.3 -``` -``` -7.4. Algorithmic -Design Strategies -``` -``` -s3.3– -3.6, -s4.1– -4.8, -s5.1– -5.7, -s6.1– -6.3, -s7.1– -7.6, -s11.1, -s12.1 -``` -``` -7.5. Algorithmic -Analysis Strategies -``` -``` -s3.3– -3.6, -s4.1– -4.8, -s5.1– -5.7, -s6.1– -6.3, -s7.1– -7.6, -s11.1, -s12.1 -``` -**8. Basic Concept of a -System** - c10 - -``` -8.1. Emergent -System Properties -s10.1 -``` -``` -8.2. System -Engineering -s10.2 -``` -``` -8.3. Overview of a -Computer System -``` - -**13-30** **_SWEBOK® Guide_** **V3.0** - -``` -Voland 2003 -``` -##### [2*] - -``` -McConnell 2004 -``` -##### [3*] - -``` -Brookshear 2008 -``` -##### [4*] - -``` -Horowitz et al. 2007 -``` -##### [5*] - -``` -Sommerville 2011 -``` -##### [6*] - -``` -Null and Lobur 2006 -``` -##### [8*] - -``` -Nielsen 1993 -``` -##### [9*] - -``` -Bishop 2002 -``` -##### [11*] - -**9. Computer -Organization** - c1–4 - -``` -9.1. Computer -Organization -Overview -``` -``` -s1.1–1.2 -``` -``` -9.2. Digital Systems c3 -9.3. Digital Logic c3 -9.4. Computer -Expression of Data -c2 -``` -``` -9.5. The Central -Processing Unit -(CPU) -``` -``` -s4.1– -4.2 -``` -``` -9.6. Memory System -Organization -s4.6 -``` -``` -9.7. Input and Output -(I/O) -s4.5 -``` -**10. Compiler Basics** s6.4 s8.4 - 10.1. Compiler - Overview - s8.4 - -``` -10.2. Interpretation -and Compilation -s8.4 -``` -``` -10.3. The -Compilation Process -s6.4 s8.4 -``` -**11. Operating -Systems Basics** - c3 - -``` -11.1. Operating -Systems Overview -s3.2 -``` -11. 2. Ta sk s of -Operating System - s3.3 - -``` -11.3. Operating -System Abstractions -s3.2 -``` -``` -11.4. Operating -Systems -Classification -``` -``` -s3.1 -``` - -``` -Computing Foundations 13-31 -``` -``` -Voland 2003 -``` -##### [2*] - -``` -McConnell 2004 -``` -##### [3*] - -``` -Brookshear 2008 -``` -##### [4*] - -``` -Horowitz et al. 2007 -``` -##### [5*] - -``` -Sommerville 2011 -``` -##### [6*] - -``` -Null and Lobur 2006 -``` -##### [8*] - -``` -Nielsen 1993 -``` -##### [9*] - -``` -Bishop 2002 -``` -##### [11*] - -**12. Database -Basics and Data -Management** - -``` -c9 -``` -``` -12.1. Entity and -Schema -s9.1 -``` -``` -12.2. Database -Management -Systems (DBMS) -``` -``` -s9.1 -``` -``` -12.3. Database -Query Language -s9.2 -``` -``` -12.4. Ta sk s of -DBMS Packages -s9.2 -``` -``` -12.5. Data -Management -s9.5 -``` -``` -12.6. Data Mining s9.6 -``` -**13. Network -Communication -Basics** - -``` -c12 -``` -``` -13.1. Ty p e s of -Network -``` -``` -s12.2– -12.3 -13.2. Basic Network -Components -s12.6 -``` -``` -13.3. Networking -Protocols and -Standards -``` -``` -s12.4– -12.5 -``` -``` -13.4. The Internet -13.5. Internet of -Things -s12.8 -``` -``` -13.6. Virtual Private -Network -``` -**14. Parallel and -Distributed -Computing** - -``` -c9 -``` -``` -14.1. Parallel -and Distributed -Computing -Overview -``` -``` -s9.4.1– -9.4.3 -``` - -**13-32** **_SWEBOK® Guide_** **V3.0** - -``` -Voland 2003 -``` -##### [2*] - -``` -McConnell 2004 -``` -##### [3*] - -``` -Brookshear 2008 -``` -##### [4*] - -``` -Horowitz et al. 2007 -``` -##### [5*] - -``` -Sommerville 2011 -``` -##### [6*] - -``` -Null and Lobur 2006 -``` -##### [8*] - -``` -Nielsen 1993 -``` -##### [9*] - -``` -Bishop 2002 -``` -##### [11*] - -``` -14.2. Differences -between Parallel -and Distributed -Computing -``` -``` -s9.4.4– -9.4.5 -``` -``` -14.3. Parallel -and Distributed -Computing Models -``` -``` -s9.4.4– -9.4.5 -``` -``` -14.4. Main Issues -in Distributed -Computing -``` -**15. Basic User -Human Factors** - c8 c5 - -``` -15.1. Input and -Output -``` -``` -s5.1, -s5.3 -``` -``` -15.2. Error Messages -s5.2, -s5.8 -15.3. Software -Robustness -``` -``` -s5.5– -5.6 -``` -**16. Basic Developer -Human Factors** - c31–32 - -``` -16.1. Structure c31 -16.2. Comments c32 -``` -**17. Secure Software -Development and -Maintenance** - -``` -c29 -``` -``` -17.1. Two Aspects of -Secure Coding -s29.1 -``` -``` -17.2. Coding -Security into -Software -``` -``` -s29.4 -``` -``` -17.3. Requirement -Security -s29.2 -``` -``` -17.4. Design -Security -s29.3 -``` -``` -17.5. Implementation -Security -s29.5 -``` - -``` -Computing Foundations 13-33 -``` -##### REFERENCES - -[1] Joint Task Force on Computing Curricula, -IEEE Computer Society and Association -for Computing Machinery, _Software -Engineering 2004: Curriculum Guidelines -for Undergraduate Degree Programs in -Software Engineering_ , 2004; [http://sites.](http://sites.) -computer.org/ccse/SE2004Volume.pdf. - -[2*] G. Voland, _Engineering by Design_ , 2nd ed., -Prentice Hall, 2003. - -[3*] S. McConnell, _Code Complete_ , 2nd ed., -Microsoft Press, 2004. - -[4*] J.G. Brookshear, _Computer Science: An -Overview_ , 10th ed., Addison-Wesley, 2008. - -[5*] E. Horowitz et al., _Computer Algorithms_ , -2nd ed., Silicon Press, 2007. - -[6*] I. Sommerville, _Software Engineering_ , 9th -ed., Addison-Wesley, 2011. - -``` -[7] ISO/IEC/IEEE 24765:2010 Systems and -Software Engineering—Vocabulary , ISO/ -IEC/IEEE, 2010. -``` -``` -[8*] L. Null and J. Lobur, The Essentials of -Computer Organization and Architecture , -2nd ed., Jones and Bartlett Publishers, -2006. -``` -``` -[9*] J. Nielsen, Usability Engineering , Morgan -Kaufmann, 1993. -``` -``` -[10] ISO 9241-420:2011 Ergonomics of Human- -System Interaction, ISO, 2011. -``` -``` -[11*] M. Bishop, Computer Security: Art and -Science , Addison-Wesley, 2002. -``` -``` -[12] R.C. Seacord, The CERT C Secure Coding -Standard , Addison-Wesley Professional, -2008. -``` blob - fd2b319528d24c38e8e19aab2f0c03139434e149 (mode 644) blob + /dev/null --- 14_mathematical_foundations.markdown +++ /dev/null @@ -1,1954 +0,0 @@ -``` -14-1 -``` -**CHAPTER 14** - -**MATHEMATICAL FOUNDATIONS** - -##### INTRODUCTION - -Software professionals live with programs. In a -very simple language, one can program only for -something that follows a well-understood, non- -ambiguous logic. The Mathematical Foundations -knowledge area (KA) helps software engineers -comprehend this logic, which in turn is translated -into programming language code. The mathemat- -ics that is the primary focus in this KA is quite -different from typical arithmetic, where numbers -are dealt with and discussed. Logic and reason- -ing are the essence of mathematics that a software -engineer must address. -Mathematics, in a sense, is the study of formal -systems. The word “formal” is associated with -preciseness, so there cannot be any ambiguous or -erroneous interpretation of the fact. Mathemat- -ics is therefore the study of any and all certain -truths about any concept. This concept can be -about numbers as well as about symbols, images, -sounds, video—almost anything. In short, not -only numbers and numeric equations are sub- -ject to preciseness. On the contrary, a software -engineer needs to have a precise abstraction on a -diverse application domain. -The _SWEBOK Guide_ ’s Mathematical Founda- -tions KA covers basic techniques to identify a set -of rules for reasoning in the context of the system -under study. Anything that one can deduce fol- -lowing these rules is an absolute certainty within -the context of that system. In this KA, techniques -that can represent and take forward the reasoning -and judgment of a software engineer in a precise -(and therefore mathematical) manner are defined -and discussed. The language and methods of logic -that are discussed here allow us to describe math- -ematical proofs to infer conclusively the absolute -truth of certain concepts beyond the numbers. In - -``` -short, you can write a program for a problem only -if it follows some logic. The objective of this KA -is to help you develop the skill to identify and -describe such logic. The emphasis is on helping -you understand the basic concepts rather than on -challenging your arithmetic abilities. -``` -``` -BREAKDOWN OF TOPICS FOR -MATHEMATICAL FOUNDATIONS -``` -``` -The breakdown of topics for the Mathematical -Foundations KA is shown in Figure 14.1. -``` -**1. Set, Relations, Functions** - [1*, c2] - -``` -Set. A set is a collection of objects, called elements -of the set. A set can be represented by listing its -elements between braces, e.g., S = {1, 2, 3}. -The symbol ∈ is used to express that an ele- -ment belongs to a set, or—in other words—is a -member of the set. Its negation is represented by -∉, e.g., 1 ∈ S, but 4 ∉ S. -In a more compact representation of set using -set builder notation, {x | P(x)} is the set of all x -such that P(x) for any proposition P(x) over any -universe of discourse. Examples for some impor- -tant sets include the following: -``` -``` -N = {0, 1, 2, 3, ...} = the set of nonnegative -integers. -Z = {..., −3, −2, −1, 0, 1, 2, 3, ...} = the set of -integers. -``` -``` -Finite and Infinite Set. A set with a finite num- -ber of elements is called a finite set. Conversely, -any set that does not have a finite number of ele- -ments in it is an infinite set. The set of all natural -numbers, for example, is an infinite set. -``` - -**14-2** **_SWEBOK® Guide_** **V3.0** - -_Cardinality._ The cardinality of a finite set S is -the number of elements in S. This is represented -|S|, e.g., if S = {1, 2, 3}, then |S| = 3. -_Universal Set._ In general S = {x ∈ U | p(x)}, -where U is the universe of discourse in which -the predicate P(x) must be interpreted. The “uni- -verse of discourse” for a given predicate is often -referred to as the universal set. Alternately, one -may define universal set as the set of all elements. -_Set Equality._ Two sets are equal if and only if -they have the same elements, i.e.: - -``` -X = Y ≡ ∀p (p ∈ X ↔ p ∈ Y). -``` -_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). -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. -If X is not a proper subset of Y, it is denoted -as X ⊄ Y. - -_Superset._ If X is a subset of Y, then Y is called -a _superset_ of X. This is denoted by Y ⊇ X, i.e., Y -⊇ X if and only if X ⊆ Y. -For example, if X = {1, 2, 3} and Y = {1, 2, 3, -4, 5}, then Y ⊇ X. - -``` -Empty Set. A set with no elements is called an -empty set. An empty set, denoted by ∅, is also -referred to as a null or void set. -Power Set. The set of all subsets of a set X is -called the power set of X. It is represented as -℘(X). -For example, if X = {a, b, c}, then ℘(X) = {∅, -{a}, {b}, {c}, {a, b}, {a, c}, {b, c}, {a, b, c}}. If -|X| = n, then |℘(X)| = 2n. -Venn Diagrams. Venn diagrams are graphic rep- -resentations of sets as enclosed areas in the plane. -For example, in Figure 14.2, the rectangle rep- -resents the universal set and the shaded region -represents a set X. -``` -``` -Figure 14.2. Venn Diagram for Set X -``` -``` -1.1. Set Operations -``` -``` -Intersection. The intersection of two sets X and -Y, denoted by X ∩ Y, is the set of common ele- -ments in both X and Y. -In other words, X ∩ Y = {p | (p ∈ X) ∧ (p ∈ Y)}. -As, for example, {1, 2, 3} ∩ {3, 4, 6} = {3} -If X ∩ Y = f, then the two sets X and Y are said -to be a disjoint pair of sets. -``` -``` -Figure 14.1. Breakdown of Topics for the Mathematical Foundations KA -``` - -``` -Mathematical Foundations 14-3 -``` -A Venn diagram for set intersection is shown in -Figure 14.3. The common portion of the two sets -represents the set intersection. - -``` -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.4. Union of Sets X and Y -``` -It may be noted that |X ∪ Y| = |X| + |Y| − |X -∩ Y|. -A Venn diagram illustrating the union of two -sets is represented by the shaded region in Figure -14.4. -_Complement._ The set of elements in the univer- -sal set that do not belong to a given set X is called -its complement set X'. -In other words, X' ={p | (p ∈ U) ∧ (p ∉ X)}. - -``` -Figure 14.5. Venn Diagram for Complement Set of X -``` -``` -The shaded portion of the Venn diagram in Fig- -ure 14.5 represents the complement set of X. -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 rep- -resented 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.6. Venn Diagram for X − Y -``` -``` -Cartesian Product. An ordinary pair {p, q} is -a set with two elements. In a set, the order of the -elements is irrelevant, so {p, q} = {q, p}. -In an ordered pair (p, q), the order of occur- -rences of the elements is relevant. Thus, (p, q) ≠ -(q, p) unless p = q. In general (p, q) = (s, t) if and -only if p = s and q = t. -Given two sets X and Y, their Cartesian product -X × Y is the set of all ordered pairs (p, q) such that -p ∈ X and q ∈ Y. -In other words, X × Y = {(p, q) | (p ∈ X) ∧ (q -∈ 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 - X ∩ (Y ∩ Z) = (X ∩ Y) ∩ Z - - -**14-4** **_SWEBOK® Guide_** **V3.0** - -2. Commutative Laws: - X ∪ Y = Y ∪ X X ∩ Y = Y ∩ X -3. Distributive Laws: - X ∪ (Y ∩ Z) = (X ∪ Y) ∩ (X ∪ Z) - X ∩ (Y ∪ Z) = (X ∩ Y) ∪ (X ∩ Z) -4. Identity Laws: - X ∪ ∅ = X X ∩ U = X -5. Complement Laws: - X ∪ X' = U X ∩ X' = ∅ -6. Idempotent Laws: - X ∪ X = X X ∩ X = X -7. Bound Laws: - X ∪ U = U X ∩ ∅ = ∅ -8. Absorption Laws: - X ∪ (X ∩ Y) = X X ∩ (X ∪ Y) = X -9. De Morgan’s Laws: - (X ∪ Y)' = X' ∩ Y' (X ∩ Y)' = X' ∪ Y' - -_1.3. Relation and Function_ - -A relation is an association between two sets of -information. For example, let’s consider a set -of residents of a city and their phone numbers. -The pairing of names with corresponding phone -numbers is a relation. This pairing is _ordered_ for -the entire relation. In the example being consid- -ered, 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 rela- -tion R(X, Y) is well behaved if the function maps -every element of the domain set X to a single ele- -ment of the range set Y. Let’s consider domain set -X as a set of persons and let range set Y store their -phone numbers. Assuming that a person may have -more than one phone number, the relation being -considered is not a function. However, if we draw -a relation between names of residents and their -date of births with the name set as domain, then - -``` -this becomes a well-behaved relation and hence a -function. This means that, while all functions are -relations, not all relations are functions. In case -of a function given an x, one gets one and exactly -one y for each ordered pair ( x , y ). -For example, let’s consider the following two -relations. -``` -``` -A: {(3, –9), (5, 8), (7, –6), (3, 9), (6, 3)}. -B: {(5, 8), (7, 8), (3, 8), (6, 8)}. -``` -``` -Are these functions as well? -In case of relation A, the domain is all the -x-values, i.e., {3, 5, 6, 7}, and the range is all the -y-values, i.e., {–9, –6, 3, 8, 9}. -Relation A is not a function, as there are two -different range values, –9 and 9, for the same -x-value of 3. -In case of relation B, the domain is same as that -for A, i.e., {3, 5, 6, 7}. However, the range is a -single element {8}. This qualifies as an example -of a function even if all the x-values are mapped -to the same y-value. Here, each x-value is distinct -and hence the function is well behaved. Relation -B may be represented by the equation y = 8. -The characteristic of a function may be verified -using a vertical line test, which is stated below: -Given the graph of a relation, if one can draw -a vertical line that crosses the graph in more than -one place, then the relation is not a function. -``` -``` -Figure 14.7. Vertical Line Test for Function -``` -``` -In this example, both lines L1 and L2 cut the -graph for the relation thrice. This signifies that -for the same x-value, there are three different -y-values for each of case. Thus, the relation is not -a function. -``` - -``` -Mathematical Foundations 14-5 -``` -**2. Basic Logic** - [1*, c1] - -_2.1. Propositional Logic_ - -A proposition is a statement that is either true -or false, but not both. Let’s consider declarative -sentences for which it is meaningful to assign -either of the two status values: _true_ or _false_. Some -examples of propositions are given below. - -1. The sun is a star -2. Elephants are mammals. -3. 2 + 3 = 5. - -However, a + 3 = b is not a proposition, as it is -neither true nor false. It depends on the values of -the variables _a_ and _b_. -_The Law of Excluded Middle:_ For every propo- -sition p, either p is true or p is false. -_The Law of Contradiction:_ For every proposi- -tion p, it is not the case that p is both true and false. -Propositional logic is the area of logic that -deals with propositions. A truth table displays -the relationships between the truth values of -propositions. -A Boolean variable is one whose value is either -true or false. Computer bit operations correspond -to logical operations of Boolean variables. -The basic logical operators including negation -(¬ p), conjunction (p ∧ q), disjunction (p ∨ q), -exclusive or (p ⊕ q), and implication (p → q) are -to be studied. Compound propositions may be -formed using various logical operators. -A compound proposition that is always true is a -tautology. A compound proposition that is always -false is a contradiction. A compound proposition -that is neither a tautology nor a contradiction is a -contingency. -Compound propositions that always have the -same truth value are called logically equivalent -(denoted by ≡). Some of the common equiva- -lences are: - -Identity laws: -p ∧ T ≡ p p ∨ F ≡ p - -Domination laws: -p ∨ T ≡ T p ∧ F ≡ F - -``` -Idempotent laws: -p ∨ p ≡ p p ∧ p ≡ p -``` -``` -Double negation law: -¬ (¬ p) ≡ p -``` -``` -Commutative laws: -p ∨ q ≡ q ∨ p p ∧ q ≡ q ∧ p -``` -``` -Associative laws: -(p ∨ q) ∨ r ≡ p ∨ (q ∨ r) -(p ∧ q) ∧ r ≡ p ∧ (q ∧ r) -``` -``` -Distributive laws: -p ∨ (q ∧ r) ≡ (p ∨ q) ∧ (p ∨ r) -p ∧ (q ∨ r) ≡ (p ∧ q) ∨ (p ∧ r) -``` -``` -De Morgan’s laws: -¬ (p ∧ q) ≡ ¬ p ∨ ¬ q ¬ (p ∨ q) ≡ ¬ p ∧ ¬ q -``` -``` -2.2. Predicate Logic -``` -``` -A predicate is a verb phrase template that -describes a property of objects or a relationship -among objects represented by the variables. For -example, in the sentence, The flower is red, the -template is red is a predicate. It describes the -property of a flower. The same predicate may be -used in other sentences too. -Predicates are often given a name, e.g., “Red” -or simply “R” can be used to represent the predi- -cate is red. Assuming R as the name for the predi- -cate is red , sentences that assert an object is of the -color red can be represented as R(x) , where x rep- -resents an arbitrary object. R(x) reads as x is red. -Quantifiers allow statements about entire col- -lections of objects rather than having to enumer- -ate the objects by name. -The Universal quantifier ∀x asserts that a sen- -tence is true for all values of variable x. -For example, ∀x Tiger(x) → Mammal(x) -means all tigers are mammals. -The Existential quantifier ∃x asserts that a sen- -tence is true for at least one value of variable x. -For example, ∃x Tiger(x) → Man-eater(x) means -there exists at least one tiger that is a man-eater. -Thus, while universal quantification uses -implication, the existential quantification natu- -rally uses conjunction. -``` - -**14-6** **_SWEBOK® Guide_** **V3.0** - -A variable _x_ that is introduced into a logical -expression by a quantifier is bound to the closest -enclosing quantifier. -A variable is said to be a free variable if it is not -bound to a quantifier. -Similarly, in a block-structured programming -language, a variable in a logical expression refers -to the closest quantifier within whose scope it -appears. -For example, in ∃x (Cat(x) ∧ ∀x (Black(x))), x -in Black(x) is universally quantified. The expres- -sion implies that cats exist and everything is -black. -Propositional logic falls short in representing -many assertions that are used in computer sci- -ence and mathematics. It also fails to compare -equivalence and some other types of relationship -between propositions. -For example, the assertion _a is greater than -1_ is not a proposition because one cannot infer -whether it is true or false without knowing the -value of _a_. Thus, propositional logic cannot deal -with such sentences. However, such assertions -appear quite often in mathematics and we want -to infer on those assertions. Also, the pattern -involved in the following two logical equiva- -lences cannot be captured by propositional -logic: “ _Not all men are smokers_ ” and “ _Some men -don’t smoke._ ” Each of these two propositions -is treated independently in propositional logic. -There is no mechanism in propositional logic to -find out whether or not the two are equivalent to -one another. Hence, in propositional logic, each -equivalent proposition is treated individually -rather than dealing with a general formula that -covers all equivalences collectively. -Predicate logic is supposed to be a more pow- -erful logic that addresses these issues. In a sense, -predicate logic (also known as first-order logic -or predicate calculus) is an extension of propo- -sitional logic to formulas involving terms and -predicates. - -**3. Proof Techniques** - [1*, c1] - -A proof is an argument that rigorously establishes -the truth of a statement. Proofs can themselves be -represented formally as discrete structures. - -``` -Statements used in a proof include axioms -and postulates that are essentially the underlying -assumptions about mathematical structures, the -hypotheses of the theorem to be proved, and pre- -viously proved theorems. -A theorem is a statement that can be shown to -be true. -A lemma is a simple theorem used in the proof -of other theorems. -A corollary is a proposition that can be estab- -lished directly from a theorem that has been -proved. -A conjecture is a statement whose truth value -is unknown. -When a conjecture’s proof is found, the conjec- -ture becomes a theorem. Many times conjectures -are shown to be false and, hence, are not theorems. -``` -``` -3.1. Methods of Proving Theorems -``` -``` -Direct Proof. Direct proof is a technique to estab- -lish that the implication p → q is true by showing -that q must be true when p is true. -For example, to show that if n is odd then n^2 −1 -is even, suppose n is odd, i.e., n = 2k + 1 for some -integer k: -``` -``` -∴ n^2 = (2k + 1)^2 = 4k^2 + 4k + 1. -``` -``` -As the first two terms of the Right Hand Side -(RHS) are even numbers irrespective of the value -of k, the Left Hand Side (LHS) (i.e., n^2 ) is an odd -number. Therefore, n^2 −1 is even. -Proof by Contradiction. A proposition p is true -by contradiction if proved based on the truth of -the implication ¬ p → q where q is a contradiction. -For example, to show that the sum of 2x + 1 -and 2y − 1 is even, assume that the sum of 2x + 1 -and 2y − 1is odd. In other words, 2(x + y), which -is a multiple of 2, is odd. This is a contradiction. -Hence, the sum of 2x + 1 and 2y − 1 is even. -An inference rule is a pattern establishing that -if a set of premises are all true, then it can be -deduced that a certain conclusion statement is -true. The reference rules of addition, simplifica- -tion, and conjunction need to be studied. -Proof by Induction. Proof by induction is done -in two phases. First, the proposition is estab- -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- -lished that if the proposition holds for an arbitrary -positive integer _k,_ then it must also hold for the -next greater integer, _k + 1_. In other words, proof -by induction is based on the rule of inference that -tells us that the truth of an infinite sequence of -propositions P(n), ∀n ∈ [1 ... ∞] is established -if P(1) is true, and secondly, ∀k ∈ [2 ... n] if P(k) -→ P(k + 1). -It may be noted here that, for a proof by math- -ematical induction, it is not assumed that P(k) is -true for all positive integers k. Proving a theo- -rem or proposition only requires us to establish -that if it is assumed P(k) is true for any arbitrary -positive integer k, then P(k + 1) is also true. The -correctness of mathematical induction as a valid -proof technique is beyond discussion of the cur- -rent text. Let us prove the following proposition -using induction. -Proposition: _The sum of the first n positive odd -integers P(n) is n_^2_._ -Basis Step: The proposition is true for n = 1 as -P(1) = 1^2 = 1. The basis step is complete. -Inductive Step: The induction hypothesis (IH) -is that the proposition is true for n = k, k being an -arbitrary positive integer k. - -``` -∴ 1 + 3 + 5+ ... + (2k − 1) = k^2 -``` -``` -Now, it’s to be shown that P(k) → P(k + 1). -``` -``` -P(k + 1) = 1 + 3 + 5+ ... +(2k − 1) + (2k + 1) -= P(k) + (2k + 1) -= k^2 + (2k + 1) [using IH] -= k^2 + 2k + 1 -= (k + 1)^2 -``` -Thus, it is shown that if the proposition is true -for n = k, then it is also true for n = k + 1. -The basis step together with the inductive step of -the proof show that P(1) is true and the conditional -statement P(k) → P(k + 1) is true for all positive -integers k. Hence, the proposition is proved. - -**4. Basics of Counting** - [1*c6] - -The sum rule states that if a task t 1 can be done -in n 1 ways and a second task t 2 can be done in - -``` -n 2 ways, and if these tasks cannot be done at the -same time, then there are n 1 + n 2 ways to do either -task. -``` -- If A and B are disjoint sets, then |A ∪ B|=|A| - + |B|. -- In general if A1, A2, .... , An are disjoint - sets, then |A1 ∪ A2 ∪ ... ∪ An| = |A1| + |A2| - + ... + |An|. - -``` -For example, if there are 200 athletes doing -sprint events and 30 athletes who participate in -the long jump event, then how many ways are -there to pick one athlete who is either a sprinter -or a long jumper? -Using the sum rule, the answer would be 200 -+ 30 = 230. -The product rule states that if a task t 1 can be -done in n 1 ways and a second task t 2 can be done -in n 2 ways after the first task has been done, then -there are n 1 * n 2 ways to do the procedure. -``` -- If A and B are disjoint sets, then |A × B| = - |A| * |B|. -- In general if A1, A2, ..., An are disjoint sets, - then |A1 × A2 × ... × An| = |A1| * |A2| * .... - * |An|. - -``` -For example, if there are 200 athletes doing -sprint events and 30 athletes who participate in -the long jump event, then how many ways are -there to pick two athletes so that one is a sprinter -and the other is a long jumper? -Using the product rule, the answer would be -200 * 30 = 6000. -The principle of inclusion-exclusion states that -if a task t 1 can be done in n 1 ways and a second -task t 2 can be done in n 2 ways at the same time -with t 1 , then to find the total number of ways the -two tasks can be done, subtract the number of -ways to do both tasks from n 1 + n 2. -``` -- If A and B are not disjoint, |A ∪ B| = |A| + - |B| − |A ∩ B|. - -``` -In other words, the principle of inclusion- -exclusion aims to ensure that the objects in the -intersection of two sets are not counted more than -once. -``` - -**14-8** **_SWEBOK® Guide_** **V3.0** - -_Recursion_ is the general term for the practice -of defining an object in terms of itself. There are -recursive algorithms, recursively defined func- -tions, relations, sets, etc. -A recursive function is a function that calls -itself. For example, we define f(n) = 3 * f(n − 1) -for all n ∈ N and n ≠ 0 and f(0) = 5. -An algorithm is recursive if it solves a problem -by reducing it to an instance of the same problem -with a smaller input. -A phenomenon is said to be random if individ- -ual outcomes are uncertain but the long-term pat- -tern of many individual outcomes is predictable. -The probability of any outcome for a ran- -dom 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 probabil- -ity model, the P(S) = 1. All possible outcomes -together must have probability of 1. -Two events A and B are disjoint if they have -no outcomes in common and so can never occur -together. If A and B are two disjoint events, P(A -or B) = P(A) + P(B). This is known as the addi- -tion rule for disjoint events. -If two events have no outcomes in common, -the probability that one or the other occurs is the -sum of their individual probabilities. -Permutation is an arrangement of objects in -which the order matters without repetition. One -can choose r objects in a particular order from a -total of n objects by using nPr ways, where, npr = -n! / (n − r)!. Various notations like nPr and P(n, r) -are used to represent the number of permutations -of a set of n objects taken r at a time. -Combination is a selection of objects in which -the order does not matter without repetition. This -is different from a permutation because the order -does not matter. If the order is only changed (and -not the members) then no new combination is -formed. One can choose r objects in any order -from a total of n objects by using nCr ways, where, -nC -r = n! / [r! * (n − r)!]. - -**5. Graphs and Trees** - [1*, c10, c11] - -``` -5.1. Graphs -``` -``` -A graph G = (V, E) where V is the set of vertices -(nodes) and E is the set of edges. Edges are also -referred to as arcs or links. -``` -``` -Figure 14.8. Example of a Graph -``` -``` -F is a function that maps the set of edges E to -a set of ordered or unordered pairs of elements V. -For example, in Figure 14.8, G = (V, E) where V -= {A, B, C}, E = {e1, e2, e3}, and F = {(e1, (A, -C)), (e2, (C, B)), (e3, (B, A))}. -The graph in Figure 14.8 is a simple graph that -consists of a set of vertices or nodes and a set of -edges connecting unordered pairs. -The edges in simple graphs are undirected. -Such graphs are also referred to as undirected -graphs. -For example, in Figure 14.8, (e1, (A, C)) may -be replaced by (e1, (C, A)) as the pair between -vertices A and C is unordered. This holds good -for the other two edges too. -In a multigraph, more than one edge may con- -nect the same two vertices. Two or more connect- -ing edges between the same pair of vertices may -reflect multiple associations between the same -two vertices. Such edges are called parallel or -multiple edges. -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 -``` -``` -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.10. Example of a Pseudograph -``` -For example, in Figure 14.10, the edge e4 both -starts and ends at B. Figure 14.10 is a pseudo- -graph in which e4 is a loop. - -``` -Figure 14.11. Example of a Directed Graph -``` -``` -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 con- -tain 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.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, -and 15 respectively. If the vertices A, B, and C -represent three cities in a state, the weights, for -example, could be the distances in miles between -these cities. -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 undi- -rected graph G(V, E), then: -``` -- the _degree_ of v, deg(v), is its number of inci- - 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: - -- u is _adjacent to_ v, and v is _adjacent from_ u. -- e _comes from_ u and _goes to_ v. -- e _connects_ u to v, or e _goes from_ u to v. -- the _initial vertex_ of e is u. -- the _terminal vertex_ of e is v. - -If vertex v is in the set of vertices for the -directed graph G(V, E), then - -- _in-degree_ of v, deg−(v), is the number of - edges going to v, i.e., for which v is the ter- - minal vertex. -- _out-degree_ of v, deg+(v), is the number of - edges coming from v, i.e., for which v is the - initial vertex. -- _degree_ of v, deg(v) = deg−(v) + deg+(v), is the - sum of vs in-degree and out-degree. -- a loop at a vertex contributes 1 to both in- - degree and out-degree of this vertex. - -It may be noted that, following the definitions -above, the degree of a node is unchanged whether -we consider its edges to be directed or undirected. -In an undirected graph, a path of length n from -u to v is a sequence of n adjacent edges from ver- -tex u to vertex v. - -- A path is a _circuit_ if u=v. -- A path _traverses_ the vertices along it. -- A path is _simple_ if it contains no edge more - than once. - -A cycle on n vertices Cn for any n ≥ 3 is a sim- -ple graph where V = {v 1 , v 2 , ..., vn} and E = {{v 1 , -v 2 }, {v 2 , v 3 }, ... , {vn−1, vn}, {vn, v 1 }}. -For example, Figure 14.13 illustrates two -cycles of length 3 and 4. - -``` -Figure 14.13. Example of Cycles C 3 and C 4 -``` -``` -An adjacency list is a table with one row per -vertex, listing its adjacent vertices. The adjacency -listing for a directed graph maintains a listing of -the terminal nodes for each of the vertex in the -graph. -``` -``` -Ve r t ex -Adjacency -List -``` -``` -A B, C -``` -``` -B A, B, C -``` -``` -C A, B -``` -``` -Figure 14.14. Adjacency Lists for Graphs in Figures 14.10 -and 14.11 -``` -``` -For example, Figure 14.14 illustrates the adja- -cency lists for the pseudograph in Figure 14.10 -and the directed graph in Figure 14.11. As the -out-degree of vertex C in Figure 14.11 is zero, -there is no entry against C in the adjacency list. -Different representations for a graph—like -adjacency matrix, incidence matrix, and adja- -cency lists—need to be studied. -``` -``` -5.2. Trees -``` -``` -A tree T(N, E) is a hierarchical data structure of n -= |N| nodes with a specially designated root node -R while the remaining n − 1 nodes form subtrees -under the root node R. The number of edges |E| in -a tree would always be equal to |N| − 1. -The subtree at node X is the subgraph of the -tree consisting of node X and its descendants and -all edges incident to those descendants. As an -alternate to this recursive definition, a tree may -be defined as a connected undirected graph with -no simple circuits. -``` - -``` -Mathematical Foundations 14-11 -``` -``` -Figure 14.15. Example of a Tree -``` -However, one should remember that a tree is -strictly hierarchical in nature as compared to a -graph, which is flat. In case of a tree, an ordered -pair is built between two nodes as parent and -child. Each child node in a tree is associated -with only one parent node, whereas this restric- -tion becomes meaningless for a graph where no -parent-child association exists. -An undirected graph is a tree if and only if -there is a unique simple path between any two of -its vertices. -Figure 14.15 presents a tree T(N, E) where the -set of nodes N = {A, B, C, D, E, F, G, H, I, J, K}. -The edge set E is {(A, B), (A, C), (A, D), (B, E), -(B, F), (B, G), (C, H), (C, I), (D, J), (D, K)}. -The parent of a nonroot node v is the unique -node u with a directed edge from u to v. Each -node in the tree has a unique parent node except -the root of the tree. -For example, in Figure 14.15, root node A is -the parent node for nodes B, C, and D. Similarly, -B is the parent of E, F, G, and so on. The root -node A does not have any parent. -A node that has children is called an internal -node. -For example, in Figure 14.15, node A or node B -are examples of internal nodes. -The degree of a node in a tree is the same as its -number of children. -For example, in Figure 14.15, root node A and -its child B are both of degree 3. Nodes C and D -have degree 2. -The distance of a node from the root node in -terms of number of hops is called its _level_. Nodes -in a tree are at different levels. The root node is - -``` -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 lev- -els 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. -For example, in Figure 14.15, nodes E through -K are all leaf nodes with degree 0. -The ancestors or predecessors of a nonroot -node X are all the nodes in the path from root to -node X. -For example, in Figure 14.15, nodes A and D -form the set of ancestors for J. -The successors or descendents of a node X are -all the nodes that have X as its ancestor. For a tree -with n nodes, all the remaining n − 1 nodes are -successors of the root node. -For example, in Figure 14.15, node B has suc- -cessors in E, F, and G. -If node X is an ancestor of node Y, then node Y -is a successor of X. -Two or more nodes sharing the same parent -node are called sibling nodes. -For example, in Figure 14.15, nodes E and G -are siblings. However, nodes E and J, though -from the same level, are not sibling nodes. -Two sibling nodes are of the same level, but -two nodes in the same level are not necessarily -siblings. -A tree is called an ordered tree if the rela- -tive position of occurrences of children nodes is -significant. -For example, a family tree is an ordered tree -if, as a rule, the name of an elder sibling appears -always before (i.e., on the left of) the younger -sibling. -In an unordered tree, the relative position of -occurrences between the siblings does not bear -any significance and may be altered arbitrarily. -A binary tree is formed with zero or more nodes -where there is a root node R and all the remaining -nodes form a pair of ordered subtrees under the -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.16. Examples of Binary Trees -``` -For example, in Figure 14.16, the two binary -trees are different as the positions of occurrences -of the children of A are different in the two trees. - -``` -Figure 14.17. Example of a Full Binary Tree -``` -According to [1*], a binary tree is called a full -binary tree if every internal node has exactly two -children. -For example, the binary tree in Figure 14.17 -is a full binary tree, as both of the two internal -nodes A and B are of degree 2. -A full binary tree following the definition -above is also referred to as a _strictly binary tree_. -For example, both binary trees in Figure 14.18 -are complete binary trees. The tree in Figure -14.18(a) is a complete as well as a full binary -tree. A complete binary tree has all its levels, -except possibly the last one, filled up to capacity. -In case the last level of a complete binary tree is -not full, nodes occur from the leftmost positions -available. - -``` -Figure 14.18. Example of Complete Binary Trees -``` -``` -Interestingly, following the definitions above, -the tree in Figure 14.18(b) is a complete but not -full binary tree as node B has only one child in D. -On the contrary, the tree in Figure 14.17 is a full -—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 = -⎡log 2 L⎤. -For example, this statement is true for the -two trees in Figures 14.17 and 14.18(a) as both -trees are full and balanced. However, the expres- -sion above does not match for the tree in Figure -14.18(b) as it is not a full binary tree. -A binary search tree (BST) is a special kind of -binary tree in which each node contains a distinct -key value, and the key value of each node in the -tree is less than every key value in its right subtree -and greater than every key value in its left subtree. -A traversal algorithm is a procedure for sys- -tematically visiting every node of a binary tree. -Tree traversals may be defined recursively. -If T is binary tree with root R and the remain- -ing nodes form an ordered pair of nonnull left -subtree TL and nonnull right subtree TR below R, -then the preorder traversal function PreOrder(T) -is defined as: -``` -``` -PreOrder(T) = R, PreOrder(TL), PreOrder(TR) -... eqn. 1 -``` - -``` -Mathematical Foundations 14-13 -``` -The recursive process of finding the preorder -traversal of the subtrees continues till the sub- -trees are found to be Null. Here, commas have -been used as delimiters for the sake of improved -readability. -The postorder and in-order may be similarly -defined using eqn. 2 and eqn. 3 respectively. - -``` -PostOrder(T) = PostOrder(TL), PostOrder(TR), -R ... eqn 2 -InOrder(T) = InOrder(TL), R, InOrder(TR) ... -eqn 3 -``` -``` -Figure 14.19. A Binary Search Tree -``` -For example, the tree in Figure 14.19 is a binary -search tree (BST). The preorder, postorder, and -in-order traversal outputs for the BST are given -below in their respective order. - -``` -Preorder output: 9, 5, 2, 1, 4, 7, 6, 8, 13, 11, -10, 15 -Postorder output: 1, 4, 2, 6, 8, 7, 5, 10, 11, 15, -13, 9 -In-order output: 1, 2, 4, 5, 6, 7, 8, 9, 10, 11, -13, 15 -``` -Further discussion on trees and their usage has -been included in section 6, Data Structure and Rep- -resentation, of the Computing Foundations KA. - -**6. Discrete Probability** - [1*, c7] - -Probability is the mathematical description of -randomness. Basic definition of probability and - -``` -randomness has been defined in section 4 of this -KA. Here, let us start with the concepts behind -probability distribution and discrete probability. -A probability model is a mathematical descrip- -tion of a random phenomenon consisting of two -parts: a sample space S and a way of assigning -probabilities to events. The sample space defines -the set of all possible outcomes, whereas an event -is a subset of a sample space representing a pos- -sible outcome or a set of outcomes. -A random variable is a function or rule that -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 dis- -crete or continuous depending on the experiment. -A discrete random variable can hold all pos- -sible outcomes without missing any, although it -might take an infinite amount of time. -A continuous random variable is used to mea- -sure an uncountable number of values even if an -infinite amount of time is given. -For example, if a random variable X represents -an outcome that is a real number between 1 and -100, then X may have an infinite number of val- -ues. One can never list all possible outcomes for -X even if an infinite amount of time is allowed. -Here, X is a continuous random variable. On -the contrary, for the same interval of 1 to 100, -another random variable Y can be used to list all -the integer values in the range. Here, Y is a dis- -crete random variable. -An upper-case letter, say X, will represent -the name of the random variable. Its lower-case -counterpart, x, will represent the value of the ran- -dom variable. -The probability that the random variable X will -equal x is: -``` -``` -P(X = x) or, more simply, P(x). -``` -``` -A probability distribution (density) function is -a table, formula, or graph that describes the val- -ues of a random variable and the probability asso- -ciated with these values. -``` - -**14-14** **_SWEBOK® Guide_** **V3.0** - -Probabilities associated with discrete random -variables have the following properties: - -``` -i. 0 ≤ P(x) ≤ 1 for all x -ii. ΣP(x) = 1 -``` -A discrete probability distribution can be repre- -sented as a discrete random variable. - -##### X 1 2 3 4 5 6 - -``` -P(x) 1/6 1/6 1/6 1/6 1/6 1/6 -``` -**Figure 14.20.** A Discrete Probability Function for a Rolling -Die - -The mean μ of a probability distribution model -is the sum of the product terms for individual -events and its outcome probability. In other -words, for the possible outcomes x 1 , x 2 , ... , xn -in a sample space S if pk is the probability of out- -come xk, the mean of this probability would be μ -= x 1 p 1 + x 2 p 2 + ... + xnpn. -For example, the mean of the probability den- -sity for the distribution in Figure 14.20 would be - -``` -1 * (1/6) + 2 * (1/6) + 3 * (1/6) + 4 * (1/6) + 5 -* (1/6) + 6 * (1/6) -= 21 * (1/6) = 3.5 -``` -Here, the sample space refers to the set of all -possible outcomes. -The variance s^2 of a discrete probability model -is: s^2 = (x 1 – μ)^2 p 1 + (x 2 – μ)^2 p 2 + ... + (xk – μ)^2 pk. -The _standard deviation_ s is the square root of the -variance. -For example, for the probability distribution in -Figure 14.20, the variation σ^2 would be - -``` -s^2 = [(1 – 3.5)^2 * (1/6) + (2 – 3.5)^2 * (1/6) + -(3 – 3.5)^2 * (1/6) + (4 – 3.5)^2 * (1/6) + (5 – -3.5)^2 * (1/6) + (6 – 3.5)^2 * (1/6)] -= (6.25 + 2.25 + 0.25 + 0.5 + 2.25 + 6.25) * -(1/6) -= 17.5 * (1/6) -= 2.90 -``` -``` -∴ standard deviation s = -``` -``` -These numbers indeed aim to derive the aver- -age value from repeated experiments. This is -based on the single most important phenom- -enon of probability, i.e., the average value from -repeated experiments is likely to be close to the -expected value of one experiment. Moreover, -the average value is more likely to be closer to -the expected value of any one experiment as the -number of experiments increases. -``` -**7. Finite State Machines** - [1*, c13] - -``` -A computer system may be abstracted as a map- -ping from state to state driven by inputs. In other -words, a system may be considered as a transition -function T: S × I → S × O, where S is the set of -states and I, O are the input and output functions. -If the state set S is finite (not infinite), the sys- -tem is called a finite state machine (FSM). -Alternately, a finite state machine (FSM) is a -mathematical abstraction composed of a finite -number of states and transitions between those -states. If the domain S × I is reasonably small, -then one can specify T explicitly using diagrams -similar to a flow graph to illustrate the way logic -flows for different inputs. However, this is prac- -tical only for machines that have a very small -information capacity. -An FSM has a finite internal memory, an input -feature that reads symbols in a sequence and one -at a time, and an output feature. -The operation of an FSM begins from a start -state, goes through transitions depending on input -to different states, and can end in any valid state. -However, only a few of all the states mark a suc- -cessful flow of operation. These are called accept -states. -The information capacity of an FSM is -C = log |S|. Thus, if we represent a machine having -an information capacity of C bits as an FSM, then -its state transition graph will have |S| = 2C nodes. -A finite state machine is formally defined as M -= ( S , I , O , f , g , s 0 ). -``` -``` -S is the state set; -I is the set of input symbols; -O is the set of output symbols; -f is the state transition function; -``` - -``` -Mathematical Foundations 14-15 -``` -``` -g is the output function; -and s 0 is the initial state. -``` -Given an input x ∈ I on state Sk, the FSM -makes a transition to state Sh following state tran- -sition function f and produces an output y ∈ O -using the output function g. - -``` -Figure 14.21. Example of an FSM -``` -For example, Figure 14.21 illustrates an FSM -with S 0 as the start state and S 1 as the final state. -Here, S = {S 0 , S 1 , S 2 }; I = {0, 1}; O = {2, 3}; f(S 0 , -0) = S 2 , f(S 0 , 1) = S 1 , f(S 1 , 0) = S 2 , f(S 1 , 1) = S 2 , f(S 2 , -0) = S 2 , f(S 2 , 1) = S 0 ; g(S 0 , 0) = 3, g(S 0 , 1) = 2, g(S 1 , -0) = 3, g(S 1 , 1) = 2, g(S 2 , 0) = 2, g(S 2 , 1) = 3. - -``` -Current -State -``` -``` -Input -0 1 -S 0 S 2 S 1 -S 1 S 2 S 2 -S 2 S 2 S 0 -``` -``` -(a) -``` -``` -Current -State -``` -``` -Output State -Input Input -0 1 0 1 -S 0 3 2 S 2 S 1 -S 1 3 2 S 2 S 2 -S 2 2 3 S 2 S 0 -``` -``` -(b) -``` -``` -Figure 14.22. Tabular Representation of an FSM -``` -``` -The state transition and output values for differ- -ent inputs on different states may be represented -using a state table. The state table for the FSM in -Figure 14.21 is shown in Figure 14.22. Each pair -against an input symbol represents the new state -and the output symbol. -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 lan- -guage 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. -A formal language is a set of finite-length -words or strings over some finite alphabet, and -a grammar specifies the rules for formation of -these words or strings. The entire set of words -that are valid for a grammar constitutes the lan- -guage for the grammar. Thus, the grammar G is -any compact, precise mathematical definition of a -language L as opposed to just a raw listing of all -of the language’s legal sentences or examples of -those sentences. -A grammar implies an algorithm that would -generate all legal sentences of the language. -There are different types of grammars. -A phrase-structure or Type-0 grammar G = (V, -T, S, P) is a 4-tuple in which: -``` -- 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 - symbol. -- P is the set of productions rules for substitut- - ing one sentence fragment for another. - -``` -There exists another set N = V − T of words -called nonterminals. The nonterminals represent -concepts like noun. Production rules are applied -on strings containing nonterminals until no more -nonterminal symbols are present in the string. -The start symbol S is a nonterminal. -``` - -**14-16** **_SWEBOK® Guide_** **V3.0** - -The language generated by a formal grammar -G, denoted by L(G), is the set of all strings over -the set of alphabets V that can be generated, start- -ing with the start symbol, by applying produc- -tion rules until all the nonterminal symbols are -replaced in the string. -For example, let G = ({S, A, a, b}, {a, b}, S, {S -→ aA, S → b, A → aa}). Here, the set of termi- -nals are N = {S, A}, where S is the start symbol. -The three production rules for the grammar are -given as P1: S → aA; P2: S → b; P3: A → aa. -Applying the production rules in all possible -ways, the following words may be generated -from the start symbol. - -``` -S → aA (using P1 on start symbol) -→ aaa (using P3) -S → b (using P2 on start symbol) -``` -Nothing else can be derived for G. Thus, the -language of the grammar G consists of only two -words: L(G) = {aaa, b}. - -_8.1. Language Recognition_ - -Formal grammars can be classified according to the -types of productions that are allowed. The Chom- -sky hierarchy (introduced by Noam Chomsky in -1956) describes such a classification scheme. - -``` -Figure 14.23. Chomsky Hierarchy of Grammars -``` -As illustrated in Figure 14.23, we infer the fol- -lowing on different types of grammars: - -1. Every regular grammar is a context-free - grammar (CFG). -2. Every CFG is a context-sensitive grammar - (CSG). - 3. Every CSG is a phrase-structure grammar - (PSG). - -``` -Context-Sensitive Grammar: All fragments in -the RHS are either longer than the corresponding -fragments in the LHS or empty, i.e., if b → a, then -|b| < |a| or a = ∅. -A formal language is context-sensitive if a con- -text-sensitive grammar generates it. -Context-Free Grammar: All fragments in the -LHS are of length 1, i.e., if A → a, then |A| = 1 -for all A ∈ N. -The term context-free derives from the fact that -A can always be replaced by a, regardless of the -context in which it occurs. -A formal language is context-free if a context- -free grammar generates it. Context-free lan- -guages are the theoretical basis for the syntax of -most programming languages. -Regular Grammar. All fragments in the RHS -are either single terminals or a pair built by a -terminal and a nonterminal; i.e., if A → a, then -either a ∈ T, or a = cD, or a = Dc for c ∈ T, D ∈ N. -If a = cD, then the grammar is called a right -linear grammar. On the other hand, if a = Dc, then -the grammar is called a left linear grammar. Both -the right linear and left linear grammars are regu- -lar or Type-3 grammar. -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 infor- -mation: 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). -``` -. creates a product structure, L(AB) = L(A). - L(B). -* denotes concatenation, L(A*) = {x 1 x 2 ...xn | - xi ∈ L(A) and n ³ 0} - -``` -For example, the regular expression (ab)* -matches the set of strings: {e, ab, abab, ababab, -abababab, ...}. -``` - -``` -Mathematical Foundations 14-17 -``` -For example, the regular expression (aa)* -matches the set of strings on one letter _a_ that have -even length. -For example, the regular expression (aaa)* + -(aaaaa)* matches the set of strings of length equal -to a multiple of 3 or 5. - -**9. Numerical Precision, Accuracy, and Errors** - [2*, c2] - -The main goal of numerical analysis is to -develop efficient algorithms for computing pre- -cise numerical values of functions, solutions of -algebraic and differential equations, optimization -problems, etc. -A matter of fact is that all digital computers can -only store finite numbers. In other words, there -is no way that a computer can represent an infi- -nitely large number—be it an integer, rational -number, or any real or all complex numbers (see -section 10, Number Theory). So the mathematics -of approximation becomes very critical to handle -all the numbers in the finite range that a computer -can handle. -Each number in a computer is assigned a loca- -tion or word, consisting of a specified number of -binary digits or bits. A k bit word can store a total -of N = 2k different numbers. -For example, a computer that uses 32 bit arith- -metic can store a total of N = 2^32 ≈ 4.3 × 10^9 dif- -ferent numbers, while another one that uses 64 -bits can handle N’ = 2^64 ≈ 1.84 × 10^19 different -numbers. The question is how to distribute these -N numbers over the real line for maximum effi- -ciency and accuracy in practical computations. -One evident choice is to distribute them evenly, -leading to fixed-point arithmetic. In this system, -the first bit in a word is used to represent a sign -and the remaining bits are treated for integer val- -ues. This allows representation of the integers -from 1 − ½N, i.e., = 1 − 2k−1 to 1. As an approxi- -mating method, this is not good for noninteger -numbers. -Another option is to space the numbers closely -together—say with a uniform gap of 2−n—and so -distribute the total N numbers uniformly over the -interval −2−n−1N < x ≤ 2−n−1N. Real numbers lying -between the gaps are represented by either _round- -ing_ (meaning the closest exact representative) - -``` -or chopping (meaning the exact representative -immediately below —or above, if negative—the -number). -Numbers lying beyond the range must be repre- -sented by the largest (or largest negative) number -that can be represented. This becomes a symbol -for overflow. Overflow occurs when a computa- -tion produces a value larger than the maximum -value in the range. -When processing speed is a significant bottle- -neck, the use of the fixed-point representations -is an attractive and faster alternative to the more -cumbersome floating-point arithmetic most com- -monly used in practice. -Let’s define a couple of very important terms: -accuracy and precision as associated with numer- -ical analysis. -Accuracy is the closeness with which a mea- -sured or computed value agrees with the true value. -Precision, on the other hand, is the closeness -with which two or more measured or computed -values for the same physical substance agree with -each other. In other words, precision is the close- -ness with which a number represents an exact -value. -Let x be a real number and let x* be an approxi- -mation. The absolute error in the approximation -x* ≈ x is defined as | x* − x |. The relative error -is defined as the ratio of the absolute error to the -size of x, i.e., |x* − x| / | x |, which assumes x ¹ 0; -otherwise, relative error is not defined. -For example, 1000000 is an approximation to -1000001 with an absolute error of 1 and a relative -error of 10−6, while 10 is an approximation of 11 -with an absolute error of 1 and a relative error of -0.1. Typically, relative error is more intuitive and -the preferred determiner of the size of the error. -The present convention is that errors are always -≥ 0, and are = 0 if and only if the approximation -is exact. -An approximation x* has k significant deci- -mal digits if its relative error is < 5 × 10−k−1. This -means that the first k digits of x* following its -first nonzero digit are the same as those of x. -Significant digits are the digits of a number that -are known to be correct. In a measurement, one -uncertain digit is included. -For example, measurement of length with -a ruler of 15.5 mm with ±0.5 mm maximum -``` - -**14-18** **_SWEBOK® Guide_** **V3.0** - -allowable error has 2 significant digits, whereas -a measurement of the same length using a caliper -and recorded as 15.47 mm with ±0.01 mm maxi- -mum allowable error has 3 significant digits. - -**10. Number Theory** - [1*, c4] - -Number theory is one of the oldest branches -of pure mathematics and one of the largest. Of -course, it concerns questions about numbers, -usually meaning whole numbers and fractional or -rational numbers. The different types of numbers -include integer, real number, natural number, -complex number, rational number, etc. - -_10.1. Divisibility_ - -Let’s start this section with a brief description of -each of the above types of numbers, starting with -the natural numbers. -_Natural Numbers._ This group of numbers starts -at 1 and continues: 1, 2, 3, 4, 5, and so on. Zero -is not in this group. There are no negative or frac- -tional numbers in the group of natural numbers. -The common mathematical symbol for the set of -all natural numbers is N. -_Whole Numbers._ This group has all of the natu- -ral numbers in it plus the number 0. -Unfortunately, not everyone accepts the above -definitions of natural and whole numbers. There -seems to be no general agreement about whether -to include 0 in the set of natural numbers. -Many mathematicians consider that, in Europe, -the sequence of natural numbers traditionally -started with 1 (0 was not even considered to be -a number by the Greeks). In the 19th century, set -theoreticians and other mathematicians started -the convention of including 0 in the set of natural -numbers. -_Integers._ This group has all the whole numbers -in it and their negatives. The common mathemati- -cal symbol for the set of all integers is Z, i.e., Z = -{..., −3, −2, −1, 0, 1, 2, 3, ...}. -_Rational Numbers._ These are any numbers that -can be expressed as a ratio of two integers. The -common symbol for the set of all rational num- -bers is Q. -Rational numbers may be classified into -three types, based on how the decimals act. The - -``` -decimals either do not exist, e.g., 15, or, when -decimals do exist, they may terminate, as in 15.6, -or they may repeat with a pattern, as in 1.666..., -(which is 5/3). -Irrational Numbers. These are numbers that -cannot be expressed as an integer divided by an -integer. These numbers have decimals that never -terminate and never repeat with a pattern, e.g., PI -or √2. -Real Numbers. This group is made up of all the -rational and irrational numbers. The numbers that -are encountered when studying algebra are real -numbers. The common mathematical symbol for -the set of all real numbers is R. -Imaginary Numbers. These are all based on the -imaginary number i. This imaginary number is -equal to the square root of −1. Any real number -multiple of i is an imaginary number, e.g., i , 5 i , -3.2 i , −2.6 i, etc. -Complex Numbers. A complex number is a -combination of a real number and an imaginary -number in the form a + b i. The real part is a, and -b is called the imaginary part. The common math- -ematical symbol for the set of all complex num- -bers is C. -For example, 2 + 3 i , 3−5 i , 7.3 + 0 i , and 0 + 5 i. -Consider the last two examples: -7.3 + 0 i is the same as the real number 7.3. -Thus, all real numbers are complex numbers with -zero for the imaginary part. -Similarly, 0 + 5 i is just the imaginary number -5 i. Thus, all imaginary numbers are complex -numbers with zero for the real part. -Elementary number theory involves divisibility -among integers. Let a, b ∈ Z with a ≠ 0.The expres- -sion a|b, i.e., a divides b if ∃c ∈ Z: b = ac, i.e., there -is an integer c such that c times a equals b. -For example, 3|−12 is true, but 3|7 is false. -If a divides b , then we say that a is a factor of -b or a is a divisor of b , and b is a multiple of a. -b is even if and only if 2| b. -Let a, d ∈ Z with d > 1. Then a mod d denotes -that the remainder r from the division algorithm -with dividend a and divisor d , i.e., the remainder -when a is divided by d. We can compute (a mod -d) by: a − d * ⎣ a/d ⎦ , where ⎣ a/d ⎦ represents the -floor of the real number. -Let Z+ = {n ∈ Z | n > 0} and a, b ∈ Z, m ∈ Z+, -then a is congruent to b modulo m , written as a ≡ -b (mod m) , if and only if m | a−b. -``` - -``` -Mathematical Foundations 14-19 -``` -Alternately, _a_ is congruent to _b modulo m_ if and -only if _(a−b) mod m = 0_. - -_10.2. Prime Number, GCD_ - -An integer p > 1 is prime if and only if it is not -the product of any two integers greater than 1, -i.e., p is prime if p > 1 ∧ ∃ ¬ a, b ∈ N: a > 1, b > -1, a * b = p. -The only positive factors of a prime p are 1 -and p itself. For example, the numbers 2, 13, 29, -61, etc. are prime numbers. Nonprime integers -greater than 1 are called composite numbers. A -composite number may be composed by multi- -plying two integers greater than 1. -There are many interesting applications of -prime numbers; among them are the public- -key cryptography scheme, which involves the -exchange of public keys containing the product -_p*q_ of two random large primes _p_ and _q_ (a private -key) that must be kept secret by a given party. -The greatest common divisor gcd(a, b) of inte- -gers a, b is the greatest integer d that is a divisor -both of a and of b, i.e., - -``` -d = gcd(a, b) for max(d: d|a ∧ d|b) -``` -For example, gcd(24, 36) = 12. -Integers _a_ and _b_ are called relatively prime or -coprime if and only if their GCD is 1. -For example, neither 35 nor 6 are prime, but -they are coprime as these two numbers have no -common factors greater than 1, so their GCD is 1. -A set of integers X = {i 1 , i 2 , ...} is relatively -prime if all possible pairs ih, ik, h ≠ k drawn from -the set X are relatively prime. - -**11. Algebraic Structures** - -This section introduces a few representations -used in higher algebra. An algebraic structure -consists of one or two sets closed under some -operations and satisfying a number of axioms, -including none. -For example, group, monoid, ring, and lattice -are examples of algebraic structures. Each of -these is defined in this section. - -``` -11.1. Group -``` -``` -A set S closed under a binary operation • forms a -group if the binary operation satisfies the follow- -ing four criteria: -``` -- Associative: ∀a, b, c ∈ S, the equation (a • b) - - c = a • (b • c) holds. -- Identity: There exists an identity element I ∈ - S such that for all a ∈ S, I • a = a • I = a. -- Inverse: Every element a ∈ S, has an inverse - a' ∈ S with respect to the binary operation, - i.e., a • a' = I; for example, the set of integers - Z with respect to the addition operation is a - group. The identity element of the set is 0 for - the addition operation. ∀x ∈ Z, the inverse - of x would be –x, which is also included in Z. -- Closure property: ∀a, b ∈ S, the result of the - operation a • b ∈ S. -- A group that is commutative, i.e., a • b = b • a, - is known as a commutative or Abelian group. - -``` -The set of natural numbers N (with the opera- -tion of addition) is not a group, since there is no -inverse for any x > 0 in the set of natural numbers. -Thus, the third rule (of inverse) for our operation -is violated. However, the set of natural number -has some structure. -Sets with an associative operation (the first -condition above) are called semigroups; if they -also have an identity element (the second condi- -tion), then they are called monoids. -Our set of natural numbers under addition is -then an example of a monoid, a structure that -is not quite a group because it is missing the -requirement that every element have an inverse -under the operation. -A monoid is a set S that is closed under a single -associative binary operation • and has an identity -element I ∈ S such that for all a ∈ S, I • a = a • I -= a. A monoid must contain at least one element. -For example, the set of natural numbers N -forms a commutative monoid under addition with -identity element 0. The same set of natural num- -bers N also forms a monoid under multiplication -with identity element 1. The set of positive inte- -gers P forms a commutative monoid under multi- -plication 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 -with an identity element. -A _subgroup_ is a group _H_ contained within a -bigger one, _G,_ such that the identity element of -_G_ is contained in _H_ , and whenever _h_ 1 and _h_ 2 are -in _H_ , then so are _h_ 1 • _h_ 2 and _h_ 1 −1. Thus, the ele- -ments of _H_ , equipped with the group operation on -_G_ restricted to _H_ , indeed form a group. -Given any subset _S_ of a group _G_ , the subgroup -generated by _S_ consists of products of elements -of _S_ and their inverses. It is the smallest subgroup -of _G_ containing _S_. -For example, let _G_ be the Abelian group whose -elements are _G_ = {0, 2, 4, 6, 1, 3, 5, 7} and whose -group operation is addition modulo 8. This group -has a pair of nontrivial subgroups: _J_ = {0, 4} and -_H_ = {0, 2, 4, 6}, where _J_ is also a subgroup of _H_. -In group theory, a cyclic group is a group that -can be generated by a single element, in the -sense that the group has an element _a_ (called the -_generator_ of the group) such that, when written -multiplicatively, every element of the group is a -power of _a_. -A group G is cyclic if G = {an for any integer n}. -Since any group generated by an element in a -group is a subgroup of that group, showing that -the only subgroup of a group G that contains _a_ is -G itself suffices to show that G is cyclic. -For example, the group _G_ = {0, 2, 4, 6, 1, 3, 5, -7}, with respect to addition modulo 8 operation, -is cyclic. The subgroups _J_ = {0, 4} and _H_ = {0, 2, -4, 6} are also cyclic. - -``` -11.2. Rings -``` -``` -If we take an Abelian group and define a second -operation on it, a new structure is found that is -different from just a group. If this second opera- -tion is associative and is distributive over the -first, then we have a ring. -A ring is a triple of the form (S, +, •), where (S, -+) is an Abelian group, (S, •) is a semigroup, and -``` -- is distributive over +; i.e., “ a, b, c ∈ S, the equa- -tion _a_ • ( _b_ + _c_ ) = ( _a_ • _b_ ) + ( _a_ • _c_ ) holds. Further, if -- is commutative, then the ring is said to be com- -mutative. If there is an identity element for the • -operation, then the ring is said to have an identity. - For example, (Z, +, *), i.e., the set of integers Z, -with the usual addition and multiplication opera- -tions, is a ring. As (Z, *) is commutative, this ring -is a commutative or Abelian ring. The ring has 1 -as its identity element. - Let’s note that the second operation may not -have an identity element, nor do we need to find -an inverse for every element with respect to this -second operation. As for what distributive means, -intuitively it is what we do in elementary math- -ematics when performing the following change: a -* (b + c) = (a * b) + (a * c). - A field is a ring for which the elements of the -set, excluding 0, form an Abelian group with the -second operation. - A simple example of a field is the field of ratio- -nal numbers (R, +, *) with the usual addition -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 - -``` -Rosen 2011 -``` -##### [1*] - -``` -Cheney and Kincaid 2007 -``` -##### [2*] - -**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 - -[1*] K. Rosen, _Discrete Mathematics and Its -Applications_ , 7th ed., McGraw-Hill, 2011. - -[2*] E.W. Cheney and D.R. Kincaid, _Numerical -Mathematics and Computing_ , 6th ed., -Brooks/Cole, 2007. - -##### ACKNOWLEDGMENTS - -``` -The author thankfully acknowledges the contri- -bution of Prof. Arun Kumar Chatterjee, Ex-Head, -Department of Mathematics, Manipur Univer- -sity, India, and Prof. Devadatta Sinha, Ex-Head, -Department of Computer Science and Engineer- -ing, University of Calcutta, India, in preparing -this chapter on Mathematical Foundations. -``` blob - a116b05e17a9816720c99efc135a76f6912c0f71 (mode 644) blob + /dev/null --- 15_engineering_foundations.markdown +++ /dev/null @@ -1,1728 +0,0 @@ -``` -15-1 -``` -**CHAPTER 15** - -**ENGINEERING FOUNDATIONS** - -##### ACRONYMS - -``` -CAD Computer-Aided Design -``` -``` -CMMI -Capability Maturity Model -Integration -pdf Probability Density Function -pmf Probability Mass Function -RCA Root Cause Analysis -SDLC Software Development Life Cycle -``` -##### INTRODUCTION - -IEEE defines engineering as “the application of -a systematic, disciplined, quantifiable approach -to structures, machines, products, systems or -processes” [1]. This chapter outlines some of the -engineering foundational skills and techniques -that are useful for a software engineer. The focus -is on topics that support other KAs while mini- -mizing duplication of subjects covered elsewhere -in this document. -As the theory and practice of software engi- -neering matures, it is increasingly apparent that -software engineering is an engineering disci- -pline that is based on knowledge and skills com- -mon to all engineering disciplines. This Engi- -neering Foundations knowledge area (KA) is -concerned with the engineering foundations that -apply to software engineering and other engi- -neering disciplines. Topics in this KA include -empirical methods and experimental techniques; -statistical analysis; measurement; engineering -design; modeling, prototyping, and simulation; -standards; and root cause analysis. Application -of this knowledge, as appropriate, will allow -software engineers to develop and maintain -software more efficiently and effectively. Com- -pleting their engineering work efficiently and - -``` -effectively is a goal of all engineers in all engi- -neering disciplines. -``` -``` -BREAKDOWN OF TOPICS FOR -ENGINEERING FOUNDATIONS -``` -``` -The breakdown of topics for the Engineering -Foundations KA is shown in Figure 15.1. -``` -**1. Empirical Methods and Experimental -Techniques** - [2*, c1] - -``` -An engineering method for problem solving -involves proposing solutions or models of solu- -tions and then conducting experiments or tests -to study the proposed solutions or models. Thus, -engineers must understand how to create an exper- -iment and then analyze the results of the experi- -ment in order to evaluate the proposed solution. -Empirical methods and experimental techniques -help the engineer to describe and understand vari- -ability in their observations, to identify the sources -of variability, and to make decisions. -Three different types of empirical studies com- -monly used in engineering efforts are designed -experiments, observational studies, and retro- -spective studies. Brief descriptions of the com- -monly used methods are given below. -``` -``` -1.1. Designed Experiment -``` -``` -A designed or controlled experiment is an inves- -tigation of a testable hypothesis where one or -more independent variables are manipulated to -measure their effect on one or more dependent -variables. A precondition for conducting an -experiment is the existence of a clear hypothesis. -It is important for an engineer to understand how -to formulate clear hypotheses. -``` - -**15-2** **_SWEBOK® Guide_** **V3.0** - -Designed experiments allow engineers to -determine in precise terms how the variables are -related and, specifically, whether a cause-effect -relationship exists between them. Each combi- -nation of values of the independent variables is -a _treatment_. The simplest experiments have just -two treatments representing two levels of a sin- -gle independent variable (e.g., using a tool vs. -not using a tool). More complex experimental -designs arise when more than two levels, more -than one independent variable, or any dependent -variables are used. - -_1.2. Observational Study_ - -An observational or case study is an empirical -inquiry that makes observations of processes -or phenomena within a real-life context. While -an experiment deliberately ignores context, an -observational or case study includes context as -part of the observation. A case study is most use- -ful when the focus of the study is on _how_ and _why_ -questions, when the behavior of those involved in -the study cannot be manipulated, and when con- -textual conditions are relevant and the boundaries -between the phenomena and context are not clear. - -_1.3. Retrospective Study_ - -A retrospective study involves the analysis of his- -torical data. Retrospective studies are also known -as historical studies. This type of study uses data -(regarding some phenomenon) that has been -archived over time. This archived data is then ana- -lyzed in an attempt to find a relationship between -variables, to predict future events, or to identify -trends. The quality of the analysis results will -depend on the quality of the information contained -in the archived data. Historical data may be incom- -plete, inconsistently measured, or incorrect. - -**2. Statistical Analysis** - [2*, c9s1, c2s1] [3*, c10s3] - -``` -In order to carry out their responsibilities, engi- -neers must understand how different product -and process characteristics vary. Engineers often -come across situations where the relationship -between different variables needs to be studied. -An important point to note is that most of the -studies are carried out on the basis of samples -and so the observed results need to be understood -with respect to the full population. Engineers -must, therefore, develop an adequate understand- -ing of statistical techniques for collecting reliable -data in terms of sampling and analysis to arrive at -results that can be generalized. These techniques -are discussed below. -``` -``` -2.1. Unit of Analysis (Sampling Units), -Population, and Sample -``` -``` -Unit of analysis. While carrying out any empiri- -cal study, observations need to be made on cho- -sen units called the units of analysis or sampling -units. The unit of analysis must be identified and -must be appropriate for the analysis. For exam- -ple, when a software product company wants to -find the perceived usability of a software product, -the user or the software function may be the unit -of analysis. -Population. The set of all respondents or items -(possible sampling units) to be studied forms the -population. As an example, consider the case of -studying the perceived usability of a software -product. In this case, the set of all possible users -forms the population. -While defining the population, care must be -exercised to understand the study and target -population. There are cases when the popula- -tion studied and the population for which the -``` -``` -Figure 15.1. Breakdown of Topics for the Engineering Foundations KA -``` - -``` -Engineering Foundations 15-3 -``` -results are being generalized may be different. -For example, when the study population consists -of only past observations and generalizations are -required for the future, the study population and -the target population may not be the same. -_Sample._ A sample is a subset of the population. -The most crucial issue towards the selection of -a sample is its representativeness, including size. -The samples must be drawn in a manner so as -to ensure that the draws are independent, and -the rules of drawing the samples must be pre- -defined so that the probability of selecting a par- -ticular sampling unit is known beforehand. This -method of selecting samples is called _probability -sampling. -Random variable._ In statistical terminology, -the process of making observations or measure- -ments on the sampling units being studied is -referred to as conducting the experiment. For -example, if the experiment is to toss a coin 10 -times and then count the number of times the -coin lands on heads, each 10 tosses of the coin -is a sampling unit and the number of heads for a -given sample is the observation or outcome for -the experiment. The outcome of an experiment is -obtained in terms of real numbers and defines the -random variable being studied. Thus, the attribute -of the items being measured at the outcome of -the experiment represents the random variable -being studied; the observation obtained from a -particular sampling unit is a particular realization -of the random variable. In the example of the coin -toss, the random variable is the number of heads -observed for each experiment. In statistical stud- -ies, attempts are made to understand population -characteristics on the basis of samples. -The set of possible values of a random variable -may be finite or infinite but countable (e.g., the -set of all integers or the set of all odd numbers). -In such a case, the random variable is called a _dis- -crete random variable._ In other cases, the random -variable under consideration may take values on -a continuous scale and is called a _continuous ran- -dom variable. -Event._ A subset of possible values of a random -variable is called an event_._ Suppose X denotes -some random variable; then, for example, we -may define different events such as X ³ x or X < -x and so on. - -``` -Distribution of a random variable. The range -and pattern of variation of a random variable is -given by its distribution. When the distribution -of a random variable is known, it is possible to -compute the chance of any event. Some distribu- -tions are found to occur commonly and are used -to model many random variables occurring in -practice in the context of engineering. A few of -the more commonly occurring distributions are -given below. -``` -- Binomial distribution: used to model random - variables that count the number of successes - in _n_ trials carried out independently of each - other, where each trial results in success or - failure. We make an assumption that the - chance of obtaining a success remains con- - stant [2*, c3s6]. -- Poisson distribution: used to model the count - of occurrence of some event over time or - space [2*, c3s9]. -- Normal distribution: used to model continu- - ous random variables or discrete random - variables by taking a very large number of - values [2*, c4s6]. - -``` -Concept of parameters. A statistical distribution -is characterized by some parameters. For exam- -ple, the proportion of success in any given trial -is the only parameter characterizing a binomial -distribution. Similarly, the Poisson distribution is -characterized by a rate of occurrence. A normal -distribution is characterized by two parameters: -namely, its mean and standard deviation. -Once the values of the parameters are known, -the distribution of the random variable is com- -pletely known and the chance (probability) of -any event can be computed. The probabilities -for a discrete random variable can be computed -through the probability mass function, called -the pmf. The pmf is defined at discrete points -and gives the point mass—i.e., the probability -that the random variable will take that particular -value. Likewise, for a continuous random vari- -able, we have the probability density function, -called the pdf. The pdf is very much like density -and needs to be integrated over a range to obtain -the probability that the continuous random vari- -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- -able taking certain set of values may be computed -theoretically. -_Concept of estimation_ [2*, c6s2, c7s1, c7s3]. -The true values of the parameters of a distribution -are usually unknown and need to be estimated -from the sample observations. The estimates are -functions of the sample values and are called sta- -tistics. For example, the sample mean is a statistic -and may be used to estimate the population mean. -Similarly, the rate of occurrence of defects esti- -mated from the sample (rate of defects per line of -code) is a statistic and serves as the estimate of -the population rate of rate of defects per line of -code. The statistic used to estimate some popula- -tion parameter is often referred to as the _estimator_ -of the parameter. -A very important point to note is that the results -of the estimators themselves are random. If we -take a different sample, we are likely to get a dif- -ferent estimate of the population parameter. In the -theory of estimation, we need to understand dif- -ferent properties of estimators—particularly, how -much the estimates can vary across samples and -how to choose between different alternative ways -to obtain the estimates. For example, if we wish -to estimate the mean of a population, we might -use as our estimator a sample mean, a sample -median, a sample mode, or the midrange of the -sample. Each of these estimators has different -statistical properties that may impact the standard -error of the estimate. -_Types of estimates_ [2*, c7s3, c8s1].There are -two types of estimates: namely, point estimates -and interval estimates. When we use the value -of a statistic to estimate a population parameter, -we get a point estimate. As the name indicates, a -point estimate gives a point value of the param- -eter being estimated. -Although point estimates are often used, they -leave room for many questions. For instance, we -are not told anything about the possible size of -error or statistical properties of the point esti- -mate. Thus, we might need to supplement a point -estimate with the sample size as well as the vari- -ance of the estimate. Alternately, we might use -an interval estimate. An interval estimate is a -random interval with the lower and upper lim- -its of the interval being functions of the sample - -``` -observations as well as the sample size. The lim- -its are computed on the basis of some assump- -tions regarding the sampling distribution of the -point estimate on which the limits are based. -Properties of estimators. Various statistical -properties of estimators are used to decide about -the appropriateness of an estimator in a given -situation. The most important properties are that -an estimator is unbiased, efficient, and consistent -with respect to the population. -Tests of hypotheses [2*, c9s1].A hypothesis is -a statement about the possible values of a param- -eter. For example, suppose it is claimed that a -new method of software development reduces the -occurrence of defects. In this case, the hypoth- -esis is that the rate of occurrence of defects has -reduced. In tests of hypotheses, we decide—on -the basis of sample observations—whether a pro- -posed hypothesis should be accepted or rejected. -For testing hypotheses, the null and alternative -hypotheses are formed. The null hypothesis is the -hypothesis of no change and is denoted as H 0. The -alternative hypothesis is written as H 1. It is impor- -tant to note that the alternative hypothesis may be -one-sided or two-sided. For example, if we have -the null hypothesis that the population mean is not -less than some given value, the alternative hypoth- -esis would be that it is less than that value and we -would have a one-sided test. However, if we have -the null hypothesis that the population mean is -equal to some given value, the alternative hypoth- -esis would be that it is not equal and we would -have a two-sided test (because the true value could -be either less than or greater than the given value). -In order to test some hypothesis, we first com- -pute some statistic. Along with the computation -of the statistic, a region is defined such that in -case the computed value of the statistic falls in -that region, the null hypothesis is rejected. This -region is called the critical region (also known as -the confidence interval). In tests of hypotheses, -we need to accept or reject the null hypothesis -on the basis of the evidence obtained. We note -that, in general, the alternative hypothesis is the -hypothesis of interest. If the computed value of -the statistic does not fall inside the critical region, -then we cannot reject the null hypothesis. This -indicates that there is not enough evidence to -believe that the alternative hypothesis is true. -``` - -``` -Engineering Foundations 15-5 -``` -As the decision is being taken on the basis -of sample observations, errors are possible; the -types of such errors are summarized in the fol- -lowing table. - -``` -Nature -``` -``` -Statistical Decision -Accept H 0 Reject H 0 -H 0 is -true -``` -##### OK - -``` -Type I error -(probability = a) -H 0 is -false -``` -``` -Type II error -(probability = b) -``` -##### OK - -In test of hypotheses, we aim at maximizing the -power of the test (the value of 1−b) while ensur- -ing that the probability of a type I error (the value -of a) is maintained within a particular value— -typically 5 percent. -It is to be noted that construction of a test of -hypothesis includes identifying statistic(s) to -estimate the parameter(s) and defining a critical -region such that if the computed value of the sta- -tistic falls in the critical region, the null hypoth- -esis is rejected. - -_2.2. Concepts of Correlation and Regression_ -[2*, c11s2, c11s8] - -A major objective of many statistical investiga- -tions is to establish relationships that make it pos- -sible to predict one or more variables in terms of -others. Although it is desirable to predict a quan- -tity exactly in terms of another quantity, it is sel- -dom possible and, in many cases, we have to be -satisfied with estimating the average or expected -values. -The relationship between two variables is stud- -ied using the methods of correlation and regres- -sion. Both these concepts are explained briefly in -the following paragraphs. -_Correlation._ The strength of linear relation- -ship between two variables is measured using -the correlation coefficient_._ While computing the -correlation coefficient between two variables, we -assume that these variables measure two differ- -ent attributes of the same entity. The correlation -coefficient takes a value between –1 to +1. The -values –1 and +1 indicate a situation when the -association between the variables is perfect—i.e., - -``` -given the value of one variable, the other can be -estimated with no error. A positive correlation -coefficient indicates a positive relationship—that -is, if one variable increases, so does the other. On -the other hand, when the variables are negatively -correlated, an increase of one leads to a decrease -of the other. -It is important to remember that correlation -does not imply causation. Thus, if two variables -are correlated, we cannot conclude that one -causes the other. -Regression. The correlation analysis only -measures the degree of relationship between -two variables. The analysis to find the relation- -ship between two variables is called regression -analysis. The strength of the relationship between -two variables is measured using the coefficient of -determination. This is a value between 0 and 1. -The closer the coefficient is to 1, the stronger the -relationship between the variables. A value of 1 -indicates a perfect relationship. -``` -**3. Measurement** - [4*, c3s1, c3s2] [5*, c4s4] [6*, c7s5] - [7*, p442–447] - -``` -Knowing what to measure and which measure- -ment method to use is critical in engineering -endeavors. It is important that everyone involved -in an engineering project understand the mea- -surement methods and the measurement results -that will be used. -Measurements can be physical, environmen- -tal, economic, operational, or some other sort of -measurement that is meaningful for the particular -project. This section explores the theory of mea- -surement and how it is fundamental to engineer- -ing. Measurement starts as a conceptualization -then moves from abstract concepts to definitions -of the measurement method to the actual appli- -cation of that method to obtain a measurement -result. Each of these steps must be understood, -communicated, and properly employed in order -to generate usable data. In traditional engineer- -ing, direct measures are often used. In software -engineering, a combination of both direct and -derived measures is necessary [6*, p273]. -The theory of measurement states that mea- -surement is an attempt to describe an underlying -``` - -**15-6** **_SWEBOK® Guide_** **V3.0** - -real empirical system. Measurement methods -define activities that allocate a value or a symbol -to an attribute of an entity. -Attributes must then be defined in terms of -the operations used to identify and measure -them— that is, the measurement methods. In this -approach, a measurement method is defined to be -a precisely specified operation that yields a num- -ber (called the _measurement result)_ when mea- -suring an attribute. It follows that, to be useful, -the measurement method has to be well defined. -Arbitrariness in the method will reflect itself in -ambiguity in the measurement results. -In some cases—particularly in the physical -world—the attributes that we wish to measure are -easy to grasp; however, in an artificial world like -software engineering, defining the attributes may -not be that simple. For example, the attributes of -height, weight, distance, etc. are easily and uni- -formly understood (though they may not be very -easy to measure in all circumstances), whereas -attributes such as software size or complexity -require clear definitions. -_Operational definitions._ The definition of attri- -butes, to start with, is often rather abstract. Such -definitions do not facilitate measurements. For -example, we may define a circle as _a line forming -a closed loop such that the distance between any -point on this line and a fixed interior point called -the center is constant._ We may further say that the -fixed distance from the center to any point on the -closed loop gives the radius of the circle. It may be -noted that though the concept has been defined, no -means of measuring the radius has been proposed. -The operational definition specifies the exact steps -or method used to carry out a specific measure- -ment. This can also be called the _measurement -method_ ; sometimes a _measurement procedure_ may -be required to be even more precise. -The importance of operational definitions -can hardly be overstated. Take the case of the -apparently simple measurement of height of -individuals. Unless we specify various factors -like the time when the height will be measured -(it is known that the height of individuals vary -across various time points of the day), how the -variability due to hair would be taken care of, -whether the measurement will be with or without -shoes, what kind of accuracy is expected (correct -up to an inch, 1/2 inch, centimeter, etc.)—even - -``` -this simple measurement will lead to substantial -variation. Engineers must appreciate the need to -define measures from an operational perspective. -``` -``` -3.1. Levels (Scales) of Measurement -[4*, c3s2] [6*, c7s5] -``` -``` -Once the operational definitions are determined, -the actual measurements need to be undertaken. -It is to be noted that measurement may be car- -ried out in four different scales: namely, nominal, -ordinal, interval, and ratio. Brief descriptions of -each are given below. -Nominal scale: This is the lowest level of mea- -surement and represents the most unrestricted -assignment of numerals. The numerals serve only -as labels, and words or letters would serve as well. -The nominal scale of measurement involves only -classification and the observed sampling units -are put into any one of the mutually exclusive -and collectively exhaustive categories (classes). -Some examples of nominal scales are: -``` -- Job titles in a company -- The software development life cycle (SDLC) - model (like waterfall, iterative, agile, etc.) - followed by different software projects - -``` -In nominal scale, the names of the different cat- -egories are just labels and no relationship between -them is assumed. The only operations that can be -carried out on nominal scale is that of counting -the number of occurrences in the different classes -and determining if two occurrences have the same -nominal value. However, statistical analyses may -be carried out to understand how entities belong- -ing to different classes perform with respect to -some other response variable. -Ordinal scale: Refers to the measurement scale -where the different values obtained through the -process of measurement have an implicit order- -ing. The intervals between values are not speci- -fied and there is no objectively defined zero -element. Typical examples of measurements in -ordinal scales are: -``` -- Skill levels (low, medium, high) -- Capability Maturity Model Integration - (CMMI) maturity levels of software devel- - opment organizations - - -``` -Engineering Foundations 15-7 -``` -- Level of adherence to process as measured in - a 5-point scale of excellent, above average, - average, below average, and poor, indicating - the range from total adherence to no adher- - ence at all - -Measurement in ordinal scale satisfies the tran- -sitivity property in the sense that if A > B and B -> C, then A > C. However, arithmetic operations -cannot be carried out on variables measured in -ordinal scales. Thus, if we measure customer sat- -isfaction on a 5-point ordinal scale of 5 implying -a very high level of satisfaction and 1 implying a -very high level of dissatisfaction, we cannot say -that a score of four is twice as good as a score -of two. So, it is better to use terminology such -as excellent, above average, average, below aver- -age, and poor than ordinal numbers in order to -avoid the error of treating an ordinal scale as a -ratio scale. It is important to note that ordinal -scale measures are commonly misused and such -misuse can lead to erroneous conclusions [6*, -p274]. A common misuse of ordinal scale mea- -sures is to present a mean and standard deviation -for the data set, both of which are meaningless. -However, we can find the median, as computation -of the median involves counting only. -_Interval scales:_ With the interval scale, we -come to a form that is quantitative in the ordi- -nary sense of the word. Almost all the usual sta- -tistical measures are applicable here, unless they -require knowledge of a _true_ zero point. The zero -point on an interval scale is a matter of conven- -tion. Ratios do not make sense, but the difference -between levels of attributes can be computed and -is meaningful. Some examples of interval scale of -measurement follow: - -- Measurement of temperature in different - scales, such as Celsius and Fahrenheit. Sup- - pose T 1 and T 2 are temperatures measured - in some scale. We note that the fact that T 1 - is twice T 2 does not mean that one object is - twice as hot as another. We also note that the - zero points are arbitrary. -- Calendar dates. While the difference between - dates to measure the time elapsed is a mean- - ingful concept, the ratio does not make sense. -- Many psychological measurements aspire to - create interval scales. Intelligence is often - -``` -measured in interval scale, as it is not neces- -sary to define what zero intelligence would -mean. -``` -``` -If a variable is measured in interval scale, most -of the usual statistical analyses like mean, stan- -dard deviation, correlation, and regression may -be carried out on the measured values. -Ratio scale: These are quite commonly encoun- -tered in physical science. These scales of mea- -sures are characterized by the fact that operations -exist for determining all 4 relations: equality, rank -order, equality of intervals, and equality of ratios. -Once such a scale is available, its numerical val- -ues can be transformed from one unit to another -by just multiplying by a constant, e.g., conversion -of inches to feet or centimeters. When measure- -ments are being made in ratio scale, existence of -a nonarbitrary zero is mandatory. All statistical -measures are applicable to ratio scale; logarithm -usage is valid only when these scales are used, as -in the case of decibels. Some examples of ratio -measures are -``` -- the number of statements in a software - program -- temperature measured in the Kelvin (K) scale - or in Fahrenheit (F). - -``` -An additional measurement scale, the absolute -scale, is a ratio scale with uniqueness of the mea- -sure; i.e., a measure for which no transformation -is possible (for example, the number of program- -mers working on a project). -``` -``` -3.2. Direct and Derived Measures -[6*, c7s5] -``` -``` -Measures may be either direct or derived (some- -times called indirect measures). An example of -a direct measure would be a count of how many -times an event occurred, such as the number of -defects found in a software product. A derived -measure is one that combines direct measures in -some way that is consistent with the measurement -method. An example of a derived measure would -be calculating the productivity of a team as the -number of lines of code developed per developer- -month. In both cases, the measurement method -determines how to make the measurement. -``` - -**15-8** **_SWEBOK® Guide_** **V3.0** - -_3.3. Reliability and Validity_ -[4*, c3s4, c3s5] - -A basic question to be asked for any measure- -ment method is whether the proposed measure- -ment method is truly measuring the concept with -good quality. Reliability and validity are the two -most important criteria to address this question. -The reliability of a measurement method is -the extent to which the application of the mea- -surement method yields consistent measurement -results. Essentially, _reliability_ refers to the consis- -tency of the values obtained when the same item -is measured a number of times. When the results -agree with each other, the measurement method -is said to be reliable. Reliability usually depends -on the operational definition. It can be quantified -by using the index of variation, which is com- -puted as the ratio between the standard deviation -and the mean. The smaller the index, the more -reliable the measurement results. -_Validity_ refers to whether the measurement -method really measures what we intend to mea- -sure. Validity of a measurement method may -be looked at from three different perspectives: -namely, construct validity, criteria validity, and -content validity. - -_3.4. Assessing Reliability_ -[4*, c3s5] - -There are several methods for assessing reli- -ability; these include the test-retest method, the -alternative form method, the split-halves method, -and the internal consistency method. The easi- -est of these is the test-retest method. In the test- -retest method, we simply apply the measurement -method to the same subjects twice. The correla- -tion coefficient between the first and second set -of measurement results gives the reliability of the -measurement method. - -**4. Engineering Design** - [5*, c1s2, c1s3, c1s4] - -A product’s life cycle costs are largely influenced -by the design of the product. This is true for manu- -factured products as well as for software products. - -``` -The design of a software product is guided by -the features to be included and the quality attri- -butes to be provided. It is important to note that -software engineers use the term “design” within -their own context; while there are some common- -alities, there are also many differences between -engineering design as discussed in this section -and software engineering design as discussed in -the Software Design KA. The scope of engineer- -ing design is generally viewed as much broader -than that of software design. The primary aim of -this section is to identify the concepts needed to -develop a clear understanding regarding the pro- -cess of engineering design. -Many disciplines engage in problem solving -activities where there is a single correct solu- -tion. In engineering, most problems have many -solutions and the focus is on finding a feasible -solution (among the many alternatives) that -best meets the needs presented. The set of pos- -sible solutions is often constrained by explic- -itly imposed limitations such as cost, available -resources, and the state of discipline or domain -knowledge. In engineering problems, sometimes -there are also implicit constraints (such as the -physical properties of materials or laws of phys- -ics) that also restrict the set of feasible solutions -for a given problem. -``` -``` -4.1. Engineering Design in Engineering -Education -``` -``` -The importance of engineering design in engi- -neering education can be clearly seen by the high -expectations held by various accreditation bod- -ies for engineering education. Both the Cana- -dian Engineering Accreditation Board and the -Accreditation Board for Engineering and Tech- -nology (ABET) note the importance of including -engineering design in education programs. -The Canadian Engineering Accreditation -Board includes requirements for the amount of -engineering design experience/coursework that -is necessary for engineering students as well as -qualifications for the faculty members who teach -such coursework or supervise design projects. -Their accreditation criteria states: -``` - -``` -Engineering Foundations 15-9 -``` -``` -Design: An ability to design solutions for -complex, open-ended engineering prob- -lems and to design systems, components -or processes that meet specified needs with -appropriate attention to health and safety -risks, applicable standards, and economic, -environmental, cultural and societal con- -siderations. [8, p12] -``` -In a similar manner, ABET defines engineering -design as - -``` -the process of devising a system, compo- -nent, or process to meet desired needs. It -is a decision-making process (often itera- -tive), in which the basic sciences, math- -ematics, and the engineering sciences are -applied to convert resources optimally to -meet these stated needs. [9, p4] -``` -Thus, it is clear that engineering design is a -vital component in the training and education for -all engineers. The remainder of this section will -focus on various aspects of engineering design. - -_4.2. Design as a Problem Solving Activity_ -[5*, c1s4, c2s1, c3s3] - -It is to be noted that engineering design is primar- -ily a problem solving activity. Design problems -are open ended and more vaguely defined. There -are usually several alternative ways to solve the -same problem. Design is generally considered to -be a _wicked problem_ —a term first coined by Horst -Rittel in the 1960s when design methods were a -subject of intense interest. Rittel sought an alterna- -tive to the linear, step-by-step model of the design -process being explored by many designers and -design theorists and argued that most of the prob- -lems addressed by the designers are wicked prob- -lems. As explained by Steve McConnell, a wicked -problem is one that could be clearly defined only -by solving it or by solving part of it. This paradox -implies, essentially, that a wicked problem has to -be solved once in order to define it clearly and then -solved again to create a solution that works. This -has been an important insight for software design- -ers for several decades [10*, c5s1]. - -``` -4.3. Steps Involved in Engineering Design -[7*, c4] -``` -``` -Engineering problem solving begins when a -need is recognized and no existing solution will -meet that need. As part of this problem solving, -the design goals to be achieved by the solution -should be identified. Additionally, a set of accep- -tance criteria must be defined and used to deter- -mine how well a proposed solution will satisfy -the need. Once a need for a solution to a problem -has been identified, the process of engineering -design has the following generic steps: -``` -``` -a) define the problem -b) gather pertinent information -c) generate multiple solutions -d) analyze and select a solution -e) implement the solution -``` -``` -All of the engineering design steps are itera- -tive, and knowledge gained at any step in the -process may be used to inform earlier tasks and -trigger an iteration in the process. These steps are -expanded in the subsequent sections. -``` -``` -a. Define the problem. At this stage, the custom- -er’s requirements are gathered. Specific informa- -tion about product functions and features are also -closely examined. This step includes refining the -problem statement to identify the real problem to -be solved and setting the design goals and criteria -for success. -The problem definition is a crucial stage in -engineering design. A point to note is that this -step is deceptively simple. Thus, enough care -must be taken to carry out this step judiciously. It -is important to identify needs and link the success -criteria with the required product characteristics. -It is also an engineering task to limit the scope -of a problem and its solution through negotiation -among the stakeholders. -``` -``` -b. Gather pertinent information. At this stage, -the designer attempts to expand his/her knowl- -edge about the problem. This is a vital, yet often -neglected, stage. Gathering pertinent information -can reveal facts leading to a redefinition of the -``` - -**15-10** **_SWEBOK® Guide_** **V3.0** - -problem—in particular, mistakes and false starts -may be identified. This step may also involve the -decomposition of the problem into smaller, more -easily solved subproblems. -While gathering pertinent information, care -must be taken to identify how a product may be -used as well as misused. It is also important to -understand the perceived value of the product/ -service being offered. Included in the pertinent -information is a list of constraints that must be -satisfied by the solution or that may limit the set -of feasible solutions. - -_c. Generate multiple solutions._ During this stage, -different solutions to the same problem are devel- -oped. It has already been stated that design prob- -lems have multiple solutions. The goal of this -step is to conceptualize multiple possible solu- -tions and refine them to a sufficient level of detail -that a comparison can be done among them. - -_d. Analyze and select a solution._ Once alternative -solutions have been identified, they need to be ana- -lyzed to identify the solution that best suits the cur- -rent situation. The analysis includes a functional -analysis to assess whether the proposed design -would meet the functional requirements. Physical -solutions that involve human users often include -analysis of the ergonomics or user friendliness of -the proposed solution. Other aspects of the solu- -tion—such as product safety and liability, an eco- -nomic or market analysis to ensure a return (profit) -on the solution, performance predictions and anal- -ysis to meet quality characteristics, opportunities -for incorrect data input or hardware malfunctions, -and so on—may be studied. The types and amount -of analysis used on a proposed solution are depen- -dent on the type of problem and the needs that the -solution must address as well as the constraints -imposed on the design. - -_e. Implement the solution._ The final phase of the -design process is implementation. Implemen- -tation refers to development and testing of the -proposed solution. Sometimes a preliminary, -partial solution called a _prototyp_ e may be devel- -oped initially to test the proposed design solu- -tion under certain conditions. Feedback resulting -from testing a prototype may be used either to - -``` -refine the design or drive the selection of an alter- -native design solution. One of the most impor- -tant activities in design is documentation of the -design solution as well as of the tradeoffs for the -choices made in the design of the solution. This -work should be carried out in a manner such that -the solution to the design problem can be com- -municated clearly to others. -The testing and verification take us back to the -success criteria. The engineer needs to devise -tests such that the ability of the design to meet the -success criteria is demonstrated. While design- -ing the tests, the engineer must think through -different possible failure modes and then design -tests based on those failure modes. The engineer -may choose to carry out designed experiments to -assess the validity of the design. -``` -**5. Modeling, Simulation, and Prototyping** - [5*, c6] [11*, c13s3] [12*, c2s3.1] - -``` -Modeling is part of the abstraction process used -to represent some aspects of a system. Simula- -tion uses a model of the system and provides a -means of conducting designed experiments with -that model to better understand the system, its -behavior, and relationships between subsystems, -as well as to analyze aspects of the design. Mod- -eling and simulation are techniques that can be -used to construct theories or hypotheses about the -behavior of the system; engineers then use those -theories to make predictions about the system. -Prototyping is another abstraction process where -a partial representation (that captures aspects of -interest) of the product or system is built. A pro- -totype may be an initial version of the system but -lacks the full functionality of the final version. -``` -``` -5.1. Modeling -``` -``` -A model is always an abstraction of some real -or imagined artifact. Engineers use models in -many ways as part of their problem solving -activities. Some models are physical, such as a -made-to-scale miniature construction of a bridge -or building. Other models may be nonphysical -representations, such as a CAD drawing of a cog -or a mathematical model for a process. Models -help engineers reason and understand aspects of -``` - -``` -Engineering Foundations 15-11 -``` -a problem. They can also help engineers under- -stand what they do know and what they don’t -know about the problem at hand. -There are three types of models: iconic, ana- -logic, and symbolic. An iconic model is a visu- -ally equivalent but incomplete 2-dimensional -or 3-dimensional representation—for example, -maps, globes, or built-to-scale models of struc- -tures such as bridges or highways. An iconic -model actually resembles the artifact modeled. -In contrast, an analogic model is a functionally -equivalent but incomplete representation. That -is, the model behaves like the physical artifact -even though it may not physically resemble it. -Examples of analogic models include a miniature -airplane for wind tunnel testing or a computer -simulation of a manufacturing process. -Finally, a symbolic model is a higher level of -abstraction, where the model is represented using -symbols such as equations. The model captures -the relevant aspects of the process or system in -symbolic form. The symbols can then be used to -increase the engineer’s understanding of the final -system. An example is an equation such as _F = -Ma_. Such mathematical models can be used to -describe and predict properties or behavior of the -final system or product. - -_5.2. Simulation_ - -All simulation models are a specification of real- -ity. A central issue in simulation is to abstract -and specify an appropriate simplification of -reality. Developing this abstraction is of vital -importance, as misspecification of the abstrac- -tion would invalidate the results of the simulation -exercise. Simulation can be used for a variety of -testing purposes. -Simulation is classified based on the type of -system under study. Thus, simulation can be either -continuous or discrete. In the context of software -engineering, the emphasis will be primarily on -discrete simulation. Discrete simulations may -model event scheduling or process interaction. -The main components in such a model include -entities, activities and events, resources, the state -of the system, a simulation clock, and a random -number generator. Output is generated by the -simulation and must be analyzed. - -``` -An important problem in the development of a -discrete simulation is that of initialization. Before -a simulation can be run, the initial values of all -the state variables must be provided. As the simu- -lation designer may not know what initial values -are appropriate for the state variables, these val- -ues might be chosen somewhat arbitrarily. For -instance, it might be decided that a queue should -be initialized as empty and idle. Such a choice of -initial condition can have a significant but unrec- -ognized impact on the outcome of the simulation. -``` -``` -5.3. Prototyping -``` -``` -Constructing a prototype of a system is another -abstraction process. In this case, an initial version -of the system is constructed, often while the sys- -tem is being designed. This helps the designers -determine the feasibility of their design. -There are many uses for a prototype, includ- -ing the elicitation of requirements, the design and -refinement of a user interface to the system, vali- -dation of functional requirements, and so on. The -objectives and purposes for building the proto- -type will determine its construction and the level -of abstraction used. -The role of prototyping is somewhat different -between physical systems and software. With -physical systems, the prototype may actually -be the first fully functional version of a system -or it may be a model of the system. In software -engineering, prototypes are also an abstract -model of part of the software but are usually not -constructed with all of the architectural, perfor- -mance, and other quality characteristics expected -in the finished product. In either case, prototype -construction must have a clear purpose and be -planned, monitored, and controlled—it is a tech- -nique to study a specific problem within a limited -context [6*, c2s8]. -In conclusion, modeling, simulation, and pro- -totyping are powerful techniques for studying the -behavior of a system from a given perspective. -All can be used to perform designed experiments -to study various aspects of the system. How- -ever, these are abstractions and, as such, may not -model all attributes of interest. -``` - -**15-12** **_SWEBOK® Guide_** **V3.0** - -**6. Standards** - [5*, c9s3.2] [13*, c1s2] - -Moore states that a - -``` -standard can be; (a) an object or measure -of comparison that defines or represents -the magnitude of a unit; (b) a characteriza- -tion that establishes allowable tolerances -for categories of items; and (c) a degree or -level of required excellence or attainment. -Standards are definitional in nature, estab- -lished either to further understanding and -interaction or to acknowledge observed (or -desired) norms of exhibited characteristics -or behavior. [13*, p8] -``` -Standards provide requirements, specifica- -tions, guidelines, or characteristics that must be -observed by engineers so that the products, pro- -cesses, and materials have acceptable levels of -quality. The qualities that various standards pro- -vide may be those of safety, reliability, or other -product characteristics. Standards are considered -critical to engineers and engineers are expected to -be familiar with and to use the appropriate stan- -dards in their discipline. -Compliance or conformance to a standard lets -an organization say to the public that they (or -their products) meet the requirements stated in -that standard. Thus, standards divide organiza- -tions or their products into those that conform to -the standard and those that do not. For a standard -to be useful, conformance with the standard must -add value—real or perceived—to the product, -process, or effort. -Apart from the organizational goals, standards -are used for a number of other purposes such -as protecting the buyer, protecting the business, -and better defining the methods and procedures -to be followed by the practice. Standards also -provide users with a common terminology and -expectations. -There are many internationally recognized -standards-making organizations including the -International Telecommunications Union (ITU), -the International Electrotechnical Commission -(IEC), IEEE, and the International Organization -for Standardization (ISO). In addition, there are - -``` -regional and governmentally recognized organi- -zations that generate standards for that region or -country. For example, in the United States, there -are over 300 organizations that develop stan- -dards. These include organizations such as the -American National Standards Institute (ANSI), -the American Society for Testing and Materials -(ASTM), the Society of Automotive Engineers -(SAE), and Underwriters Laboratories, Inc. (UL), -as well as the US government. For more detail -on standards used in software engineering, see -Appendix B on standards. -There is a set of commonly used principles -behind standards. Standards makers attempt to -have consensus around their decisions. There is -usually an openness within the community of -interest so that once a standard has been set, there -is a good chance that it will be widely accepted. -Most standards organizations have well-defined -processes for their efforts and adhere to those -processes carefully. Engineers must be aware of -the existing standards but must also update their -understanding of the standards as those standards -change over time. -In many engineering endeavors, knowing and -understanding the applicable standards is critical -and the law may even require use of particular -standards. In these cases, the standards often rep- -resent minimal requirements that must be met by -the endeavor and thus are an element in the con- -straints imposed on any design effort. The engi- -neer must review all current standards related to -a given endeavor and determine which must be -met. Their designs must then incorporate any and -all constraints imposed by the applicable stan- -dard. Standards important to software engineers -are discussed in more detail in an appendix spe- -cifically on this subject. -``` -**7. Root Cause Analysis** - [4*, c5, c3s7, c9s8] [5*, c9s3, c9s4, c9s5] - [13*, c13s3.4.5] - -``` -Root cause analysis (RCA) is a process designed -to investigate and identify why and how an -undesirable event has happened. Root causes -are underlying causes. The investigator should -attempt to identify specific underlying causes of -the event that has occurred. The primary objective -``` - -``` -Engineering Foundations 15-13 -``` -of RCA is to prevent recurrence of the undesir- -able event. Thus, the more specific the investiga- -tor can be about why an event occurred, the easier -it will be to prevent recurrence. A common way -to identify specific underlying cause(s) is to ask a -series of _why_ questions. - -_7.1. Techniques for Conducting Root Cause -Analysis_ -[4*, c5] [5*, c3] - -There are many approaches used for both quality -control and root cause analysis. The first step in -any root cause analysis effort is to identify the real -problem. Techniques such as statement-restate- -ment, why-why diagrams, the revision method, -present state and desired state diagrams, and the -fresh-eye approach are used to identify and refine -the real problem that needs to be addressed. -Once the real problem has been identified, then -work can begin to determine the cause of the -problem. Ishikawa is known for the seven tools -for quality control that he promoted. Some of -those tools are helpful in identifying the causes -for a given problem. Those tools are check sheets -or checklists, Pareto diagrams, histograms, run -charts, scatter diagrams, control charts, and -fishbone or cause-and-effect diagrams. More -recently, other approaches for quality improve- -ment and root cause analysis have emerged. Some -examples of these newer methods are affinity dia- -grams, relations diagrams, tree diagrams, matrix -charts, matrix data analysis charts, process deci- -sion program charts, and arrow diagrams. A few -of these techniques are briefly described below. -A fishbone or cause-and-effect diagram is a -way to visualize the various factors that affect -some characteristic. The main line in the diagram -represents the problem and the connecting lines -represent the factors that led to or influenced the -problem. Those factors are broken down into sub- -factors and sub-subfactors until root causes can -be identified. - -``` -A very simple approach that is useful in quality -control is the use of a checklist. Checklists are -a list of key points in a process with tasks that -must be completed. As each task is completed, -it is checked off the list. If a problem occurs, -then sometimes the checklist can quickly identify -tasks that may have been skipped or only par- -tially completed. -Finally, relations diagrams are a means for dis- -playing complex relationships. They give visual -support to cause-and-effect thinking. The dia- -gram relates the specific to the general, revealing -key causes and key effects. -Root cause analysis aims at preventing the -recurrence of undesirable events. Reduction of -variation due to common causes requires utili- -zation of a number of techniques. An important -point to note is that these techniques should be -used offline and not necessarily in direct response -to the occurrence of some undesirable event. -Some of the techniques that may be used to -reduce variation due to common causes are given -below. -``` -1. Cause-and-effect diagrams may be used to - identify the sub and sub-sub causes. -2. Fault tree analysis is a technique that may be - used to understand the sources of failures. -3. Designed experiments may be used to under- - stand the impact of various causes on the - occurrence of undesirable events (see Empir- - ical Methods and Experimental Techniques - in this KA). -4. Various kinds of correlation analyses may be - used to understand the relationship between - various causes and their impact. These tech- - niques may be used in cases when conduct- - ing controlled experiments is difficult but - data may be gathered (see Statistical Analy- - sis in this KA). - - -**15-14** **_SWEBOK® Guide_** **V3.0** - -##### MATRIX OF TOPICS VS. REFERENCE MATERIAL - -``` -Montgomery and Runger 2007 -``` -##### [2*] - -``` -Null and Lobur 2006 -``` -##### [3*] - -``` -Kan 2002 -``` -##### [4*] - -``` -Voland 2003 -``` -##### [5*] - -``` -Fairley 2009 -``` -##### [6*] - -``` -Tockey 2004 -``` -##### [7*] - -``` -McConnell 2004 -``` -##### [10*] - -``` -Cheney and Kincaid 2007 -``` -##### [11*] - -``` -Sommerville 2011 -``` -##### [12*] - -``` -Moore 2006 -``` -##### [13*] - -**1. Empirical -Methods and -Experimental -Te c h n i que s** - -``` -c1 -``` -``` -1.1. Designed -Experiment -1.2. -Observational -Study -1.3. -Retrospective -Study -``` -**2. Statistical -Analysis** - -``` -c9s1, -c2s1 -c10s3 -``` -``` -2.1. Concept of -Unit of Analysis -(Sampling -Units), Sample, -and Population -``` -``` -c3s6, -c3s9, -c4s6, -c6s2, -c7s1, -c7s3, -c8s1, -c9s1 -2.2. Concepts of -Correlation and -Regression -``` -``` -c11s2, -c11s 8 -``` -**3. Measurement** - c3s1, - c3s2 - c4s4 c7s5 - -``` -3.1. Levels -(Scales) of -Measurement -``` -``` -c3s2 c7s5 -p442 -–447 -``` -``` -3.2. Direct -and Derived -Measures -``` - -``` -Engineering Foundations 15-15 -``` -``` -Montgomery and Runger 2007 -``` -##### [2*] - -``` -Null and Lobur 2006 -``` -##### [3*] - -``` -Kan 2002 -``` -##### [4*] - -``` -Voland 2003 -``` -##### [5*] - -``` -Fairley 2009 -``` -##### [6*] - -``` -Tockey 2004 -``` -##### [7*] - -``` -McConnell 2004 -``` -##### [10*] - -``` -Cheney and Kincaid 2007 -``` -##### [11*] - -``` -Sommerville 2011 -``` -##### [12*] - -``` -Moore 2006 -``` -##### [13*] - -``` -3.3. Reliability -a nd Va l id it y -``` -``` -c3s4, -c3s5 -3.4. Assessing -Reliability -c3s5 -``` -**4. Engineering -Design** - -``` -c1s2, -c1s3, -c1s4 -4.1. Design in -Engineering -Education -4.2. Design -as a Problem -Solving Activity -``` -``` -c1s4, -c2s1, -c3s3 -``` -``` -c5s1 -``` -``` -4.3. Steps -Involved in -Engineering -Design -``` -``` -c4 -``` -**5. Modeling, -Prototyping, and -Simulation** - -``` -c6 c13s3 -c2 -s3.1 -``` -``` -5.1. Modeling -5.2. Simulation -5.3. Prototyping -``` -**6. Standards** - c9 -s3.2 -c1s2 -**7. Root Cause -Analysis** - -``` -c5, -c3s7, -c9s8 -``` -``` -c9s3, -c9s4, -c9s5 -``` -``` -c13 -s3.4.5 -``` -``` -7.1. Te c h n i q u e s -for Conducting -Root Cause -Analysis -``` -``` -c5 c3 -``` - -**15-16** **_SWEBOK® Guide_** **V3.0** - -##### FURTHER READINGS - -A. Abran, _Software Metrics and Software -Metrology_. [14] - -This book provides very good information on the -proper use of the terms measure, measurement -method and measurement outcome. It provides -strong support material for the entire section on -Measurement. - -``` -W.G. Vincenti, What Engineers Know and How -They Know It. [15] -``` -``` -This book provides an interesting introduc- -tion to engineering foundations through a series -of case studies that show many of the founda- -tional concepts as used in real world engineering -applications. -``` - -``` -Engineering Foundations 15-17 -``` -##### REFERENCES - -[1] _ISO/IEC/IEEE 24765:2010 Systems and -Software Engineering—Vocabulary_ , ISO/ -IEC/IEEE, 2010. - -[2*] D.C. Montgomery and G.C. Runger, -_Applied Statistics and Probability for -Engineers_ , 4th ed., Wiley, 2007. - -[3*] L. Null and J. Lobur, _The Essentials of -Computer Organization and Architecture_ , -2nd ed., Jones and Bartlett Publishers, -2006. - -[4*] S.H. Kan, _Metrics and Models in Software -Quality Engineering_ , 2nd ed., Addison- -Wesley, 2002. - -[5*] G. Voland, _Engineering by Design_ , 2nd ed., -Prentice Hall, 2003. - -[6*] R.E. Fairley, _Managing and Leading -Software Projects_ , Wiley-IEEE Computer -Society Press, 2009. - -[7*] S. Tockey, _Return on Software: Maximizing -the Return on Your Software Investment_ , -Addison-Wesley, 2004. - -[8] Canadian Engineering Accreditation Board, -Engineers Canada, “Accreditation Criteria -and Procedures,” Canadian Council of -Professional Engineers, 2011; [http://www.](http://www.) -engineerscanada.ca/files/w_Accreditation_ -Criteria_Procedures_2011.pdf. - -``` -[9] ABET Engineering Accreditation -Commission, “Criteria for Accrediting -Engineering Programs, 2012-2013,” -ABET, 2011; http://www.abet.org/uploadedFiles/ -Accreditation/Accreditation_Process/ -Accreditation_Documents/Current/eac- -criteria-2012-2013.pdf. -``` -``` -[10*] S. McConnell, Code Complete , 2nd ed., -Microsoft Press, 2004. -``` -``` -[11*] E.W. Cheney and D.R. Kincaid, Numerical -Mathematics and Computing , 6th ed., -Brooks/Cole, 2007. -``` -``` -[12*] I. Sommerville, Software Engineering , 9th -ed., Addison-Wesley, 2011. -``` -``` -[13*] J.W. Moore, The Road Map to Software -Engineering: A Standards-Based Guide , -Wiley-IEEE Computer Society Press, 2006. -``` -``` -[14] A. Abran, Software Metrics and Software -Metrology , Wiley-IEEE Computer Society -Press, 2010. -``` -``` -[15] W.G. Vincenti, What Engineers Know -and How They Know It , John Hopkins -University Press, 1990. -``` blob - c5fdd5b94d51666a6510cd293c65b50c59e47ba4 (mode 644) blob + /dev/null --- 1_software_requirements.markdown +++ /dev/null @@ -1,1618 +0,0 @@ -``` -1-1 -``` -**CHAPTER 1** - -**SOFTWARE REQUIREMENTS** - -##### ACRONYMS - -##### CIA - -``` -Confidentiality, Integrity, and -Availability -DAG Directed Acyclic Graph -FSM Functional Size Measurement -``` -``` -INCOSE -International Council on Systems -Engineering -UML Unified Modeling Language -SysML Systems Modeling Language -``` -##### INTRODUCTION - -The Software Requirements knowledge area (KA) -is concerned with the elicitation, analysis, speci- -fication, and validation of software requirements -as well as the management of requirements dur- -ing the whole life cycle of the software product. -It is widely acknowledged amongst researchers -and industry practitioners that software projects -are critically vulnerable when the requirements- -related activities are poorly performed. -Software requirements express the needs and -constraints placed on a software product that -contribute to the solution of some real-world -problem. -The term “requirements engineering” is widely -used in the field to denote the systematic handling -of requirements. For reasons of consistency, the -term “engineering” will not be used in this KA -other than for software engineering per se. -For the same reason, “requirements engineer,” -a term which appears in some of the literature, -will not be used either. Instead, the term “software -engineer” or, in some specific cases, “require- -ments specialist” will be used, the latter where -the role in question is usually performed by an -individual other than a software engineer. This - -``` -does not imply, however, that a software engineer -could not perform the function. -A risk inherent in the proposed breakdown is -that a waterfall-like process may be inferred. To -guard against this, topic 2, Requirements Process, -is designed to provide a high-level overview of the -requirements process by setting out the resources -and constraints under which the process operates -and which act to configure it. -An alternate decomposition could use a prod- -uct-based structure (system requirements, soft- -ware requirements, prototypes, use cases, and -so on). The process-based breakdown reflects -the fact that the requirements process, if it is to -be successful, must be considered as a process -involving complex, tightly coupled activities -(both sequential and concurrent), rather than as a -discrete, one-off activity performed at the outset -of a software development project. -The Software Requirements KA is related -closely to the Software Design, Software Testing, -Software Maintenance, Software Configuration -Management, Software Engineering Manage- -ment, Software Engineering Process, Software -Engineering Models and Methods, and Software -Quality KAs. -``` -``` -BREAKDOWN OF TOPICS FOR -SOFTWARE REQUIREMENTS -``` -``` -The breakdown of topics for the Software -Requirements KA is shown in Figure 1.1. -``` -**1. Software Requirements Fundamentals** - [1*, c4, c4s1, c10s1, c10s4] [2*, c1, c6, c12] - -``` -1.1. Definition of a Software Requirement -``` -``` -At its most basic, a software requirement is a -property that must be exhibited by something in -``` - -**1-2** **_SWEBOK® Guide_** **V3.0** - -order to solve some problem in the real world. It -may aim to automate part of a task for someone -to support the business processes of an organiza- -tion, to correct shortcomings of existing software, -or to control a device—to name just a few of the -many problems for which software solutions are -possible. The ways in which users, business pro- -cesses, and devices function are typically complex. -By extension, therefore, the requirements on par- -ticular software are typically a complex combina- -tion from various people at different levels of an -organization, and who are in one way or another -involved or connected with this feature from the -environment in which the software will operate. -An essential property of all software require- -ments is that they be verifiable as an individual -feature as a functional requirement or at the -system level as a nonfunctional requirement. It -may be difficult or costly to verify certain soft- -ware requirements. For example, verification -of the throughput requirement on a call center -may necessitate the development of simulation -software. Software requirements, software test- -ing, and quality personnel must ensure that the - -``` -requirements can be verified within available -resource constraints. -Requirements have other attributes in addi- -tion to behavioral properties. Common examples -include a priority rating to enable tradeoffs in -the face of finite resources and a status value to -enable project progress to be monitored. Typi- -cally, software requirements are uniquely identi- -fied so that they can be subjected to software con- -figuration management over the entire life cycle -of the feature and of the software. -``` -``` -1.2. Product and Process Requirements -``` -``` -A product requirement is a need or constraint on -the software to be developed (for example, “The -software shall verify that a student meets all pre- -requisites before he or she registers for a course”). -A process requirement is essentially a con- -straint on the development of the software (for -example, “The software shall be developed using -a RUP process”). -Some software requirements generate implicit -process requirements. The choice of verification -``` -``` -Figure 1.1. Breakdown of Topics for the Software Requirements KA -``` - -``` -Software Requirements 1-3 -``` -technique is one example. Another might be the -use of particularly rigorous analysis techniques -(such as formal specification methods) to reduce -faults that can lead to inadequate reliability. Pro- -cess requirements may also be imposed directly -by the development organization, their customer, -or a third party such as a safety regulator. - -_1.3. Functional and Nonfunctional Requirements_ - -_Functional_ requirements describe the functions -that the software is to execute; for example, for- -matting some text or modulating a signal. They -are sometimes known as capabilities or features. -A functional requirement can also be described -as one for which a finite set of test steps can be -written to validate its behavior. -_Nonfunctional_ requirements are the ones that -act to constrain the solution. Nonfunctional -requirements are sometimes known as constraints -or quality requirements. They can be further clas- -sified according to whether they are performance -requirements, maintainability requirements, -safety requirements, reliability requirements, -security requirements, interoperability require- -ments or one of many other types of software -requirements (see Models and Quality Character- -istics in the Software Quality KA). - -_1.4. Emergent Properties_ - -Some requirements represent emergent proper- -ties of software—that is, requirements that can- -not be addressed by a single component but that -depend on how all the software components -interoperate. The throughput requirement for a -call center would, for example, depend on how -the telephone system, information system, and -the operators all interacted under actual operat- -ing conditions. Emergent properties are crucially -dependent on the system architecture. - -_1.5. Quantifiable Requirements_ - -Software requirements should be stated as clearly -and as unambiguously as possible, and, where -appropriate, quantitatively. It is important to -avoid vague and unverifiable requirements that - -``` -depend for their interpretation on subjective -judgment (“the software shall be reliable”; “the -software shall be user-friendly”). This is par- -ticularly important for nonfunctional require- -ments. Two examples of quantified requirements -are the following: a call center’s software must -increase the center’s throughput by 20%; and a -system shall have a probability of generating a -fatal error during any hour of operation of less -than 1 * 10−^8. The throughput requirement is at a -very high level and will need to be used to derive -a number of detailed requirements. The reliabil- -ity requirement will tightly constrain the system -architecture. -``` -``` -1.6. System Requirements and Software -Requirements -``` -``` -In this topic, “system” means -``` -``` -an interacting combination of elements -to accomplish a defined objective. These -include hardware, software, firmware, -people, information, techniques, facilities, -services, and other support elements, -``` -``` -as defined by the International Council on Soft- -ware and Systems Engineering (INCOSE) [3]. -System requirements are the requirements for -the system as a whole. In a system containing -software components, software requirements are -derived from system requirements. -This KA defines “user requirements” in a -restricted way, as the requirements of the sys- -tem’s customers or end users. System require- -ments, by contrast, encompass user requirements, -requirements of other stakeholders (such as regu- -latory authorities), and requirements without an -identifiable human source. -``` -**2. Requirements Process** - [1*, c4s4] [2*, c1–4, c6, c22, c23] - -``` -This section introduces the software requirements -process, orienting the remaining five topics and -showing how the requirements process dovetails -with the overall software engineering process. -``` - -**1-4** **_SWEBOK® Guide_** **V3.0** - -_2.1. Process Models_ - -The objective of this topic is to provide an under- -standing that the requirements process - -- is not a discrete front-end activity of the soft- - ware life cycle, but rather a process initiated - at the beginning of a project that continues to - be refined throughout the life cycle; -- identifies software requirements as configu- - ration items and manages them using the - same software configuration management - practices as other products of the software - life cycle processes; -- needs to be adapted to the organization and - project context. - -In particular, the topic is concerned with how -the activities of elicitation, analysis, specifica- -tion, and validation are configured for different -types of projects and constraints. The topic also -includes activities that provide input into the -requirements process, such as marketing and fea- -sibility studies. - -_2.2. Process Actors_ - -This topic introduces the roles of the people who -participate in the requirements process. This pro- -cess is fundamentally interdisciplinary, and the -requirements specialist needs to mediate between -the domain of the stakeholder and that of soft- -ware engineering. There are often many people -involved besides the requirements specialist, each -of whom has a stake in the software. The stake- -holders will vary across projects, but will always -include users/operators and customers (who need -not be the same). -Typical examples of software stakeholders -include (but are not restricted to) the following: - -- Users: This group comprises those who will - operate the software. It is often a heteroge- - neous group involving people with different - roles and requirements. -- Customers: This group comprises those who - have commissioned the software or who rep- - resent the software’s target market. -- Market analysts: A mass-market product - will not have a commissioning customer, so - -``` -marketing people are often needed to estab- -lish what the market needs and to act as -proxy customers. -``` -- Regulators: Many application domains, such - as banking and public transport, are regu- - lated. Software in these domains must com- - ply with the requirements of the regulatory - authorities. -- Software engineers: These individuals have - a legitimate interest in profiting from devel- - oping the software by, for example, reusing - components in or from other products. If, - in this scenario, a customer of a particu- - lar product has specific requirements that - compromise the potential for component - reuse, the software engineers must carefully - weigh their own stake against those of the - customer. Specific requirements, particu- - larly constraints, may have major impact on - project cost or delivery because they either - fit well or poorly with the skill set of the - engineers. Important tradeoffs among such - requirements should be identified. - -``` -It will not be possible to perfectly satisfy the -requirements of every stakeholder, and it is the -software engineer’s job to negotiate tradeoffs that -are both acceptable to the principal stakeholders -and within budgetary, technical, regulatory, and -other constraints. A prerequisite for this is that all -the stakeholders be identified, the nature of their -“stake” analyzed, and their requirements elicited. -``` -``` -2.3. Process Support and Management -``` -``` -This section introduces the project management -resources required and consumed by the require- -ments process. It establishes the context for the -first topic (Initiation and Scope Definition) of the -Software Engineering Management KA. Its prin- -cipal purpose is to make the link between the pro- -cess activities identified in 2.1 and the issues of -cost, human resources, training, and tools. -``` -``` -2.4. Process Quality and Improvement -``` -``` -This topic is concerned with the assessment of -the quality and improvement of the requirements -process. Its purpose is to emphasize the key role -the requirements process plays in terms of the -``` - -``` -Software Requirements 1-5 -``` -cost and timeliness of a software product and of -the customer’s satisfaction with it. It will help to -orient the requirements process with quality stan- -dards and process improvement models for soft- -ware and systems. Process quality and improve- -ment is closely related to both the Software -Quality KA and Software Engineering Process -KA, comprising - -- requirements process coverage by process - improvement standards and models; -- requirements process measures and - benchmarking; -- improvement planning and implementation; -- security/CIA improvement/planning and - implementation. -**3. Requirements Elicitation** -[1*, c4s5] [2*, c5, c6, c9] - -Requirements elicitation is concerned with the -origins of software requirements and how the -software engineer can collect them. It is the first -stage in building an understanding of the problem -the software is required to solve. It is fundamen- -tally a human activity and is where the stakehold- -ers are identified and relationships established -between the development team and the customer. -It is variously termed “requirements capture,” -“requirements discovery,” and “requirements -acquisition.” -One of the fundamental principles of a good -requirements elicitation process is that of effec- -tive communication between the various stake- -holders. This communication continues through -the entire Software Development Life Cycle -(SDLC) process with different stakeholders at -different points in time. Before development -begins, requirements specialists may form the -conduit for this communication. They must medi- -ate between the domain of the software users (and -other stakeholders) and the technical world of the -software engineer. A set of internally consistent -models at different levels of abstraction facilitate -communications between software users/stake- -holders and software engineers. -A critical element of requirements elicitation is -informing the project scope. This involves provid- -ing a description of the software being specified -and its purpose and prioritizing the deliverables - -``` -to ensure the customer’s most important business -needs are satisfied first. This minimizes the risk -of requirements specialists spending time elicit- -ing requirements that are of low importance, or -those that turn out to be no longer relevant when -the software is delivered. On the other hand, the -description must be scalable and extensible to -accept further requirements not expressed in the -first formal lists and compatible with the previous -ones as contemplated in recursive methods. -``` -``` -3.1. Requirements Sources -``` -``` -Requirements have many sources in typical soft- -ware, and it is essential that all potential sources -be identified and evaluated. This topic is designed -to promote awareness of the various sources of -software requirements and of the frameworks for -managing them. The main points covered are as -follows: -``` -- Goals. The term “goal” (sometimes called - “business concern” or “critical success fac- - tor”) refers to the overall, high-level objec- - tives of the software. Goals provide the moti- - vation for the software but are often vaguely - formulated. Software engineers need to pay - particular attention to assessing the value - (relative to priority) and cost of goals. A fea- - sibility study is a relatively low-cost way of - doing this. -- Domain knowledge. The software engineer - needs to acquire or have available knowl- - edge about the application domain. Domain - knowledge provides the background against - which all elicited requirements knowledge - must be set in order to understand it. It’s - a good practice to emulate an ontological - approach in the knowledge domain. Rela- - tions between relevant concepts within the - application domain should be identified. -- Stakeholders (see section 2.2, Process - Actors). Much software has proved unsat- - isfactory because it has stressed the require- - ments of one group of stakeholders at the - expense of others. Hence, the delivered - software is difficult to use, or subverts the - cultural or political structures of the cus- - tomer organization. The software engineer - needs to identify, represent, and manage - - -**1-6** **_SWEBOK® Guide_** **V3.0** - -``` -the “viewpoints” of many different types of -stakeholders. -``` -- Business rules. These are statements that - define or constrain some aspect of the struc- - ture or the behavior of the business itself. “A - student cannot register in next semester’s - courses if there remain some unpaid tuition - fees” would be an example of a business rule - that would be a requirement source for a uni- - versity’s course-registration software. -- The operational environment. Requirements - will be derived from the environment in - which the software will be executed. These - may be, for example, timing constraints - in real-time software or performance con- - straints in a business environment. These - must be sought out actively because they can - greatly affect software feasibility and cost as - well as restrict design choices. -- The organizational environment. Software - is often required to support a business pro- - cess, the selection of which may be condi- - tioned by the structure, culture, and internal - politics of the organization. The software - engineer needs to be sensitive to these since, - in general, new software should not force - unplanned change on the business process. - -_3.2. Elicitation Techniques_ - -Once the requirements sources have been iden- -tified, the software engineer can start eliciting -requirements information from them. Note that -requirements are seldom elicited ready-made. -Rather, the software engineer elicits information -from which he or she formulates requirements. -This topic concentrates on techniques for getting -human stakeholders to articulate requirements- -relevant information. It is a very difficult task and -the software engineer needs to be sensitized to the -fact that (for example) users may have difficulty -describing their tasks, may leave important infor- -mation unstated, or may be unwilling or unable to -cooperate. It is particularly important to understand -that elicitation is not a passive activity and that, -even if cooperative and articulate stakeholders are -available, the software engineer has to work hard -to elicit the right information. Many business or -technical requirements are tacit or in feedback that - -``` -has yet to be obtained from end users. The impor- -tance of planning, verification, and validation in -requirements elicitation cannot be overstated. A -number of techniques exist for requirements elici- -tation; the principal ones are these: -``` -- Interviews. Interviewing stakeholders is a - “traditional” means of eliciting requirements. - It is important to understand the advantages - and limitations of interviews and how they - should be conducted. -- Scenarios. Scenarios provide a valuable - means for providing context to the elicita- - tion of user requirements. They allow the - software engineer to provide a framework - for questions about user tasks by permitting - “what if” and “how is this done” questions - to be asked. The most common type of sce- - nario is the use case description. There is a - link here to topic 4.2 (Conceptual Modeling) - because scenario notations such as use case - diagrams are common in modeling software. -- Prototypes. This technique is a valuable tool - for clarifying ambiguous requirements. They - can act in a similar way to scenarios by pro- - viding users with a context within which they - can better understand what information they - need to provide. There is a wide range of - prototyping techniques—from paper mock- - ups of screen designs to beta-test versions of - software products—and a strong overlap of - their separate uses for requirements elicita- - tion and for requirements validation (see - section 6.2, Prototyping). Low fidelity proto- - types are often preferred to avoid stakeholder - “anchoring” on minor, incidental character- - istics of a higher quality prototype that can - limit design flexibility in unintended ways. -- Facilitated meetings. The purpose of these - meetings is to try to achieve a summative - effect, whereby a group of people can bring - more insight into their software require- - ments than by working individually. They - can brainstorm and refine ideas that may be - difficult to bring to the surface using inter- - views. Another advantage is that conflicting - requirements surface early on in a way that - lets the stakeholders recognize where these - occur. When it works well, this technique - - -``` -Software Requirements 1-7 -``` -``` -may result in a richer and more consistent -set of requirements than might otherwise -be achievable. However, meetings need to -be handled carefully (hence the need for a -facilitator) to prevent a situation in which -the critical abilities of the team are eroded -by group loyalty, or in which requirements -reflecting the concerns of a few outspoken -(and perhaps senior) people that are favored -to the detriment of others. -``` -- Observation. The importance of software - context within the organizational environ- - ment has led to the adaptation of observa- - tional techniques such as ethnography for - requirements elicitation. Software engineers - learn about user tasks by immersing them- - selves in the environment and observing how - users perform their tasks by interacting with - each other and with software tools and other - resources. These techniques are relatively - expensive but also instructive because they - illustrate that many user tasks and business - processes are too subtle and complex for - their actors to describe easily. -- User stories. This technique is commonly - used in adaptive methods (see Agile Meth- - ods in the Software Engineering Models - and Methods KA) and refers to short, high- - level descriptions of required functionality - expressed in customer terms. A typical user - story has the form: _“As a , I want_ - _ so that .”_ A user - story is intended to contain just enough infor- - mation so that the developers can produce a - reasonable estimate of the effort to imple- - ment it. The aim is to avoid some of the waste - that often happens in projects where detailed - requirements are gathered early but become - invalid before the work begins. Before a user - story is implemented, an appropriate accep- - tance procedure must be written by the cus- - tomer to determine whether the goals of the - user story have been fulfilled. -- Other techniques. A range of other techniques - for supporting the elicitation of requirements - information exist and range from analyzing - competitors’ products to applying data min- - ing techniques to using sources of domain - knowledge or customer request databases. - **4. Requirements Analysis** - [1*, c4s1, c4s5, c10s4, c12s5] - [2*, c7, c11, c12, c17] - -``` -This topic is concerned with the process of ana- -lyzing requirements to -``` -- detect and resolve conflicts between - requirements; -- discover the bounds of the software and how - it must interact with its organizational and - operational environment; -- elaborate system requirements to derive soft- - ware requirements. - -``` -The traditional view of requirements analysis -has been that it be reduced to conceptual model- -ing using one of a number of analysis methods, -such as the structured analysis method. While -conceptual modeling is important, we include the -classification of requirements to help inform trad- -eoffs between requirements (requirements clas- -sification) and the process of establishing these -tradeoffs (requirements negotiation). -Care must be taken to describe requirements -precisely enough to enable the requirements to -be validated, their implementation to be verified, -and their costs to be estimated. -``` -``` -4.1. Requirements Classification -``` -``` -Requirements can be classified on a number of -dimensions. Examples include the following: -``` -- Whether the requirement is functional or - nonfunctional (see section 1.3, Functional - and Nonfunctional Requirements). -- Whether the requirement is derived from one - or more high-level requirements or an emer- - gent property (see section 1.4, Emergent - Properties), or is being imposed directly on - the software by a stakeholder or some other - source. -- Whether the requirement is on the product - or the process (see section 1.2, Product and - Process Requirements). Requirements on the - process can constrain the choice of contrac- - tor, the software engineering process to be - adopted, or the standards to be adhered to. - - -**1-8** **_SWEBOK® Guide_** **V3.0** - -- The requirement priority. The higher the pri- - ority, the more essential the requirement is - for meeting the overall goals of the software. - Often classified on a fixed-point scale such - as mandatory, highly desirable, desirable, - or optional, the priority often has to be bal- - anced against the cost of development and - implementation. -- The scope of the requirement. Scope refers - to the extent to which a requirement affects - the software and software components. - Some requirements, particularly certain - nonfunctional ones, have a global scope in - that their satisfaction cannot be allocated to - a discrete component. Hence, a requirement - with global scope may strongly affect the - software architecture and the design of many - components, whereas one with a narrow - scope may offer a number of design choices - and have little impact on the satisfaction of - other requirements. -- Volatility/stability. Some requirements will - change during the life cycle of the soft- - ware—and even during the development - process itself. It is useful if some estimate - of the likelihood that a requirement will - change can be made. For example, in a bank- - ing application, requirements for functions - to calculate and credit interest to customers’ - accounts are likely to be more stable than a - requirement to support a particular kind of - tax-free account. The former reflects a fun- - damental feature of the banking domain (that - accounts can earn interest), while the latter - may be rendered obsolete by a change to - government legislation. Flagging potentially - volatile requirements can help the software - engineer establish a design that is more toler- - ant of change. - -Other classifications may be appropriate, -depending upon the organization’s normal prac- -tice and the application itself. -There is a strong overlap between requirements -classification and requirements attributes (see -section 7.3, Requirements Attributes). - -``` -4.2. Conceptual Modeling -``` -``` -The development of models of a real-world -problem is key to software requirements analy- -sis. Their purpose is to aid in understanding the -situation in which the problem occurs, as well as -depicting a solution. Hence, conceptual models -comprise models of entities from the problem -domain, configured to reflect their real-world -relationships and dependencies. This topic is -closely related to the Software Engineering Mod- -els and Methods KA. -Several kinds of models can be developed. -These include use case diagrams, data flow mod- -els, state models, goal-based models, user inter- -actions, object models, data models, and many -others. Many of these modeling notations are part -of the Unified Modeling Language (UML). Use -case diagrams, for example, are routinely used -to depict scenarios where the boundary separates -the actors (users or systems in the external envi- -ronment) from the internal behavior where each -use case depicts a functionality of the system. -The factors that influence the choice of model- -ing notation include these: -``` -- The nature of the problem. Some types of - software demand that certain aspects be ana- - lyzed particularly rigorously. For example, - state and parametric models, which are part - of SysML [4], are likely to be more impor- - tant for real-time software than for informa- - tion systems, while it would usually be the - opposite for object and activity models. -- The expertise of the software engineer. It is - often more productive to adopt a modeling - notation or method with which the software - engineer has experience. -- The process requirements of the customer - (see section 1.2, Product and Process - Requirements). Customers may impose their - favored notation or method or prohibit any - with which they are unfamiliar. This factor - can conflict with the previous factor. - -``` -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- -text in its operational environment and to identify- -ing its interfaces with the environment. -This subtopic does not seek to “teach” a particu- -lar modeling style or notation but rather provides -guidance on the purpose and intent of modeling. - -_4.3. Architectural Design and Requirements -Allocation_ - -At some point, the solution architecture must -be derived. Architectural design is the point at -which the requirements process overlaps with -software or systems design and illustrates how -impossible it is to cleanly decouple the two tasks. -This topic is closely related to Software Structure -and Architecture in the Software Design KA. In -many cases, the software engineer acts as soft- -ware architect because the process of analyzing -and elaborating the requirements demands that -the architecture/design components that will be -responsible for satisfying the requirements be -identified. This is requirements allocation–the -assignment to architecture components respon- -sible for satisfying the requirements. -Allocation is important to permit detailed anal- -ysis of requirements. Hence, for example, once a -set of requirements has been allocated to a com- -ponent, the individual requirements can be further -analyzed to discover further requirements on how -the component needs to interact with other com- -ponents in order to satisfy the allocated require- -ments. In large projects, allocation stimulates a -new round of analysis for each subsystem. As an -example, requirements for a particular braking -performance for a car (braking distance, safety in -poor driving conditions, smoothness of applica- -tion, pedal pressure required, and so on) may be -allocated to the braking hardware (mechanical -and hydraulic assemblies) and an antilock braking -system (ABS). Only when a requirement for an -antilock braking system has been identified, and -the requirements allocated to it, can the capabili- -ties of the ABS, the braking hardware, and emer- -gent properties (such as car weight) be used to -identify the detailed ABS software requirements. -Architectural design is closely identified with -conceptual modeling (see section 4.2, Conceptual -Modeling). - -``` -4.4. Requirements Negotiation -``` -``` -Another term commonly used for this subtopic -is “conflict resolution.” This concerns resolv- -ing problems with requirements where conflicts -occur between two stakeholders requiring mutu- -ally incompatible features, between requirements -and resources, or between functional and non- -functional requirements, for example. In most -cases, it is unwise for the software engineer to -make a unilateral decision, so it becomes neces- -sary to consult with the stakeholder(s) to reach a -consensus on an appropriate tradeoff. It is often -important, for contractual reasons, that such deci- -sions be traceable back to the customer. We have -classified this as a software requirements analy- -sis topic because problems emerge as the result -of analysis. However, a strong case can also be -made for considering it a requirements validation -topic (see topic 6, Requirements Validation). -Requirements prioritization is necessary, not -only as a means to filter important requirements, -but also in order to resolve conflicts and plan for -staged deliveries, which means making complex -decisions that require detailed domain knowledge -and good estimation skills. However, it is often -difficult to get real information that can act as -a basis for such decisions. In addition, require- -ments often depend on each other, and priori- -ties are relative. In practice, software engineers -perform requirements prioritization frequently -without knowing about all the requirements. -Requirements prioritization may follow a cost- -value approach that involves an analysis from -the stakeholders defining in a scale the benefits -or the aggregated value that the implementa- -tion of the requirement brings them, versus the -penalties of not having implemented a particular -requirement. It also involves an analysis from -the software engineers estimating in a scale the -cost of implementing each requirement, relative -to other requirements. Another requirements pri- -oritization approach called the analytic hierarchy -process involves comparing all unique pairs of -requirements to determine which of the two is of -higher priority, and to what extent. -``` - -**1-10** **_SWEBOK® Guide_** **V3.0** - -_4.5. Formal Analysis_ - -Formal analysis concerns not only topic 4, but -also sections 5.3 and 6.3. This topic is also related -to Formal Methods in the Software Engineering -Models and Methods Knowledge Area. -Formal analysis has made an impact on some -application domains, particularly those of high- -integrity systems. The formal expression of -requirements requires a language with formally -defined semantics. The use of a formal analysis -for requirements expression has two benefits. -First, it enables requirements expressed in the -language to be specified precisely and unambigu- -ously, thus (in principle) avoiding the potential -for misinterpretation. Secondly, requirements can -be reasoned over, permitting desired properties -of the specified software to be proven. Formal -reasoning requires tool support to be practicable -for anything other than trivial systems, and tools -generally fall into two types: theorem provers or -model checkers. In neither case can proof be fully -automated, and the level of competence in formal -reasoning needed in order to use the tools restricts -the wider application of formal analysis. -Most formal analysis is focused on relatively -late stages of requirements analysis. It is gener- -ally counterproductive to apply formalization -until the business goals and user requirements -have come into sharp focus through means such -as those described elsewhere in section 4. How- -ever, once the requirements have stabilized and -have been elaborated to specify concrete proper- -ties of the software, it may be beneficial to for- -malize at least the critical requirements. This per- -mits static validation that the software specified -by the requirements does indeed have the proper- -ties (for example, absence of deadlock) that the -customer, users, and software engineer expect it -to have. - -**5. Requirements Specification** - [1*, c4s2, c4s3, c12s2–5] [2*, c10] - -For most engineering professions, the term “spec- -ification” refers to the assignment of numerical -values or limits to a product’s design goals. In -software engineering, “software requirements -specification” typically refers to the production of - -``` -a document that can be systematically reviewed, -evaluated, and approved. For complex systems, -particularly those involving substantial nonsoft- -ware components, as many as three different -types of documents are produced: system defini- -tion, system requirements, and software require- -ments. For simple software products, only the -third of these is required. All three documents are -described here, with the understanding that they -may be combined as appropriate. A description of -systems engineering can be found in the Related -Disciplines of Software Engineering chapter of -this Guide. -``` -``` -5.1. System Definition Document -``` -``` -This document (sometimes known as the user -requirements document or concept of operations -document) records the system requirements. It -defines the high-level system requirements from -the domain perspective. Its readership includes -representatives of the system users/customers -(marketing may play these roles for market- -driven software), so its content must be couched -in terms of the domain. The document lists the -system requirements along with background -information about the overall objectives for the -system, its target environment, and a statement of -the constraints, assumptions, and nonfunctional -requirements. It may include conceptual models -designed to illustrate the system context, usage -scenarios, and the principal domain entities, as -well as workflows. -``` -``` -5.2. System Requirements Specification -``` -``` -Developers of systems with substantial software -and nonsoftware components—a modern air- -liner, for example—often separate the descrip- -tion of system requirements from the description -of software requirements. In this view, system -requirements are specified, the software require- -ments are derived from the system requirements, -and then the requirements for the software com- -ponents are specified. Strictly speaking, system -requirements specification is a systems engineer- -ing activity and falls outside the scope of this -Guide. -``` - -``` -Software Requirements 1-11 -``` -_5.3. Software Requirements Specification_ - -Software requirements specification establishes -the basis for agreement between customers and -contractors or suppliers (in market-driven proj- -ects, these roles may be played by the marketing -and development divisions) on what the software -product is to do as well as what it is not expected -to do. -Software requirements specification permits -a rigorous assessment of requirements before -design can begin and reduces later redesign. It -should also provide a realistic basis for estimat- -ing product costs, risks, and schedules. -Organizations can also use a software require- -ments specification document as the basis for -developing effective verification and validation -plans. -Software requirements specification provides -an informed basis for transferring a software prod- -uct to new users or software platforms. Finally, it -can provide a basis for software enhancement. -Software requirements are often written in -natural language, but, in software requirements -specification, this may be supplemented by for- -mal or semiformal descriptions. Selection of -appropriate notations permits particular require- -ments and aspects of the software architecture to -be described more precisely and concisely than -natural language. The general rule is that nota- -tions should be used that allow the requirements -to be described as precisely as possible. This is -particularly crucial for safety-critical, regulatory, -and certain other types of dependable software. -However, the choice of notation is often con- -strained by the training, skills, and preferences of -the document’s authors and readers. -A number of quality indicators have been -developed that can be used to relate the quality -of software requirements specification to other -project variables such as cost, acceptance, per- -formance, schedule, and reproducibility. Quality -indicators for individual software requirements -specification statements include imperatives, -directives, weak phrases, options, and continu- -ances. Indicators for the entire software require- -ments specification document include size, read- -ability, specification, depth, and text structure. - -**6. Requirements Validation** - [1*, c4s6] [2*, c13, c15] - -``` -The requirements documents may be subject to val- -idation and verification procedures. The require- -ments may be validated to ensure that the software -engineer has understood the requirements; it is -also important to verify that a requirements docu- -ment conforms to company standards and that it -is understandable, consistent, and complete. In -cases where documented company standards or -terminology are inconsistent with widely accepted -standards, a mapping between the two should be -agreed on and appended to the document. -Formal notations offer the important advantage -of permitting the last two properties to be proven -(in a restricted sense, at least). Different stake- -holders, including representatives of the customer -and developer, should review the document(s). -Requirements documents are subject to the same -configuration management practices as the other -deliverables of the software life cycle processes. -When practical, the individual requirements are -also subject to configuration management, gener- -ally using a requirements management tool (see -topic 8, Software Requirements Tools). -It is normal to explicitly schedule one or more -points in the requirements process where the -requirements are validated. The aim is to pick up -any problems before resources are committed to -addressing the requirements. Requirements vali- -dation is concerned with the process of examin- -ing the requirements document to ensure that it -defines the right software (that is, the software -that the users expect). -``` -``` -6.1. Requirements Reviews -``` -``` -Perhaps the most common means of validation -is by inspection or reviews of the requirements -document(s). A group of reviewers is assigned -a brief to look for errors, mistaken assumptions, -lack of clarity, and deviation from standard prac- -tice. The composition of the group that conducts -the review is important (at least one represen- -tative of the customer should be included for a -customer-driven project, for example), and it may -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 -the system definition document, the system spec- -ification document, the software requirements -specification document, the baseline specifica- -tion for a new release, or at any other step in the -process. - -_6.2. Prototyping_ - -Prototyping is commonly a means for validating -the software engineer’s interpretation of the soft- -ware requirements, as well as for eliciting new -requirements. As with elicitation, there is a range -of prototyping techniques and a number of points -in the process where prototype validation may -be appropriate. The advantage of prototypes is -that they can make it easier to interpret the soft- -ware engineer’s assumptions and, where needed, -give useful feedback on why they are wrong. For -example, the dynamic behavior of a user inter- -face can be better understood through an ani- -mated prototype than through textual description -or graphical models. The volatility of a require- -ment that is defined after prototyping has been -done is extremely low because there is agreement -between the stakeholder and the software engi- -neer—therefore, for safety-critical and crucial -features prototyping would really help. There are -also disadvantages, however. These include the -danger of users’ attention being distracted from -the core underlying functionality by cosmetic -issues or quality problems with the prototype. For -this reason, some advocate prototypes that avoid -software, such as flip-chart-based mockups. Pro- -totypes may be costly to develop. However, if -they avoid the wastage of resources caused by -trying to satisfy erroneous requirements, their -cost can be more easily justified. Early proto- -types may contain aspects of the final solution. -Prototypes may be evolutionary as opposed to -throwaway. - -_6.3. Model Validation_ - -It is typically necessary to validate the quality of -the models developed during analysis. For exam- -ple, in object models, it is useful to perform a -static analysis to verify that communication paths -exist between objects that, in the stakeholders’ - -``` -domain, exchange data. If formal analysis nota- -tions are used, it is possible to use formal reason- -ing to prove specification properties. This topic is -closely related to the Software Engineering Mod- -els and Methods KA. -``` -``` -6.4. Acceptance Tests -``` -``` -An essential property of a software requirement -is that it should be possible to validate that the -finished product satisfies it. Requirements that -cannot be validated are really just “wishes.” An -important task is therefore planning how to ver- -ify each requirement. In most cases, designing -acceptance tests does this for how end-users typi- -cally conduct business using the system. -Identifying and designing acceptance tests -may be difficult for nonfunctional requirements -(see section 1.3, Functional and Nonfunctional -Requirements). To be validated, they must first -be analyzed and decomposed to the point where -they can be expressed quantitatively. -Additional information can be found in Accep- -tance/Qualification/Conformance Testing in the -Software Testing KA. -``` -**7. Practical Considerations** - [1*, c4s1, c4s4, c4s6, c4s7] -[2*, c3, c12, c14, c16, c18–21] - -``` -The first level of topic decomposition pre- -sented in this KA may seem to describe a linear -sequence of activities. This is a simplified view -of the process. -The requirements process spans the whole -software life cycle. Change management and the -maintenance of the requirements in a state that -accurately mirrors the software to be built, or that -has been built, are key to the success of the soft- -ware engineering process. -Not every organization has a culture of docu- -menting and managing requirements. It is com- -mon in dynamic start-up companies, driven by a -strong “product vision” and limited resources, to -view requirements documentation as unnecessary -overhead. Most often, however, as these compa- -nies expand, as their customer base grows, and -as their product starts to evolve, they discover -that they need to recover the requirements that -``` - -``` -Software Requirements 1-13 -``` -motivated product features in order to assess the -impact of proposed changes. Hence, requirements -documentation and change management are key -to the success of any requirements process. - -_7.1. Iterative Nature of the Requirements -Process_ - -There is general pressure in the software indus- -try for ever shorter development cycles, and this -is particularly pronounced in highly competitive, -market-driven sectors. Moreover, most projects -are constrained in some way by their environment, -and many are upgrades to, or revisions of, exist- -ing software where the architecture is a given. In -practice, therefore, it is almost always impractical -to implement the requirements process as a linear, -deterministic process in which software require- -ments are elicited from the stakeholders, base- -lined, allocated, and handed over to the software -development team. It is certainly a myth that the -requirements for large software projects are ever -perfectly understood or perfectly specified. -Instead, requirements typically iterate towards -a level of quality and detail that is sufficient to -permit design and procurement decisions to be -made. In some projects, this may result in the -requirements being baselined before all their -properties are fully understood. This risks expen- -sive rework if problems emerge late in the soft- -ware engineering process. However, software -engineers are necessarily constrained by project -management plans and must therefore take steps -to ensure that the “quality” of the requirements is -as high as possible given the available resources. -They should, for example, make explicit any -assumptions that underpin the requirements as -well as any known problems. -For software products that are developed iter- -atively, a project team may baseline only those -requirements needed for the current iteration. The -requirements specialist can continue to develop -requirements for future iterations, while develop- -ers proceed with design and construction of the -current iteration. This approach provides custom- -ers with business value quickly, while minimiz- -ing the cost of rework. -In almost all cases, requirements understanding -continues to evolve as design and development - -``` -proceeds. This often leads to the revision of -requirements late in the life cycle. Perhaps the -most crucial point in understanding software -requirements is that a significant proportion of -the requirements will change. This is sometimes -due to errors in the analysis, but it is frequently an -inevitable consequence of change in the “environ- -ment”—for example, the customer’s operating -or business environment, regulatory processes -imposed by the authorities, or the market into -which software must sell. Whatever the cause, it is -important to recognize the inevitability of change -and take steps to mitigate its effects. Change has -to be managed by ensuring that proposed changes -go through a defined review and approval pro- -cess and by applying careful requirements trac- -ing, impact analysis, and software configuration -management (see the Software Configuration -Management KA). Hence, the requirements pro- -cess is not merely a front-end task in software -development, but spans the whole software life -cycle. In a typical project, the software require- -ments activities evolve over time from elicitation -to change management. A combination of top- -down analysis and design methods and bottom- -up implementation and refactoring methods that -meet in the middle could provide the best of both -worlds. However, this is difficult to achieve in -practice, as it depends heavily upon the maturity -and expertise of the software engineers. -``` -``` -7.2. Change Management -``` -``` -Change management is central to the management -of requirements. This topic describes the role of -change management, the procedures that need to -be in place, and the analysis that should be applied -to proposed changes. It has strong links to the Soft- -ware Configuration Management KA. -``` -``` -7.3. Requirements Attributes -``` -``` -Requirements should consist not only of a speci- -fication of what is required, but also of ancillary -information, which helps manage and interpret -the requirements. Requirements attributes must -be defined, recorded, and updated as the soft- -ware under development or maintenance evolves. -This should include the various classification -``` - -**1-14** **_SWEBOK® Guide_** **V3.0** - -dimensions of the requirement (see section 4.1, -Requirements Classification) and the verification -method or relevant acceptance test plan section. -It may also include additional information, such -as a summary rationale for each requirement, the -source of each requirement, and a change history. -The most important requirements attribute, how- -ever, is an identifier that allows the requirements -to be uniquely and unambiguously identified. - -_7.4. Requirements Tracing_ - -Requirements tracing is concerned with recover- -ing the source of requirements and predicting the -effects of requirements. Tracing is fundamental -to performing impact analysis when requirements -change. A requirement should be traceable back- -ward to the requirements and stakeholders that -motivated it (from a software requirement back -to the system requirement(s) that it helps satisfy, -for example). Conversely, a requirement should -be traceable forward into the requirements and -design entities that satisfy it (for example, from -a system requirement into the software require- -ments that have been elaborated from it, and on -into the code modules that implement it, or the -test cases related to that code and even a given -section on the user manual which describes the -actual functionality) and into the test case that -verifies it. -The requirements tracing for a typical proj- -ect will form a complex directed acyclic graph -(DAG) (see Graphs in the Computing Founda- -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. - -``` -7.5. Measuring Requirements -``` -``` -As a practical matter, it is typically useful to have -some concept of the “volume” of the require- -ments for a particular software product. This -number is useful in evaluating the “size” of a -change in requirements, in estimating the cost of -a development or maintenance task, or simply for -use as the denominator in other measurements. -Functional size measurement (FSM) is a tech- -nique for evaluating the size of a body of func- -tional requirements. -Additional information on size measurement -and standards will be found in the Software Engi- -neering Process KA. -``` -**8. Software Requirements Tools** - -``` -Tools for dealing with software requirements fall -broadly into two categories: tools for modeling -and tools for managing requirements. -Requirements management tools typically sup- -port a range of activities—including documenta- -tion, tracing, and change management—and have -had a significant impact on practice. Indeed, trac- -ing and change management are really only prac- -ticable if supported by a tool. Since requirements -management is fundamental to good require- -ments practice, many organizations have invested -in requirements management tools, although -many more manage their requirements in more -ad hoc and generally less satisfactory ways (e.g., -using spreadsheets). -``` - -``` -Software Requirements 1-15 -``` -##### MATRIX OF TOPICS VS. REFERENCE MATERIAL - -``` -Sommerville 2011 -``` -##### [1*] - -``` -Wiegers 2003 -``` -##### [2*] - -**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 c10 s1 - 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 - -``` -5.2. System Requirements Specification -``` -``` -c4s2, c12s2, -c12s3, c12s4, -c12s5 -``` -``` -c10 -``` -``` -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** - -``` -Sommerville 2011 -``` -##### [1*] - -``` -Wiegers 2003 -``` -##### [2*] - -**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 -Requirements_ [5]. - -An easily digestible and practically oriented -book on software requirements, this is perhaps -the best of current textbooks on how the various -elements of software requirements fit together. It -is full of practical advice on (for example) how -to identify the various system stakeholders and -how to evaluate alternative solutions. Its cover- -age is exemplary and serves as a useful reference -for key techniques such as use case modeling and -requirements prioritization. - -C. Potts, K. Takahashi, and A. Antón, “Inquiry- -Based Requirements Analysis” [6]. - -This paper is an easily digested account of work -that has proven to be very influential in the devel- -opment of requirements handling. It describes -how and why the elaboration of requirements -cannot be a linear process by which the analyst -simply transcribes and reformulates requirements -elicited from the customer. The role of scenarios -is described in a way that helps to define their use -in discovering and describing requirements. - -``` -A. van Lamsweerde, Requirements -Engineering: From System Goals to UML -Models to Software Specifications [7]. -``` -``` -Serves as a good introduction to requirements -engineering but its unique value is as a reference -book for the KAOS goal-oriented requirements -modelling language. Explains why goal model- -ling is useful and shows how it can integrate with -mainstream modelling techniques using UML. -``` -``` -O. Gotel and A. Finkelstein, “An Analysis of the -Requirements Traceability Problem” [8]. -``` -``` -This paper is a classic reference work on a key -element of requirements management. Based on -empirical studies, it sets out the reasons for and -the barriers to the effective tracing of require- -ments. It is essential reading for an understanding -of why requirements tracing is an essential ele- -ment of an effective software process. -``` -``` -N. Maiden and C. Ncube, “Acquiring COTS -Software Selection Requirements” [9]. -``` -``` -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 han- -dling, which tends to assume custom software. -``` - -**1-18** **_SWEBOK® Guide_** **V3.0** - -##### REFERENCES - -[1*] I. Sommerville, _Software Engineering_ , 9th -ed., Addison-Wesley, 2011. - -[2*] K.E. Wiegers, _Software Requirements_ , 2nd -ed., Microsoft Press, 2003. - -[3] INCOSE, _Systems Engineering Handbook: -A Guide for System Life Cycle Processes -and Activities_ , version 3.2.2, International -Council on Systems Engineering, 2012. - -[4] S. Friedenthal, A. Moore, and R. Steiner, _A -Practical Guide to SysML: The Systems -Modeling Language_ , 2nd ed., Morgan -Kaufmann, 2012. - -[5] I. Alexander and L. Beus-Deukic, -_Discovering Requirements: How to Specify -Products and Services_ , Wiley, 2009. - -``` -[6] C. Potts, K. Takahashi, and A.I. Antón, -“Inquiry-Based Requirements Analysis,” -IEEE Software, vol. 11, no. 2, Mar. 1994, -pp. 21–32. -``` -``` -[7] A. van Lamsweerde, Requirements -Engineering: From System Goals to UML -Models to Software Specifications , Wiley, -2009. -``` -``` -[8] O. Gotel and C.W. Finkelstein, “An Analysis -of the Requirements Traceability Problem,” -Proc. 1st Int’l Conf. Requirements Eng. , -IEEE, 1994. -``` -``` -[9] N.A. Maiden and C. Ncube, “Acquiring -COTS Software Selection Requirements,” -IEEE Software, vol. 15, no. 2, Mar.–Apr. -1998, pp. 46–56. -``` blob - 9adab4b4a4ed553134b936202d355adf6f5156c6 (mode 644) blob + /dev/null --- 2_software_design.markdown +++ /dev/null @@ -1,1572 +0,0 @@ -``` -2-1 -``` -**CHAPTER 2** - -**SOFTWARE DESIGN** - -##### ACRONYMS - -##### ADL - -``` -Architecture Description -Language -CBD Component-Based Design -CRC Class Responsibility Collaborator -DFD Data Flow Diagram -ERD Entity Relationship Diagram -IDL Interface Description Language -MVC Model View Controller -OO Object-Oriented -PDL Program Design Language -``` -##### INTRODUCTION - -Design is defined as both “the process of defin- -ing the architecture, components, interfaces, and -other characteristics of a system or component” -and “the result of [that] process” [1]. Viewed as a -process, software design is the software engineer- -ing life cycle activity in which software require- -ments are analyzed in order to produce a descrip- -tion of the software’s internal structure that will -serve as the basis for its construction. A software -design (the result) describes the software archi- -tecture—that is, how software is decomposed -and organized into components—and the inter- -faces between those components. It should also -describe the components at a level of detail that -enables their construction. -Software design plays an important role in -developing software: during software design, -software engineers produce various models -that form a kind of blueprint of the solution to -be implemented. We can analyze and evaluate -these models to determine whether or not they -will allow us to fulfill the various requirements. - -``` -We can also examine and evaluate alternative -solutions and tradeoffs. Finally, we can use the -resulting models to plan subsequent development -activities, such as system verification and valida- -tion, in addition to using them as inputs and as the -starting point of construction and testing. -In a standard list of software life cycle pro- -cesses, such as that in ISO/IEC/IEEE Std. 12207, -Software Life Cycle Processes [2], software design -consists of two activities that fit between software -requirements analysis and software construction: -``` -- Software architectural design (sometimes - called high-level design): develops top-level - structure and organization of the software - and identifies the various components. -- Software detailed design: specifies each - component in sufficient detail to facilitate its - construction. - -``` -This Software Design knowledge area (KA) -does not discuss every topic that includes the -word “design.” In Tom DeMarco’s terminology -[3], the topics discussed in this KA deal mainly -with D-design (decomposition design), the goal -of which is to map software into component -pieces. However, because of its importance in -the field of software architecture, we will also -address FP-design (family pattern design), the -goal of which is to establish exploitable com- -monalities in a family of software products. This -KA does not address I-design (invention design), -which is usually performed during the software -requirements process with the goal of conceptu- -alizing and specifying software to satisfy discov- -ered needs and requirements, since this topic is -considered to be part of the requirements process -(see the Software Requirements KA). -This Software Design KA is related specifi- -cally to the Software Requirements, Software -``` - -**2-2** **_SWEBOK® Guide_** **V3.0** - -Construction, Software Engineering Manage- -ment, Software Engineering Models and Meth- -ods, Software Quality, and Computing Founda- -tions KAs. - -**BREAKDOWN OF TOPICS FOR -SOFTWARE DESIGN** - -The breakdown of topics for the Software Design -KA is shown in Figure 2.1. - -**1. Software Design Fundamentals** - -The concepts, notions, and terminology intro- -duced here form an underlying basis for under- -standing the role and scope of software design. - -_1.1. General Design Concepts_ -[4*, c1] - -In the general sense, design can be viewed as a -form of problem solving. For example, the con- -cept of a wicked problem—a problem with no -definitive solution—is interesting in terms of - -``` -understanding the limits of design. A number of -other notions and concepts are also of interest in -understanding design in its general sense: goals, -constraints, alternatives, representations, and -solutions (see Problem Solving Techniques in the -Computing Foundations KA). -``` -``` -1.2. Context of Software Design -[4*, c3] -``` -``` -Software design is an important part of the soft- -ware development process. To understand the -role of software design, we must see how it fits -in the software development life cycle. Thus, it -is important to understand the major characteris- -tics of software requirements analysis, software -design, software construction, software testing, -and software maintenance. -``` -``` -1.3. Software Design Process -[4*, c2] -``` -``` -Software design is generally considered a two- -step process: -``` -``` -Figure 2.1. Breakdown of Topics for the Software Design KA -``` - -``` -Software Design 2-3 -``` -- Architectural design (also referred to as high- - level design and top-level design) describes - how software is organized into components. -- Detailed design describes the desired behav- - ior of these components. - -The output of these two processes is a set of -models and artifacts that record the major deci- -sions that have been taken, along with an explana- -tion of the rationale for each nontrivial decision. -By recording the rationale, long-term maintain- -ability of the software product is enhanced. - -_1.4. Software Design Principles_ -[4*] [5*, c6, c7, c21] [6*, c1, c8, c9] - -A _principle_ is “a comprehensive and fundamen- -tal law, doctrine, or assumption” [7]. Software -design principles are key notions that provide -the basis for many different software design -approaches and concepts. Software design princi- -ples include abstraction; coupling and cohesion; -decomposition and modularization; encapsula- -tion/information hiding; separation of interface -and implementation; sufficiency, completeness, -and primitiveness; and separation of concerns. - -- _Abstraction_ is “a view of an object that - focuses on the information relevant to a - particular purpose and ignores the remain- - der of the information” [1] (see Abstraction - in the Computing Foundations KA). In the - context of software design, two key abstrac- - tion mechanisms are parameterization and - specification. Abstraction by parameteriza- - tion abstracts from the details of data repre- - sentations by representing the data as named - parameters. Abstraction by specification - leads to three major kinds of abstraction: - procedural abstraction, data abstraction, and - control (iteration) abstraction. -- _Coupling and Cohesion._ Coupling is defined - as “a measure of the interdependence among - modules in a computer program,” whereas - cohesion is defined as “a measure of the - strength of association of the elements within - a module” [1]. -- _Decomposition and modularization._ Decom- - posing and modularizing means that large - -``` -software is divided into a number of smaller -named components having well-defined -interfaces that describe component interac- -tions. Usually the goal is to place different -functionalities and responsibilities in differ- -ent components. -``` -- _Encapsulation and information hiding_ means - grouping and packaging the internal details - of an abstraction and making those details - inaccessible to external entities. -- _Separation of interface and implementation._ - Separating interface and implementation - involves defining a component by specify- - ing a public interface (known to the clients) - that is separate from the details of how the - component is realized (see encapsulation and - information hiding above). -- _Sufficiency, completeness, and primitiveness._ - Achieving sufficiency and completeness - means ensuring that a software component - captures all the important characteristics of - an abstraction and nothing more. Primitive- - ness means the design should be based on - patterns that are easy to implement. -- _Separation of concerns._ A concern is an - “area of interest with respect to a software - design” [8]. A design concern is an area of - design that is relevant to one or more of its - stakeholders. Each architecture view frames - one or more concerns. Separating concerns - by views allows interested stakeholders to - focus on a few things at a time and offers a - means of managing complexity [9]. -**2. Key Issues in Software Design** - -``` -A number of key issues must be dealt with when -designing software. Some are quality concerns -that all software must address—for example, -performance, security, reliability, usability, etc. -Another important issue is how to decompose, -organize, and package software components. -This is so fundamental that all design approaches -address it in one way or another (see section 1.4, -Software Design Principles, and topic 7, Soft- -ware Design Strategies and Methods). In contrast, -other issues “deal with some aspect of software’s -behavior that is not in the application domain, -but which addresses some of the supporting -``` - -**2-4** **_SWEBOK® Guide_** **V3.0** - -domains” [10]. Such issues, which often crosscut -the system’s functionality, have been referred to -as _aspects_ , which “tend not to be units of soft- -ware’s functional decomposition, but rather to be -properties that affect the performance or seman- -tics of the components in systemic ways” [11]. -A number of these key, crosscutting issues are -discussed in the following sections (presented in -alphabetical order). - -_2.1. Concurrency_ -[5*, c18] - -Design for concurrency is concerned with decom- -posing software into processes, tasks, and threads -and dealing with related issues of efficiency, -atomicity, synchronization, and scheduling. - -_2.2. Control and Handling of Events_ -[5*, c21] - -This design issue is concerned with how to -organize data and control flow as well as how -to handle reactive and temporal events through -various mechanisms such as implicit invocation -and call-backs. - -_2.3. Data Persistence_ -[12*, c9] - -This design issue is concerned with how to han- -dle long-lived data. - -_2.4. Distribution of Components_ -[5*, c18] - -This design issue is concerned with how to dis- -tribute the software across the hardware (includ- -ing computer hardware and network hardware), -how the components communicate, and how -middleware can be used to deal with heteroge- -neous software. - -_2.5. Error and Exception Handling and Fault -Tolerance_ -[5*, c18] - -This design issue is concerned with how to pre- -vent, tolerate, and process errors and deal with -exceptional conditions. - -``` -2.6. Interaction and Presentation -[5*, c16] -``` -``` -This design issue is concerned with how to struc- -ture and organize interactions with users as well -as the presentation of information (for example, -separation of presentation and business logic -using the Model-View-Controller approach). -Note that this topic does not specify user interface -details, which is the task of user interface design -(see topic 4, User Interface Design). -``` -``` -2.7. Security -[5*, c12, c18] [13*, c4] -``` -``` -Design for security is concerned with how to pre- -vent unauthorized disclosure, creation, change, -deletion, or denial of access to information and -other resources. It is also concerned with how to -tolerate security-related attacks or violations by -limiting damage, continuing service, speeding -repair and recovery, and failing and recovering -securely. Access control is a fundamental con- -cept of security, and one should also ensure the -proper use of cryptology. -``` -**3. Software Structure and Architecture** - -``` -In its strict sense, a software architecture is -“the set of structures needed to reason about -the system, which comprise software elements, -relations among them, and properties of both” -[14*]. During the mid-1990s, however, soft- -ware architecture started to emerge as a broader -discipline that involved the study of software -structures and architectures in a more generic -way. This gave rise to a number of interesting -concepts about software design at different lev- -els of abstraction. Some of these concepts can -be useful during the architectural design (for -example, architectural styles) as well as during -the detailed design (for example, design pat- -terns). These design concepts can also be used -to design families of programs (also known as -product lines). Interestingly, most of these con- -cepts can be seen as attempts to describe, and -thus reuse, design knowledge. -``` - -``` -Software Design 2-5 -``` -_3.1. Architectural Structures and Viewpoints_ -[14*, c1] - -Different high-level facets of a software design -can be described and documented. These facets -are often called views: “A view represents a partial -aspect of a software architecture that shows spe- -cific properties of a software system” [14*]. Views -pertain to distinct issues associated with software -design—for example, the logical view (satisfying -the functional requirements) vs. the process view -(concurrency issues) vs. the physical view (distri- -bution issues) vs. the development view (how the -design is broken down into implementation units -with explicit representation of the dependencies -among the units). Various authors use different -terminologies—like behavioral vs. functional vs. -structural vs. data modeling views. In summary, a -software design is a multifaceted artifact produced -by the design process and generally composed of -relatively independent and orthogonal views. - -_3.2. Architectural Styles_ -[14*, c1, c2, c3, c4, c5] - -An architectural style is “a specialization of ele- -ment and relation types, together with a set of -constraints on how they can be used” [14*]. An -architectural style can thus be seen as providing -the software’s high-level organization. Various -authors have identified a number of major archi- -tectural styles: - -- General structures (for example, layers, pipes - and filters, blackboard) -- Distributed systems (for example, client- - server, three-tiers, broker) -- Interactive systems (for example, Model-View- - Controller, Presentation-Abstraction-Control) -- Adaptable systems (for example, microker- - nel, reflection) -- Others (for example, batch, interpreters, pro- - cess control, rule-based). - -_3.3. Design Patterns_ -[15*, c3, c4, c5] - -Succinctly described, a pattern is “a common -solution to a common problem in a given context” -[16]. While architectural styles can be viewed as - -``` -patterns describing the high-level organization -of software, other design patterns can be used -to describe details at a lower level. These lower -level design patterns include the following: -``` -- Creational patterns (for example, builder, - factory, prototype, singleton) -- Structural patterns (for example, adapter, - bridge, composite, decorator, façade, fly- - weight, proxy) -- Behavioral patterns (for example, command, - interpreter, iterator, mediator, memento, - observer, state, strategy, template, visitor). - -``` -3.4. Architecture Design Decisions -[5*, c6] -``` -``` -Architectural design is a creative process. Dur- -ing the design process, software designers have -to make a number of fundamental decisions that -profoundly affect the software and the develop- -ment process. It is useful to think of the archi- -tectural design process from a decision-making -perspective rather than from an activity perspec- -tive. Often, the impact on quality attributes and -tradeoffs among competing quality attributes are -the basis for design decisions. -``` -``` -3.5. Families of Programs and Frameworks -[5*, c6, c7, c16] -``` -``` -One approach to providing for reuse of software -designs and components is to design families of -programs, also known as software product lines. -This can be done by identifying the commonalities -among members of such families and by designing -reusable and customizable components to account -for the variability among family members. -In object-oriented (OO) programming, a key -related notion is that of a framework : a partially -completed software system that can be extended -by appropriately instantiating specific extensions -(such as plug-ins). -``` -**4. User Interface Design** - -``` -User interface design is an essential part of the -software design process. User interface design -should ensure that interaction between the human -and the machine provides for effective operation -``` - -**2-6** **_SWEBOK® Guide_** **V3.0** - -and control of the machine. For software to -achieve its full potential, the user interface should -be designed to match the skills, experience, and -expectations of its anticipated users. - -_4.1. General User Interface Design Principles_ -[5*, c29-web] [17*, c2]^1 - -- _Learnability_. The software should be easy to - learn so that the user can rapidly start work- - ing with the software. -- _User familiarity_. The interface should use - terms and concepts drawn from the experi- - ences of the people who will use the software. -- _Consistency_. The interface should be consis- - tent so that comparable operations are acti- - vated in the same way. -- _Minimal surprise._ The behavior of software - should not surprise users. -- _Recoverability._ The interface should provide - mechanisms allowing users to recover from - errors. -- _User guidance._ The interface should give - meaningful feedback when errors occur and - provide context-related help to users. -- _User diversity_. The interface should pro- - vide appropriate interaction mechanisms - for diverse types of users and for users with - different capabilities (blind, poor eyesight, - deaf, colorblind, etc.). - -_4.2. User Interface Design Issues_ -[5*, c29-web] [17*, c2] - -User interface design should solve two key issues: - -- How should the user interact with the - software? -- How should information from the software - be presented to the user? - -User interface design must integrate user -interaction and information presentation. User -interface design should consider a compromise -between the most appropriate styles of interaction - -1 Chapter 29 is a web-based chapter available -at [http://ifs.host.cs.st-andrews.ac.uk/Books/SE9/](http://ifs.host.cs.st-andrews.ac.uk/Books/SE9/) -WebChapters/. - -``` -and presentation for the software, the background -and experience of the software users, and the -available devices. -``` -``` -4.3. The Design of User Interaction Modalities -[5*, c29-web] [17*, c2] -``` -``` -User interaction involves issuing commands and -providing associated data to the software. User -interaction styles can be classified into the fol- -lowing primary styles: -``` -- _Question-answer._ The interaction is essen- - tially restricted to a single question-answer - exchange between the user and the software. - The user issues a question to the software, - and the software returns the answer to the - question. -- _Direct manipulation_. Users interact with - objects on the computer screen. Direct - manipulation often includes a pointing - device (such as a mouse, trackball, or a fin- - ger on touch screens) that manipulates an - object and invokes actions that specify what - is to be done with that object. -- _Menu selection_. The user selects a command - from a menu list of commands. -- _Form fill-in_. The user fills in the fields of a - form. Sometimes fields include menus, in - which case the form has action buttons for - the user to initiate action. -- _Command language_. The user issues a com- - mand and provides related parameters to - direct the software what to do. -- _Natural language_. The user issues a com- - mand in natural language. That is, the natural - language is a front end to a command lan- - guage and is parsed and translated into soft- - ware commands. - -``` -4.4. The Design of Information Presentation -[5*, c29-web] [17*, c2] -``` -``` -Information presentation may be textual or graphi- -cal in nature. A good design keeps the information -presentation separate from the information itself. -The MVC (Model-View-Controller) approach is -an effective way to keep information presentation -separating from the information being presented. -``` - -``` -Software Design 2-7 -``` -Software engineers also consider software -response time and feedback in the design of infor- -mation presentation. Response time is generally -measured from the point at which a user executes -a certain control action until the software responds -with a response. An indication of progress is desir- -able while the software is preparing the response. -Feedback can be provided by restating the user’s -input while processing is being completed. -Abstract visualizations can be used when large -amounts of information are to be presented. -According to the style of information presenta- -tion, designers can also use color to enhance the -interface. There are several important guidelines: - -- Limit the number of colors used. -- Use color change to show the change of soft- - ware status. -- Use color-coding to support the user’s task. -- Use color-coding in a thoughtful and consis- - tent way. -- Use colors to facilitate access for people - with color blindness or color deficiency - (e.g., use the change of color saturation and - color brightness, try to avoid blue and red - combinations). -- Don’t depend on color alone to convey - important information to users with different - capabilities (blindness, poor eyesight, color- - blindness, etc.). - -_4.5. User Interface Design Process_ -[5*, c29-web] [17*, c2] - -User interface design is an iterative process; -interface prototypes are often used to determine -the features, organization, and look of the soft- -ware user interface. This process includes three -core activities: - -- _User analysis._ In this phase, the designer ana- - lyzes the users’ tasks, the working environ- - ment, other software, and how users interact - with other people. -- _Software prototyping._ Developing prototype - software help users to guide the evolution of - the interface. -- _Interface evaluation._ Designers can observe - users’ experiences with the evolving interface. - -``` -4.6. Localization and Internationalization -[17*, c8, c9] -``` -``` -User interface design often needs to consider inter- -nationalization and localization, which are means -of adapting software to the different languages, -regional differences, and the technical require- -ments of a target market. Internationalization is the -process of designing a software application so that -it can be adapted to various languages and regions -without major engineering changes. Localization -is the process of adapting internationalized soft- -ware for a specific region or language by adding -locale-specific components and translating the -text. Localization and internationalization should -consider factors such as symbols, numbers, cur- -rency, time, and measurement units. -``` -``` -4.7. Metaphors and Conceptual Models -[17*, c5] -``` -``` -User interface designers can use metaphors and -conceptual models to set up mappings between the -software and some reference system known to the -users in the real world, which can help the users to -more readily learn and use the interface. For exam- -ple, the operation “delete file” can be made into a -metaphor using the icon of a trash can. -When designing a user interface, software engi- -neers should be careful to not use more than one -metaphor for each concept. Metaphors also pres- -ent potential problems with respect to internation- -alization, since not all metaphors are meaningful -or are applied in the same way within all cultures. -``` -**5. Software Design Quality Analysis and -Evaluation** - -``` -This section includes a number of quality anal- -ysis and evaluation topics that are specifically -related to software design. (See also the Software -Quality KA.) -``` -``` -5.1. Quality Attributes -[4*, c4] -``` -``` -Various attributes contribute to the quality of -a software design, including various “-ilities” -(maintainability, portability, testability, usability) -``` - -**2-8** **_SWEBOK® Guide_** **V3.0** - -and “-nesses” (correctness, robustness). There is -an interesting distinction between quality attri- -butes discernible at runtime (for example, per- -formance, security, availability, functionality, -usability), those not discernible at runtime (for -example, modifiability, portability, reusability, -testability), and those related to the architecture’s -intrinsic qualities (for example, conceptual integ- -rity, correctness, completeness). (See also the -Software Quality KA.) - -_5.2. Quality Analysis and Evaluation Techniques_ -[4*, c4] [5*, c24] - -Various tools and techniques can help in analyz- -ing and evaluating software design quality. - -- Software design reviews: informal and for- - malized techniques to determine the quality - of design artifacts (for example, architecture - reviews, design reviews, and inspections; - scenario-based techniques; requirements - tracing). Software design reviews can also - evaluate security. Aids for installation, oper- - ation, and usage (for example, manuals and - help files) can be reviewed. -- Static analysis: formal or semiformal static - (nonexecutable) analysis that can be used - to evaluate a design (for example, fault- - tree analysis or automated cross-checking). - Design vulnerability analysis (for example, - static analysis for security weaknesses) can - be performed if security is a concern. Formal - design analysis uses mathematical models - that allow designers to predicate the behavior - and validate the performance of the software - instead of having to rely entirely on testing. - Formal design analysis can be used to detect - residual specification and design errors (per- - haps caused by imprecision, ambiguity, and - sometimes other kinds of mistakes). (See - also the Software Engineering Models and - Methods KA.) -- Simulation and prototyping: dynamic tech- - niques to evaluate a design (for example, - performance simulation or feasibility - prototypes). - -``` -5.3. Measures -[4*, c4] [5*, c24] -``` -``` -Measures can be used to assess or to quanti- -tatively estimate various aspects of a software -design; for example, size, structure, or quality. -Most measures that have been proposed depend -on the approach used for producing the design. -These measures are classified in two broad -categories: -``` -- Function-based (structured) design mea- - sures: measures obtained by analyzing func- - tional decomposition; generally represented - using a structure chart (sometimes called a - hierarchical diagram) on which various mea- - sures can be computed. -- Object-oriented design measures: the design - structure is typically represented as a class - diagram, on which various measures can be - computed. Measures on the properties of the - internal content of each class can also be - computed. -**6. Software Design Notations** - -``` -Many notations exist to represent software design -artifacts. Some are used to describe the structural -organization of a design, others to represent soft- -ware behavior. Certain notations are used mostly -during architectural design and others mainly -during detailed design, although some nota- -tions can be used for both purposes. In addition, -some notations are used mostly in the context of -specific design methods (see topic 7, Software -Design Strategies and Methods). Please note that -software design is often accomplished using mul- -tiple notations. Here, they are categorized into -notations for describing the structural (static) -view vs. the behavioral (dynamic) view. -``` -``` -6.1. Structural Descriptions (Static View) -[4*, c7] [5*, c6, c7] [6*, c4, c5, c6, c7] -[12*, c7] [14*, c7] -``` -``` -The following notations, mostly but not always -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 -they are interconnected (static view): - -- Architecture description languages (ADLs): - textual, often formal, languages used to - describe software architecture in terms of - components and connectors. -- Class and object diagrams: used to repre- - sent a set of classes (and objects) and their - interrelationships. -- Component diagrams: used to represent a - set of components (“physical and replace- - able part[s] of a system that [conform] to - and [provide] the realization of a set of inter- - faces” [18]) and their interrelationships. -- Class responsibility collaborator cards - (CRCs): used to denote the names of compo- - nents (class), their responsibilities, and their - collaborating components’ names. -- Deployment diagrams: used to represent a - set of (physical) nodes and their interrela- - tionships, and, thus, to model the physical - aspects of software. -- Entity-relationship diagrams (ERDs): used - to represent conceptual models of data stored - in information repositories. -- Interface description languages (IDLs): - programming-like languages used to define - the interfaces (names and types of exported - operations) of software components. -- Structure charts: used to describe the calling - structure of programs (which modules call, - and are called by, which other modules). - -_6.2. Behavioral Descriptions (Dynamic View)_ -[4*, c7, c13] [5*, c6, c7] [6*, c4, c5, c6, c7] -[14*, c8] - -The following notations and languages, some -graphical and some textual, are used to describe -the dynamic behavior of software systems and -components. Many of these notations are use- -ful mostly, but not exclusively, during detailed -design. Moreover, behavioral descriptions can -include a rationale for design decision such as -how a design will meet security requirements. - -- Activity diagrams: used to show control flow - from activity to activity. Can be used to rep- - resent concurrent activities. -- Communication diagrams: used to show - the interactions that occur among a group - of objects; emphasis is on the objects, their - links, and the messages they exchange on - those links. -- Data flow diagrams (DFDs): used to show - data flow among elements. A data flow dia- - gram provides “a description based on model- - ing the flow of information around a network - of operational elements, with each element - making use of or modifying the information - flowing into that element” [4*]. Data flows - (and therefore data flow diagrams) can be - used for security analysis, as they offer iden- - tification of possible paths for attack and dis- - closure of confidential information. -- Decision tables and diagrams: used to rep- - resent complex combinations of conditions - and actions. -- Flowcharts: used to represent the flow of - control and the associated actions to be - performed. -- Sequence diagrams: used to show the inter- - actions among a group of objects, with - emphasis on the time ordering of messages - passed between objects. -- State transition and state chart diagrams: - used to show the control flow from state to - state and how the behavior of a component - changes based on its current state in a state - machine. -- Formal specification languages: textual lan- - guages that use basic notions from math- - ematics (for example, logic, set, sequence) - to rigorously and abstractly define software - component interfaces and behavior, often in - terms of pre- and postconditions. (See also - the Software Engineering Models and Meth- - ods KA.) -- Pseudo code and program design languages - (PDLs): structured programming-like lan- - guages used to describe, generally at the - detailed design stage, the behavior of a pro- - cedure or method. - - -**2-10** **_SWEBOK® Guide_** **V3.0** - -**7. Software Design Strategies and Methods** - -There exist various general strategies to help -guide the design process. In contrast with general -strategies, methods are more specific in that they -generally provide a set of notations to be used -with the method, a description of the process to -be used when following the method, and a set of -guidelines for using the method. Such methods -are useful as a common framework for teams of -software engineers. (See also the Software Engi- -neering Models and Methods KA). - -_7.1. General Strategies_ -[4*, c8, c9, c10] [12*, c7] - -Some often-cited examples of general strategies -useful in the design process include the divide- -and-conquer and stepwise refinement strategies, -top-down vs. bottom-up strategies, and strategies -making use of heuristics, use of patterns and pat- -tern languages, and use of an iterative and incre- -mental approach. - -_7.2. Function-Oriented (Structured) Design_ -[4*, c13] - -This is one of the classical methods of software -design, where decomposition centers on identify- -ing the major software functions and then elab- -orating and refining them in a hierarchical top- -down manner. Structured design is generally used -after structured analysis, thus producing (among -other things) data flow diagrams and associated -process descriptions. Researchers have proposed -various strategies (for example, transformation -analysis, transaction analysis) and heuristics (for -example, fan-in/fan-out, scope of effect vs. scope -of control) to transform a DFD into a software -architecture generally represented as a structure -chart. - -_7.3. Object-Oriented Design_ -[4*, c16] - -Numerous software design methods based -on objects have been proposed. The field has -evolved from the early object-oriented (OO) - -``` -design of the mid-1980s (noun = object; verb -= method; adjective = attribute), where inheri- -tance and polymorphism play a key role, to the -field of component-based design, where metain- -formation can be defined and accessed (through -reflection, for example). Although OO design’s -roots stem from the concept of data abstraction, -responsibility-driven design has been proposed -as an alternative approach to OO design. -``` -``` -7.4. Data Structure-Centered Design -[4*, c14, c15] -``` -``` -Data structure-centered design starts from the data -structures a program manipulates rather than from -the function it performs. The software engineer -first describes the input and output data structures -and then develops the program’s control structure -based on these data structure diagrams. Various -heuristics have been proposed to deal with special -cases—for example, when there is a mismatch -between the input and output structures. -``` -``` -7.5. Component-Based Design (CBD) -[4*, c17] -``` -``` -A software component is an independent unit, -having well-defined interfaces and dependen- -cies that can be composed and deployed inde- -pendently. Component-based design addresses -issues related to providing, developing, and -integrating such components in order to improve -reuse. Reused and off-the-shelf software com- -ponents should meet the same security require- -ments as new software. Trust management is -a design concern; components treated as hav- -ing a certain degree of trustworthiness should -not depend on less trustworthy components or -services. -``` -``` -7.6. Other Methods -[5*, c19, c21] -``` -``` -Other interesting approaches also exist (see the -Software Engineering Models and Methods -KA). Iterative and adaptive methods imple- -ment software increments and reduce emphasis -on rigorous software requirement and design. -``` - -``` -Software Design 2-11 -``` -Aspect-oriented design is a method by which -software is constructed using aspects to imple- -ment the crosscutting concerns and extensions -that are identified during the software require- -ments process. Service-oriented architecture is -a way to build distributed software using web -services executed on distributed computers. Soft- -ware systems are often constructed by using ser- -vices from different providers because standard -protocols (such as HTTP, HTTPS, SOAP) have -been designed to support service communication -and service information exchange. - -**8. Software Design Tools** - [14*, c10, Appendix A] - -``` -Software design tools can be used to support the -creation of the software design artifacts during -the software development process. They can sup- -port part or whole of the following activities: -``` -- to translate the requirements model into a - design representation; -- to provide support for representing func- - 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 - -``` -Budgen 2003 -``` -##### [4*] - -``` -Sommerville 2011 -``` -##### [5*] - -``` -Page-Jones 1999 -``` -##### [6*] - -``` -Brookshear 2008 -``` -##### [12*] - -``` -Allen 2008 -``` -##### [13*] - -``` -Clements et al. 2010 -``` -##### [14*] - -``` -Gamma et al. 1994 -``` -##### [15*] - -``` -Nielsen 1993 -``` -##### [17*] - -**1. Software Design -Fundamentals** - 1.1. General Design - Concepts - c1 - -``` -1.2. The Context of -Software Design -c3 -``` -``` -1.3. The Software -Design Process -c2 -``` -``` -1.4. Software Design -Principles -c1 -c6, c7, -c21 -``` -``` -c1, c8, -c9 -``` -**2. Key Issues in -Software Design** - 2.1. Concurrency c18 - 2.2. Control and - Handling of Events - c21 - -``` -2.3. Data Persistence c9 -2.4. Distribution of -Components -c18 -``` -``` -2.5. Error and -Exception Handling -and Fault Tolerance -``` -``` -c18 -``` -``` -2.6. Interaction and -Presentation -c16 -``` -``` -2.7. Security -c12 , -c18 -c4 -``` -**3. Software Structure -and Architecture** - 3.1. Architectural - Structures and - Viewpoints - -``` -c1 -``` -``` -3.2. Architectural -Styles -``` -``` -c1, c2, -c3, c4, -c5 -``` -``` -3.3. Design Patterns -c3, c4, -c5 -``` - -``` -Software Design 2-13 -``` -``` -Budgen 2003 -``` -##### [4*] - -``` -Sommerville 2011 -``` -##### [5*] - -``` -Page-Jones 1999 -``` -##### [6*] - -``` -Brookshear 2008 -``` -##### [12*] - -``` -Allen 2008 -``` -##### [13*] - -``` -Clements et al. 2010 -``` -##### [14*] - -``` -Gamma et al. 1994 -``` -##### [15*] - -``` -Nielsen 1993 -``` -##### [17*] - -``` -3.4. Architecture -Design Decisions -c6 -``` -``` -3.5. Families of -Programs and -Frameworks -``` -``` -c6, c7, -c16 -``` -**4. User Interface -Design** - -``` -4.1. General User -Interface Design -Principle -``` -``` -c29- -web -c2 -``` -``` -4.2. User Interface -Design Issues -``` -``` -c29- -web -4.3. The Design of -User Interaction -Modalities -``` -``` -c29- -web -``` -``` -4.4. The Design -of Information -Presentation -``` -``` -c29- -web -``` -``` -4.5. User Interface -Design Process -``` -``` -c29- -web -4.6. Localization and -Internationalization -c8, c9 -``` -``` -4.7. Metaphors and -Conceptual Models -c5 -``` -**5. Software Design -Quality Analysis and -Evaluation** - -``` -5.1. Quality -Attributes -c4 -``` -``` -5.2. Quality -Analysis and -Evaluation -Te c h n i q u e s -``` -``` -c4 c24 -``` -``` -5.3. Measures c4 c24 -``` - -**2-14** **_SWEBOK® Guide_** **V3.0** - -``` -Budgen 2003 -``` -##### [4*] - -``` -Sommerville 2011 -``` -##### [5*] - -``` -Page-Jones 1999 -``` -##### [6*] - -``` -Brookshear 2008 -``` -##### [12*] - -``` -Allen 2008 -``` -##### [13*] - -``` -Clements et al. 2010 -``` -##### [14*] - -``` -Gamma et al. 1994 -``` -##### [15*] - -``` -Nielsen 1993 -``` -##### [17*] - -**6. Software Design -Notations** - 6.1. Structural - Descriptions (Static - View) - -``` -c7 c6, c7 -c4, c5, -c6, c7 -c7 c7 -``` -``` -6.2. Behavioral -Descriptions -(Dynamic View) -``` -``` -c7, c13, -c18 -c6, c7 -c4, c5, -c6, c7 -c8 -``` -**7. Software Design -Strategies and -Methods** - 7.1. General - Strategies - -``` -c8, c9, -c10 -c7 -``` -``` -7.2. Function- -Oriented -(Structured) Design -``` -``` -c13 -``` -``` -7.3. Object-Oriented -Design -c16 -``` -``` -7.4. Data Structure- -Centered Design -``` -``` -c14, -c15 -7.5. Component- -Based Design (CBD) -c17 -``` -``` -7.6. Other Methods -c19, -c21 -``` -**8. Software Design -To o l s** - -``` -c10, -App. A -``` - -``` -Software Design 2-15 -``` -##### FURTHER READINGS - -Roger Pressman, _Software Engineering: A -Practitioner’s Approach (Seventh Edition)_ -[19]. - -For roughly three decades, Roger Pressman’s -_Software Engineering: A Practitioner’s Approach_ -has been one of the world’s leading textbooks in -software engineering. Notably, this complemen- -tary textbook to [5*] comprehensively presents -software design—including design concepts, -architectural design, component-level design, -user interface design, pattern-based design, and -web application design. - -“The 4+1 View Model of Architecture” [20]. - -The seminal paper “The 4+1 View Model” orga- -nizes a description of a software architecture -using five concurrent views. The four views of -the model are the logical view, the development -view, the process view, and the physical view. -In addition, selected use cases or scenarios are -utilized to illustrate the architecture. Hence, the -model contains 4+1 views. The views are used to -describe the software as envisioned by different -stakeholders—such as end-users, developers, and -project managers. - -Len Bass, Paul Clements, and Rick Kazman, -_Software Architecture in Practice_ [21]. - -This book introduces the concepts and best prac- -tices of software architecture, meaning how soft- -ware is structured and how the software’s compo- -nents interact. Drawing on their own experience, -the authors cover the essential technical topics -for designing, specifying, and validating software -architectures. They also emphasize the impor- -tance of the business context in which large soft- -ware is designed. Their aim is to present software -architecture in a real-world setting, reflecting -both the opportunities and constraints that orga- -nizations encounter. This is one of the best books -currently available on software architecture. - -##### REFERENCES - -``` -[1] ISO/IEC/IEEE 24765:2010 Systems and -Software Engineering—Vocabulary , ISO/ -IEC/IEEE, 2010. -``` -``` -[2] IEEE Std. 12207-2008 (a.k.a. ISO/IEC -12207:2008) Standard for Systems and -Software Engineering—Software Life Cycle -Processes , IEEE, 2008. -``` -``` -[3] T. DeMarco, “The Paradox of Software -Architecture and Design,” Stevens Prize -Lecture, 1999. -``` -``` -[4*] D. Budgen, Software Design , 2nd ed., -Addison-Wesley, 2003. -``` -``` -[5*] I. Sommerville, Software Engineering , 9th -ed., Addison-Wesley, 2011. -``` -``` -[6*] M. Page-Jones, Fundamentals of Object- -Oriented Design in UML , 1st ed., Addison- -Wesley, 1999. -``` -``` -[7] Merriam-Webster’s Collegiate Dictionary , -11th ed., 2003. -``` -``` -[8] IEEE Std. 1069-2009 Standard for -Information Technology—Systems -Design—Software Design Descriptions , -IEEE, 2009. -``` -``` -[9] ISO/IEC 42010:2011 Systems and Software -Engineering—Recommended Practice for -Architectural Description of Software- -Intensive Systems , ISO/IEC, 2011. -``` -``` -[10] J. Bosch, Design and Use of Software -Architectures: Adopting and Evolving a -Product-Line Approach , ACM Press, 2000. -``` -``` -[11] G. Kiczales et al., “Aspect-Oriented -Programming,” Proc. 11th European Conf. -Object-Oriented Programming (ECOOP -97), Springer, 1997. -``` - -**2-16** **_SWEBOK® Guide_** **V3.0** - -[12*] J.G. Brookshear, _Computer Science: An -Overview_ , 10th ed., Addison-Wesley, 2008. - -[13*] J.H. Allen et al., _Software Security -Engineering: A Guide for Project -Managers_ , Addison-Wesley, 2008. - -[14*] P. Clements et al., _Documenting Software -Architectures: Views and Beyond_ , 2nd ed., -Pearson Education, 2010. - -[15*] E. Gamma et al., _Design Patterns: -Elements of Reusable Object-Oriented -Software_ , 1st ed., Addison-Wesley -Professional, 1994. - -[16] I. Jacobson, G. Booch, and J. Rumbaugh, -_The Unified Software Development -Process_ , Addison-Wesley Professional, -1999. - -``` -[17*] J. Nielsen, Usability Engineering , Morgan -Kaufmann, 1993. -``` -``` -[18] G. Booch, J. Rumbaugh, and I. Jacobson, -The Unified Modeling Language User -Guide, Addison-Wesley, 1999. -``` -``` -[19] R.S. Pressman, Software Engineering: A -Practitioner’s Approach , 7th ed., McGraw- -Hill, 2010. -``` -``` -[20] P.B. Kruchten, “The 4+1 View Model of -Architecture,” IEEE Software, vol. 12, no. -6, 1995, pp. 42–55. -``` -``` -[21] L. Bass, P. Clements, and R. Kazman, -Software Architecture in Practice , 3rd ed., -Addison-Wesley Professional, 2013. -``` blob - 7f9416c0d608423dd77d1df1f982aa114e5fd99b (mode 644) blob + /dev/null --- 3_software_construction.markdown +++ /dev/null @@ -1,1583 +0,0 @@ -``` -3-1 -``` -**CHAPTER 3** - -**SOFTWARE CONSTRUCTION** - -##### ACRONYMS - -##### API - -``` -Application Programming -Interface -COTS Commercial Off-the-Shelf -GUI Graphical User Interface -``` -``` -IDE -Integrated Development -Environment -OMG Object Management Group -``` -``` -POSIX -Portable Operating System -Interface -TDD Test-Driven Development -UML Unified Modeling Language -``` -##### INTRODUCTION - -The term software construction refers to the -detailed creation of working software through a -combination of coding, verification, unit testing, -integration testing, and debugging. -The Software Construction knowledge area -(KA) is linked to all the other KAs, but it is most -strongly linked to Software Design and Software -Testing because the software construction process -involves significant software design and testing. -The process uses the design output and provides an -input to testing (“design” and “testing” in this case -referring to the activities, not the KAs). Boundar- -ies between design, construction, and testing (if -any) will vary depending on the software life cycle -processes that are used in a project. -Although some detailed design may be per- -formed prior to construction, much design work -is performed during the construction activity. -Thus, the Software Construction KA is closely -linked to the Software Design KA. -Throughout construction, software engineers -both unit test and integration test their work. - -``` -Thus, the Software Construction KA is closely -linked to the Software Testing KA as well. -Software construction typically produces the -highest number of configuration items that need -to be managed in a software project (source files, -documentation, test cases, and so on). Thus, the -Software Construction KA is also closely linked -to the Software Configuration Management KA. -While software quality is important in all the -KAs, code is the ultimate deliverable of a soft- -ware project, and thus the Software Quality KA is -closely linked to the Software Construction KA. -Since software construction requires knowledge -of algorithms and of coding practices, it is closely -related to the Computing Foundations KA, which -is concerned with the computer science founda- -tions that support the design and construction of -software products. It is also related to project man- -agement, insofar as the management of construc- -tion can present considerable challenges. -``` -``` -BREAKDOWN OF TOPICS FOR -SOFTWARE CONSTRUCTION -``` -``` -Figure 3.1 gives a graphical representation of the -top-level decomposition of the breakdown for the -Software Construction KA. -``` -**1. Software Construction Fundamentals** - -``` -Software construction fundamentals include -``` -- minimizing complexity -- anticipating change -- constructing for verification -- reuse -- standards in construction. - -``` -The first four concepts apply to design as well -as to construction. The following sections define -``` - -**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 -construction. - -_1.1. Minimizing Complexity_ -[1*] - -Most people are limited in their ability to hold -complex structures and information in their -working memories, especially over long peri- -ods of time. This proves to be a major factor -influencing how people convey intent to com- -puters and leads to one of the strongest drives -in software construction: _minimizing_ complex- -ity. The need to reduce complexity applies to -essentially every aspect of software construction -and is particularly critical to testing of software -constructions. -In software construction, reduced complexity -is achieved through emphasizing code creation -that is simple and readable rather than clever. It -is accomplished through making use of standards -(see section 1.5, Standards in Construction), -modular design (see section 3.1, Construction -Design), and numerous other specific techniques -(see section 3.3, Coding). It is also supported by -construction-focused quality techniques (see sec- -tion 3.7, Construction Quality). - -_1.2. Anticipating Change_ -[1*] - -Most software will change over time, and the -anticipation of _change_ drives many aspects of -software construction; changes in the environ- -ments in which software operates also affect soft- -ware in diverse ways. -Anticipating change helps software engineers -build extensible software, which means they can -enhance a software product without disrupting -the underlying structure. -Anticipating change is supported by many spe- -cific techniques (see section 3.3, Coding). - -_1.3. Constructing for Verification_ -[1*] - -Constructing for verification means building -software in such a way that faults can be read- -ily found by the software engineers writing the -software as well as by the testers and users during - -``` -independent testing and operational activities. -Specific techniques that support constructing for -verification include following coding standards to -support code reviews and unit testing, organizing -code to support automated testing, and restrict- -ing the use of complex or hard-to-understand lan- -guage structures, among others. -``` -``` -1.4. Reuse -[2*] -``` -``` -Reuse refers to using existing assets in solving -different problems. In software construction, typ- -ical assets that are reused include libraries, mod- -ules, components, source code, and commercial -off-the-shelf (COTS) assets. Reuse is best prac- -ticed systematically, according to a well-defined, -repeatable process. Systematic reuse can enable -significant software productivity, quality, and -cost improvements. -Reuse has two closely related facets: “construc- -tion for reuse” and “construction with reuse.” The -former means to create reusable software assets, -while the latter means to reuse software assets in -the construction of a new solution. Reuse often -transcends the boundary of projects, which means -reused assets can be constructed in other projects -or organizations. -``` -``` -1.5. Standards in Construction -[1*] -``` -``` -Applying external or internal development stan- -dards during construction helps achieve a proj- -ect’s objectives for efficiency, quality, and cost. -Specifically, the choices of allowable program- -ming language subsets and usage standards are -important aids in achieving higher security. -Standards that directly affect construction -issues include -``` -- communication methods (for example, stan- - dards for document formats and contents) -- programming languages (for example, lan- - guage standards for languages like Java and - C++) -- coding standards (for example, standards for - naming conventions, layout, and indentation) -- platforms (for example, interface standards - for operating system calls) - - -**3-4** **_SWEBOK® Guide_** **V3.0** - -- tools (for example, diagrammatic standards - for notations like UML (Unified Modeling - Language)). - -_Use of external standards._ Construction -depends on the use of external standards for con- -struction languages, construction tools, technical -interfaces, and interactions between the Software -Construction KA and other KAs. Standards come -from numerous sources, including hardware and -software interface specifications (such as the -Object Management Group (OMG)) and interna- -tional organizations (such as the IEEE or ISO). -_Use of internal standards._ Standards may also -be created on an organizational basis at the cor- -porate level or for use on specific projects. These -standards support coordination of group activi- -ties, minimizing complexity, anticipating change, -and constructing for verification. - -**2. Managing Construction** - -_2.1. Construction in Life Cycle Models_ -[1*] - -Numerous models have been created to develop -software; some emphasize construction more -than others. -Some models are more linear from the con- -struction point of view—such as the waterfall and -staged-delivery life cycle models. These models -treat construction as an activity that occurs only -after significant prerequisite work has been com- -pleted—including detailed requirements work, -extensive design work, and detailed planning. -The more linear approaches tend to emphasize -the activities that precede construction (require- -ments and design) and to create more distinct sep- -arations between activities. In these models, the -main emphasis of construction may be coding. -Other models are more iterative—such as -evolutionary prototyping and agile develop- -ment. These approaches tend to treat construc- -tion as an activity that occurs concurrently with -other software development activities (including -requirements, design, and planning) or that over- -laps them. These approaches tend to mix design, -coding, and testing activities, and they often treat -the combination of activities as construction (see - -``` -the Software Management and Software Process -KAs). -Consequently, what is considered to be “con- -struction” depends to some degree on the life -cycle model used. In general, software con- -struction is mostly coding and debugging, but -it also involves construction planning, detailed -design, unit testing, integration testing, and other -activities. -``` -``` -2.2. Construction Planning -[1*] -``` -``` -The choice of construction method is a key aspect -of the construction-planning activity. The choice -of construction method affects the extent to -which construction prerequisites are performed, -the order in which they are performed, and the -degree to which they should be completed before -construction work begins. -The approach to construction affects the proj- -ect team’s ability to reduce complexity, anticipate -change, and construct for verification. Each of -these objectives may also be addressed at the pro- -cess, requirements, and design levels—but they -will be influenced by the choice of construction -method. -Construction planning also defines the order -in which components are created and integrated, -the integration strategy (for example, phased or -incremental integration), the software quality -management processes, the allocation of task -assignments to specific software engineers, and -other tasks, according to the chosen method. -``` -``` -2.3. Construction Measurement -[1*] -``` -``` -Numerous construction activities and artifacts can -be measured—including code developed, code -modified, code reused, code destroyed, code com- -plexity, code inspection statistics, fault-fix and -fault-find rates, effort, and scheduling. These mea- -surements can be useful for purposes of managing -construction, ensuring quality during construction, -and improving the construction process, among -other uses (see the Software Engineering Process -KA for more on measurement). -``` - -``` -Software Construction 3-5 -``` -**3. Practical Considerations** - -Construction is an activity in which the software -engineer has to deal with sometimes chaotic and -changing real-world constraints, and he or she -must do so precisely. Due to the influence of real- -world constraints, construction is more driven by -practical considerations than some other KAs, -and software engineering is perhaps most craft- -like in the construction activities. - -_3.1. Construction Design_ -[1*] - -Some projects allocate considerable design activ- -ity to construction, while others allocate design -to a phase explicitly focused on design. Regard- -less of the exact allocation, some detailed design -work will occur at the construction level, and that -design work tends to be dictated by constraints -imposed by the real-world problem that is being -addressed by the software. -Just as construction workers building a physi- -cal structure must make small-scale modifica- -tions to account for unanticipated gaps in the -builder’s plans, software construction workers -must make modifications on a smaller or larger -scale to flesh out details of the software design -during construction. -The details of the design activity at the construc- -tion level are essentially the same as described in -the Software Design KA, but they are applied on -a smaller scale of algorithms, data structures, and -interfaces. - -_3.2. Construction Languages_ -[1*] -Construction languages include all forms of -communication by which a human can specify an -executable problem solution to a problem. Con- -struction languages and their implementations -(for example, compilers) can affect software -quality attributes of performance, reliability, por- -tability, and so forth. They can be serious con- -tributors to security vulnerabilities. -The simplest type of construction language -is a _configuration language,_ in which software -engineers choose from a limited set of pre- -defined options to create new or custom software - -``` -installations. The text-based configuration files -used in both the Windows and Unix operating -systems are examples of this, and the menu-style -selection lists of some program generators consti- -tute another example of a configuration language. -Toolkit languages are used to build applica- -tions out of elements in toolkits (integrated sets -of application-specific reusable parts); they are -more complex than configuration languages. -Toolkit languages may be explicitly defined as -application programming languages, or the appli- -cations may simply be implied by a toolkit’s set -of interfaces. -Scripting languages are commonly used kinds -of application programming languages. In some -scripting languages, scripts are called batch files -or macros. -Programming languages are the most flexible -type of construction languages. They also contain -the least amount of information about specific -application areas and development processes— -therefore, they require the most training and skill -to use effectively. The choice of programming lan- -guage can have a large effect on the likelihood of -vulnerabilities being introduced during coding— -for example, uncritical usage of C and C++ are -questionable choices from a security viewpoint. -There are three general kinds of notation used -for programming languages, namely -``` -- linguistic (e.g., C/C++, Java) -- formal (e.g., Event-B) -- visual (e.g., MatLab). - -``` -Linguistic notations are distinguished in par- -ticular by the use of textual strings to represent -complex software constructions. The combina- -tion of textual strings into patterns may have a -sentence-like syntax. Properly used, each such -string should have a strong semantic connotation -providing an immediate intuitive understanding -of what will happen when the software construc- -tion is executed. -Formal notations rely less on intuitive, every- -day meanings of words and text strings and more -on definitions backed up by precise, unambigu- -ous, and formal (or mathematical) definitions. -Formal construction notations and formal meth- -ods are at the semantic base of most forms of -``` - -**3-6** **_SWEBOK® Guide_** **V3.0** - -system programming notations, where accuracy, -time behavior, and testability are more important -than ease of mapping into natural language. For- -mal constructions also use precisely defined ways -of combining symbols that avoid the ambiguity -of many natural language constructions. -_Visual notations_ rely much less on the textual -notations of linguistic and formal construction -and instead rely on direct visual interpretation -and placement of visual entities that represent the -underlying software. Visual construction tends to -be somewhat limited by the difficulty of making -“complex” statements using only the arrange- -ment of icons on a display. However, these icons -can be powerful tools in cases where the primary -programming task is simply to build and “adjust” -a visual interface to a program, the detailed -behavior of which has an underlying definition. - -_3.3. Coding_ -[1*] - -The following considerations apply to the soft- -ware construction coding activity: - -- Techniques for creating understandable - source code, including naming conventions - and source code layout; -- Use of classes, enumerated types, variables, - named constants, and other similar entities; -- Use of control structures; -- Handling of error conditions—both antici- - pated and exceptional (input of bad data, for - example); -- Prevention of code-level security breaches - (buffer overflows or array index bounds, for - example); -- Resource usage via use of exclusion mecha- - nisms and discipline in accessing serially - reusable resources (including threads and - database locks); -- Source code organization (into state- - ments, routines, classes, packages, or other - structures); -- Code documentation; -- Code tuning, - -``` -3.4. Construction Testing -[1*] -``` -``` -Construction involves two forms of testing, -which are often performed by the software engi- -neer who wrote the code: -``` -- Unit testing -- Integration testing. - -``` -The purpose of construction testing is to reduce -the gap between the time when faults are inserted -into the code and the time when those faults are -detected, thereby reducing the cost incurred to -fix them. In some instances, test cases are writ- -ten after code has been written. In other instances, -test cases may be created before code is written. -Construction testing typically involves a -subset of the various types of testing, which -are described in the Software Testing KA. For -instance, construction testing does not typically -include system testing, alpha testing, beta testing, -stress testing, configuration testing, usability test- -ing, or other more specialized kinds of testing. -Two standards have been published on the topic -of construction testing: IEEE Standard 829-1998 , -IEEE Standard for Software Test Documentation, -and IEEE Standard 1008-1987, IEEE Standard -for Software Unit Testing. -(See sections 2.1.1., Unit Testing, and 2.1.2., -Integration Testing, in the Software Testing KA -for more specialized reference material.) -``` -``` -3.5. Construction for Reuse -[2*] -``` -``` -Construction for reuse creates software that has -the potential to be reused in the future for the -present project or other projects taking a broad- -based, multisystem perspective. Construction for -reuse is usually based on variability analysis and -design. To avoid the problem of code clones, it -is desired to encapsulate reusable code fragments -into well-structured libraries or components. -The tasks related to software construction for -reuse during coding and testing are as follows: -``` - -``` -Software Construction 3-7 -``` -- Variability implementation with mecha- - nisms such as parameterization, conditional - compilation, design patterns, and so forth. -- Variability encapsulation to make the soft- - ware assets easy to configure and customize. -- Testing the variability provided by the reus- - able software assets. -- Description and publication of reusable soft- - ware assets. - -_3.6. Construction with Reuse_ -[2*] - -Construction with reuse means to create new -software with the reuse of existing software -assets. The most popular method of reuse is to -reuse code from the libraries provided by the lan- -guage, platform, tools being used, or an organiza- -tional repository. Asides from these, the applica- -tions developed today widely make use of many -open-source libraries. Reused and off-the-shelf -software often have the same—or better—quality -requirements as newly developed software (for -example, security level). -The tasks related to software construction with -reuse during coding and testing are as follows: - -- The selection of the reusable units, data- - bases, test procedures, or test data. -- The evaluation of code or test reusability. -- The integration of reusable software assets - into the current software. -- The reporting of reuse information on new - code, test procedures, or test data. - -_3.7. Construction Quality_ -[1*] - -In addition to faults resulting from requirements -and design, faults introduced during construction -can result in serious quality problems—for exam- -ple, security vulnerabilities. This includes not -only faults in security functionality but also faults -elsewhere that allow bypassing of this functional- -ity and other security weaknesses or violations. -Numerous techniques exist to ensure the qual- -ity of code as it is constructed. The primary tech- -niques used for construction quality include - -- unit testing and integration testing (see sec- - tion 3.4, Construction Testing) -- test-first development (see section 2.2 in the - Software Testing KA) -- use of assertions and defensive programming -- debugging -- inspections -- technical reviews, including security-ori- - ented reviews (see section 2.3.2 in the Soft- - ware Quality KA) -- static analysis (see section 2.3 of the Soft- - ware Quality KA) - -``` -The specific technique or techniques selected -depend on the nature of the software being con- -structed as well as on the skillset of the software -engineers performing the construction activi- -ties. Programmers should know good practices -and common vulnerabilities—for example, from -widely recognized lists about common vulner- -abilities. Automated static analysis of code for -security weaknesses is available for several com- -mon programming languages and can be used in -security-critical projects. -Construction quality activities are differenti- -ated from other quality activities by their focus. -Construction quality activities focus on code and -artifacts that are closely related to code—such -as detailed design—as opposed to other artifacts -that are less directly connected to the code, such -as requirements, high-level designs, and plans. -``` -``` -3.8. Integration -[1*] -``` -``` -A key activity during construction is the integra- -tion of individually constructed routines, classes, -components, and subsystems into a single sys- -tem. In addition, a particular software system -may need to be integrated with other software or -hardware systems. -Concerns related to construction integration -include planning the sequence in which compo- -nents will be integrated, identifying what hard- -ware is needed, creating scaffolding to support -interim versions of the software, determining -the degree of testing and quality work performed -on components before they are integrated, and -``` - -**3-8** **_SWEBOK® Guide_** **V3.0** - -determining points in the project at which interim -versions of the software are tested. -Programs can be integrated by means of either -the phased or the incremental approach. Phased -integration, also called “big bang” integration, -entails delaying the integration of component -software parts until all parts intended for release -in a version are complete. Incremental integration -is thought to offer many advantages over the tra- -ditional phased integration—for example, easier -error location, improved progress monitoring, -earlier product delivery, and improved customer -relations. In incremental integration, the develop- -ers write and test a program in small pieces and -then combine the pieces one at a time. Additional -test infrastructure, such as stubs, drivers, and -mock objects, are usually needed to enable incre- -mental integration. By building and integrating -one unit at a time (for example, a class or compo- -nent), the construction process can provide early -feedback to developers and customers. Other -advantages of incremental integration include -easier error location, improved progress monitor- -ing, more fully tested units, and so forth. - -**4. Construction Technologies** - -_4.1. API Design and Use_ -[3*] - -An application programming interface (API) is the -set of signatures that are exported and available to -the users of a library or a framework to write their -applications. Besides signatures, an API should -always include statements about the program’s -effects and/or behaviors (i.e., its semantics). -API design should try to make the API easy -to learn and memorize, lead to readable code, be -hard to misuse, be easy to extend, be complete, -and maintain backward compatibility. As the -APIs usually outlast their implementations for -a widely used library or framework, it is desired -that the API be straightforward and kept stable to -facilitate the development and maintenance of the -client applications. -API use involves the processes of select- -ing, learning, testing, integrating, and possibly -extending APIs provided by a library or frame- -work (see section 3.6, Construction with Reuse). - -``` -4.2. Object-Oriented Runtime Issues -[1*] -``` -``` -Object-oriented languages support a series of -runtime mechanisms including polymorphism -and reflection. These runtime mechanisms -increase the flexibility and adaptability of object- -oriented programs. Polymorphism is the ability -of a language to support general operations with- -out knowing until runtime what kind of concrete -objects the software will include. Because the -program does not know the exact types of the -objects in advance, the exact behaviour is deter- -mined at runtime (called dynamic binding). -Reflection is the ability of a program to observe -and modify its own structure and behavior at run- -time. Reflection allows inspection of classes, -interfaces, fields, and methods at runtime with- -out knowing their names at compile time. It also -allows instantiation at runtime of new objects and -invocation of methods using parameterized class -and method names. -``` -``` -4.3. Parameterization and Generics -[4*] -``` -``` -Parameterized types , also known as generics -(Ada, Eiffel) and templates (C++), enable the -definition of a type or class without specifying all -the other types it uses. The unspecified types are -supplied as parameters at the point of use. Param- -eterized types provide a third way (in addition to -class inheritance and object composition) to com- -pose behaviors in object-oriented software. -``` -``` -4.4. Assertions, Design by Contract, and Defensive -Programming -[1*] -``` -``` -An assertion is an executable predicate that’s -placed in a program—usually a routine or macro— -that allows runtime checks of the program. Asser- -tions are especially useful in high-reliability pro- -grams. They enable programmers to more quickly -flush out mismatched interface assumptions, errors -that creep in when code is modified, and so on. -Assertions are normally compiled into the code at -development time and are later compiled out of the -code so that they don’t degrade the performance. -``` - -``` -Software Construction 3-9 -``` -Design by contract is a development approach -in which preconditions and postconditions are -included for each routine. When preconditions -and postconditions are used, each routine or -class is said to form a contract with the rest of -the program. Furthermore, a contract provides a -precise specification of the semantics of a routine, -and thus helps the understanding of its behavior. -Design by contract is thought to improve the -quality of software construction. -_Defensive programming_ means to protect a -routine from being broken by invalid inputs. -Common ways to handle invalid inputs include -checking the values of all the input parameters -and deciding how to handle bad inputs. Asser- -tions are often used in defensive programming to -check input values. - -_4.5. Error Handling, Exception Handling, and -Fault Tolerance_ -[1*] - -The way that errors are handled affects software’s -ability to meet requirements related to correct- -ness, robustness, and other nonfunctional attri- -butes. Assertions are sometimes used to check -for errors. Other error handling techniques—such -as returning a neutral value, substituting the next -piece of valid data, logging a warning message, -returning an error code, or shutting down the soft- -ware—are also used. -Exceptions are used to detect and process -errors or exceptional events. The basic structure -of an exception is that a routine uses _throw_ to -throw a detected exception and an exception han- -dling block will _catch_ the exception in a _try-catch_ -block. The try-catch block may process the erro- -neous condition in the routine or it may return -control to the calling routine. Exception handling -policies should be carefully designed follow- -ing common principles such as including in the -exception message all information that led to the -exception, avoiding empty catch blocks, knowing -the exceptions the library code throws, perhaps -building a centralized exception reporter, and -standardizing the program’s use of exceptions. -Fault tolerance is a collection of techniques -that increase software reliability by detecting -errors and then recovering from them if possible - -``` -or containing their effects if recovery is not pos- -sible. The most common fault tolerance strategies -include backing up and retrying, using auxiliary -code, using voting algorithms, and replacing an -erroneous value with a phony value that will have -a benign effect. -``` -``` -4.6. Executable Models -[5*] -``` -``` -Executable models abstract away the details of -specific programming languages and decisions -about the organization of the software. Different -from traditional software models, a specification -built in an executable modeling language like -xUML (executable UML) can be deployed in -various software environments without change. -An executable-model compiler (transformer) can -turn an executable model into an implementation -using a set of decisions about the target hardware -and software environment. Thus, constructing -executable models can be regarded as a way of -constructing executable software. -Executable models are one foundation support- -ing the Model-Driven Architecture (MDA) initia- -tive of the Object Management Group (OMG). An -executable model is a way to completely specify -a Platform Independent Model (PIM); a PIM is -a model of a solution to a problem that does not -rely on any implementation technologies. Then -a Platform Specific Model (PSM), which is a -model that contains the details of the implemen- -tation, can be produced by weaving together the -PIM and the platform on which it relies. -``` -``` -4.7. State-Based and Table-Driven Construction -Techniques -[1*] -``` -``` -State-based programming, or automata-based -programming, is a programming technology -using finite state machines to describe program -behaviours. The transition graphs of a state -machine are used in all stages of software devel- -opment (specification, implementation, debug- -ging, and documentation). The main idea is to -construct computer programs the same way the -automation of technological processes is done. -State-based programming is usually combined -``` - -**3-10** **_SWEBOK® Guide_** **V3.0** - -with object-oriented programming, forming a -new composite approach called _state-based, -object-oriented programming._ -A table-driven method is a schema that uses -tables to look up information rather than using -logic statements (such as _if_ and _case_ ). Used in -appropriate circumstances, table-driven code -is simpler than complicated logic and easier to -modify. When using table-driven methods, the -programmer addresses two issues: what informa- -tion to store in the table or tables, and how to effi- -ciently access information in the table. - -_4.8. Runtime Configuration and -Internationalization_ -[1*] - -To achieve more flexibility, a program is often -constructed to support late binding time of its vari- -ables. Runtime configuration is a technique that -binds variable values and program settings when -the program is running, usually by updating and -reading configuration files in a just-in-time mode. -Internationalization is the technical activ- -ity of preparing a program, usually interactive -software, to support multiple locales. The corre- -sponding activity, _localization,_ is the activity of -modifying a program to support a specific local -language. Interactive software may contain doz- -ens or hundreds of prompts, status displays, help -messages, error messages, and so on. The design -and construction processes should accommodate -string and character-set issues including which -character set is to be used, what kinds of strings -are used, how to maintain the strings without -changing the code, and translating the strings into -different languages with minimal impact on the -processing code and the user interface. - -_4.9. Grammar-Based Input Processing_ -[1*] [6*] - -Grammar-based input processing involves syntax -analysis, or _parsing_ , of the input token stream. It -involves the creation of a data structure (called a -_parse tree_ or _syntax tree_ ) representing the input -data. The inorder traversal of the parse tree usu- -ally gives the expression just parsed. The parser -checks the symbol table for the presence of - -``` -programmer-defined variables that populate the -tree. After building the parse tree, the program -uses it as input to the computational processes. -``` -``` -4.10. Concurrency Primitives -[7*] -``` -``` -A synchronization primitive is a programming -abstraction provided by a programming language -or the operating system that facilitates concur- -rency and synchronization. Well-known concur- -rency primitives include semaphores, monitors, -and mutexes. -A semaphore is a protected variable or abstract -data type that provides a simple but useful abstrac- -tion for controlling access to a common resource -by multiple processes or threads in a concurrent -programming environment. -A monitor is an abstract data type that presents -a set of programmer-defined operations that are -executed with mutual exclusion. A monitor con- -tains the declaration of shared variables and pro- -cedures or functions that operate on those vari- -ables. The monitor construct ensures that only -one process at a time is active within the monitor. -A mutex (mutual exclusion) is a synchroniza- -tion primitive that grants exclusive access to a -shared resource by only one process or thread at -a time. -``` -``` -4.11. Middleware -[3*] [6*] -``` -``` -Middleware is a broad classification for soft- -ware that provides services above the operating -system layer yet below the application program -layer. Middleware can provide runtime contain- -ers for software components to provide message -passing, persistence, and a transparent location -across a network. Middleware can be viewed as -a connector between the components that use the -middleware. Modern message-oriented middle- -ware usually provides an Enterprise Service Bus -(ESB), which supports service-oriented interac- -tion and communication between multiple soft- -ware applications. -``` - -``` -Software Construction 3-11 -``` -_4.12. Construction Methods for Distributed -Software_ -[7*] - -A distributed system is a collection of physically -separate, possibly heterogeneous computer sys- -tems that are networked to provide the users with -access to the various resources that the system -maintains. Construction of distributed software is -distinguished from traditional software construc- -tion by issues such as parallelism, communica- -tion, and fault tolerance. -Distributed programming typically falls into one -of several basic architectural categories: client- -server, 3-tier architecture, n-tier architecture, dis- -tributed objects, loose coupling, or tight coupling -(see section 14.3 of the Computing Foundations -KA and section 3.2 of the Software Design KA). - -_4.13. Constructing Heterogeneous Systems_ -[6*] - -Heterogeneous systems consist of a variety of -specialized computational units of different types, -such as Digital Signal Processors (DSPs), micro- -controllers, and peripheral processors. These -computational units are independently controlled -and communicate with one another. Embedded -systems are typically heterogeneous systems. -The design of heterogeneous systems may -require the combination of several specification -languages in order to design different parts of -the system—in other words, hardware/software -codesign. The key issues include multilanguage -validation, cosimulation, and interfacing. -During the hardware/software codesign, soft- -ware development and virtual hardware devel- -opment proceed concurrently through stepwise -decomposition. The hardware part is usually -simulated in field programmable gate arrays -(FPGAs) or application-specific integrated cir- -cuits (ASICs). The software part is translated into -a low-level programming language. - -_4.14. Performance Analysis and Tuning_ -[1*] - -Code efficiency—determined by architecture, -detailed design decisions, and data-structure and - -``` -algorithm selection—influences an execution -speed and size. Performance analysis is the inves- -tigation of a program’s behavior using informa- -tion gathered as the program executes, with the -goal of identifying possible hot spots in the pro- -gram to be improved. -Code tuning, which improves performance at -the code level, is the practice of modifying correct -code in ways that make it run more efficiently. -Code tuning usually involves only small-scale -changes that affect a single class, a single routine, -or, more commonly, a few lines of code. A rich -set of code tuning techniques is available, includ- -ing those for tuning logic expressions, loops, data -transformations, expressions, and routines. Using -a low-level language is another common tech- -nique for improving some hot spots in a program. -``` -``` -4.15. Platform Standards -[6*] [7*] -``` -``` -Platform standards enable programmers to -develop portable applications that can be exe- -cuted in compatible environments without -changes. Platform standards usually involve a -set of standard services and APIs that compat- -ible platform implementations must implement. -Typical examples of platform standards are Java -2 Platform Enterprise Edition (J2EE) and the -POSIX standard for operating systems (Portable -Operating System Interface), which represents -a set of standards implemented primarily for -UNIX-based operating systems. -``` -``` -4.16. Test-First Programming -[1*] -``` -``` -Test-first programming (also known as Test- -Driven Development—TDD) is a popular devel- -opment style in which test cases are written prior -to writing any code. Test-first programming can -usually detect defects earlier and correct them -more easily than traditional programming styles. -Furthermore, writing test cases first forces pro- -grammers to think about requirements and design -before coding, thus exposing requirements and -design problems sooner. -``` - -**3-12** **_SWEBOK® Guide_** **V3.0** - -**5. Software Construction Tools** - -``` -5.1. Development Environments -[1*] -``` -``` -A development environment, or integrated devel- -opment environment (IDE), provides compre- -hensive facilities to programmers for software -construction by integrating a set of development -tools. The choices of development environments -can affect the efficiency and quality of software -construction. -In additional to basic code editing functions, -modern IDEs often offer other features like com- -pilation and error detection from within the edi- -tor, integration with source code control, build/ -test/debugging tools, compressed or outline -views of programs, automated code transforms, -and support for refactoring. -``` -``` -5.2. GUI Builders -[1*] -``` -``` -A GUI (Graphical User Interface) builder is a -software development tool that enables the devel- -oper to create and maintain GUIs in a WYSI- -WYG (what you see is what you get) mode. A -GUI builder usually includes a visual editor -for the developer to design forms and windows -and manage the layout of the widgets by drag- -ging, dropping, and parameter setting. Some GUI -builders can automatically generate the source -code corresponding to the visual GUI design. -Because current GUI applications usually fol- -low the event-driven style (in which the flow of -the program is determined by events and event -handling), GUI builder tools usually provide -code generation assistants, which automate the -most repetitive tasks required for event handling. -The supporting code connects widgets with the -outgoing and incoming events that trigger the -functions providing the application logic. -Some modern IDEs provide integrated GUI -builders or GUI builder plug-ins. There are also -many standalone GUI builders. -``` -``` -5.3. Unit Testing Tools -[1*] [2*] -Unit testing verifies the functioning of software -modules in isolation from other software elements -that are separately testable (for example, classes, -routines, components). Unit testing is often auto- -mated. Developers can use unit testing tools -and frameworks to extend and create automated -testing environment. With unit testing tools and -frameworks, the developer can code criteria into -the test to verify the unit’s correctness under vari- -ous data sets. Each individual test is implemented -as an object, and a test runner runs all of the tests. -During the test execution, those failed test cases -will be automatically flagged and reported. -``` -``` -5.4. Profiling, Performance Analysis, and -Slicing Tools -[1*] -``` -``` -Performance analysis tools are usually used to -support code tuning. The most common per- -formance analysis tools are profiling tools. An -execution profiling tool monitors the code while -it runs and records how many times each state- -ment is executed or how much time the program -spends on each statement or execution path. Pro- -filing the code while it is running gives insight -into how the program works, where the hot spots -are, and where the developers should focus the -code tuning efforts. -Program slicing involves computation of the -set of program statements (i.e., the program slice) -that may affect the values of specified variables -at some point of interest, which is referred to as -a slicing criterion. Program slicing can be used -for locating the source of errors, program under- -standing, and optimization analysis. Program -slicing tools compute program slices for various -programming languages using static or dynamic -analysis methods. -``` - -``` -Software Construction 3-13 -``` -##### MATRIX OF TOPICS VS. REFERENCE MATERIAL - -``` -McConnell 2004 -``` -##### [1*] - -``` -Sommerville 2011 -``` -##### [2*] - -``` -Clements et al. 2010 -``` -##### [3*] - -``` -Gamma et al. 1994 -``` -##### [4*] - -``` -Mellor and Balcer 2002 -``` -##### [5*] - -``` -Null and Lobur 2006 -``` -##### [6*] - -``` -Silberschatz et al. 2008 -``` -##### [7*] - -**1. Software -Construction -Fundamentals** - -``` -1.1. Minimizing -Complexity -``` -``` -c2, c3, -c7-c9, -c24, c27, -c28, c31, -c32, c34 -``` -``` -1.2. Anticipating -Change -``` -``` -c3–c5, -c24, c31, -c32, c34 -``` -``` -1.3. Constructing for -Verification -``` -``` -c8, -c20– -c23, c31, -c34 -1.4. Reuse c16 -1.5. Standards in -Construction -c4 -``` -**2. Managing -Construction** - 2.1. Construction in - Life Cycle Models - -``` -c2, c3, -c27, c29 -``` -``` -2.2. Construction -Planning -``` -``` -c3, c4, -c21, -c27–c29 -2.3. Construction -Measurement -c25, c28 -``` -**3. Practical -Considerations** - 3.1. Construction - Design - -``` -c3, c5, -c24 -3.2. Construction -Languages -c4 -``` -``` -3.3. Coding -c5–c19, -c25–c26 -``` - -**3-14** **_SWEBOK® Guide_** **V3.0** - -``` -McConnell 2004 -``` -##### [1*] - -``` -Sommerville 2011 -``` -##### [2*] - -``` -Clements et al. 2010 -``` -##### [3*] - -``` -Gamma et al. 1994 -``` -##### [4*] - -``` -Mellor and Balcer 2002 -``` -##### [5*] - -``` -Null and Lobur 2006 -``` -##### [6*] - -``` -Silberschatz et al. 2008 -``` -##### [7*] - -``` -3.4. Construction -Te s t i n g -c22, c23 -``` -``` -3.5. Construction for -Reuse -c16 -``` -``` -3.6. Construction -with Reuse -c16 -``` -``` -3.7. Construction -Quality -``` -``` -c8, -c20–c25 -3.8. Integration c29 -``` -**4. Construction -Te c h no l o g i e s** - 4.1. API Design and - Use - c7 - -``` -4.2. Object-Oriented -Runtime Issues -c6, c7 -``` -``` -4.3. -Parameterization -and Generics -``` -``` -c1 -``` -``` -4.4. Assertions, -Design by Contract, -and Defensive -Programming -``` -``` -c8, c9 -``` -``` -4.5. Error Handling, -Exception Handling, -and Fault Tolerance -``` -``` -c3, c8 -``` -``` -4.6. Executable -Models -c1 -``` -``` -4.7. State-Based -and Table-Driven -Construction -Te c h n i q u e s -``` -``` -c18 -``` -``` -4.8. Runtime -Configuration and -Internationalization -``` -``` -c3, c10 -``` -``` -4.9. Grammar-Based -Input Processing -c5 c8 -``` - -``` -Software Construction 3-15 -``` -``` -McConnell 2004 -``` -##### [1*] - -``` -Sommerville 2011 -``` -##### [2*] - -``` -Clements et al. 2010 -``` -##### [3*] - -``` -Gamma et al. 1994 -``` -##### [4*] - -``` -Mellor and Balcer 2002 -``` -##### [5*] - -``` -Null and Lobur 2006 -``` -##### [6*] - -``` -Silberschatz et al. 2008 -``` -##### [7*] - -``` -4.10. Concurrency -Primitives -c6 -``` -``` -4.11. Middleware c1 c8 -4.12. Construction -Methods for -Distributed Software -``` -``` -c2 -``` -``` -4.13. Constructing -Heterogeneous -Systems -``` -``` -c9 -``` -``` -4.14. Performance -Analysis and Tuning -c25, c26 -``` -``` -4.15. Platform -Standards -c10 c1 -``` -``` -4.16. Test-First -Programming -c22 -``` -**5. Construction Tools** - -``` -5.1. Development -Environments -c30 -``` -``` -5.2. GUI Builders c30 -5.3. Unit Testing -To ol s -c22 c8 -``` -``` -5.4. Profiling, -Performance -Analysis, and -Sl i c i n g To ol s -``` -``` -c25, c26 -``` - -**3-16** **_SWEBOK® Guide_** **V3.0** - -##### FURTHER READINGS - -_IEEE Std. 1517-2010 Standard for Information -Technology—System and Software Life -Cycle Processes—Reuse Processes_ , IEEE, -2010 [8]. - -This standard specifies the processes, activities, -and tasks to be applied during each phase of the -software life cycle to enable a software product -to be constructed from reusable assets. It covers -the concept of reuse-based development and the -processes of construction for reuse and construc- -tion with reuse. - -_IEEE Std. 12207-2008 (a.k.a. ISO/IEC -12207:2008) Standard for Systems and -Software Engineering—Software Life Cycle -Processes_ , IEEE, 2008 [9]. - -This standard defines a series of software devel- -opment processes, including software construc- -tion process, software integration process, and -software reuse process. - -##### REFERENCES - -``` -[1*] S. McConnell, Code Complete , 2nd ed., -Microsoft Press, 2004. -``` -``` -[2*] I. Sommerville, Software Engineering , 9th -ed., Addison-Wesley, 2011. -``` -``` -[3*] P. Clements et al., Documenting Software -Architectures: Views and Beyond , 2nd ed., -Pearson Education, 2010. -``` -``` -[4*] E. Gamma et al., Design Patterns: Elements -of Reusable Object-Oriented Software , 1st -ed., Addison-Wesley Professional, 1994. -``` -``` -[5*] S.J. Mellor and M.J. Balcer, Executable -UML: A Foundation for Model-Driven -Architecture , 1st ed., Addison-Wesley, -2002. -``` -``` -[6*] L. Null and J. Lobur, The Essentials of -Computer Organization and Architecture , -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. -``` blob - 901c0328cfceb2f2660d96c4813be8b3c862d795 (mode 644) blob + /dev/null --- 4_software_testing.markdown +++ /dev/null @@ -1,2086 +0,0 @@ -``` -4-1 -``` -**CHAPTER 4** - -**SOFTWARE TESTING** - -##### ACRONYMS - -``` -API Application Program Interface -TDD Test-Driven Development -``` -``` -TTCN3 -Testing and Test Control Notation -Version 3 -XP Extreme Programming -``` -##### INTRODUCTION - -Software testing consists of the _dynamic_ verifica- -tion that a program provides _expected_ behaviors -on a _finite_ set of test cases, suitably _selected_ from -the usually infinite execution domain. -In the above definition, italicized words cor- -respond to key issues in describing the Software -Testing knowledge area (KA): - -- _Dynamic:_ This term means that testing - always implies executing the program on - selected inputs. To be precise, the input - value alone is not always sufficient to spec- - ify a test, since a complex, nondeterministic - system might react to the same input with - different behaviors, depending on the system - state. In this KA, however, the term “input” - will be maintained, with the implied conven- - tion that its meaning also includes a speci- - fied input state in those cases for which it - is important. Static techniques are different - from and complementary to dynamic testing. - Static techniques are covered in the Software - Quality KA. It is worth noting that terminol- - ogy is not uniform among different commu- - nities and some use the term “testing” also in - reference to static techniques. -- _Finite:_ Even in simple programs, so many test - cases are theoretically possible that exhaus- - tive testing could require months or years to - -``` -execute. This is why, in practice, a complete -set of tests can generally be considered infi- -nite, and testing is conducted on a subset of -all possible tests, which is determined by risk -and prioritization criteria. Testing always -implies a tradeoff between limited resources -and schedules on the one hand and inherently -unlimited test requirements on the other. -``` -- _Selected:_ The many proposed test tech- - niques differ essentially in how the test set - is selected, and software engineers must be - aware that different selection criteria may - yield vastly different degrees of effective- - ness. How to identify the most suitable - selection criterion under given conditions is - a complex problem; in practice, risk analysis - techniques and software engineering exper- - tise are applied. -- _Expected:_ It must be possible, although not - always easy, to decide whether the observed - outcomes of program testing are acceptable - or not; otherwise, the testing effort is use- - less. The observed behavior may be checked - against user needs (commonly referred to - as testing for validation), against a speci- - fication (testing for verification), or, per- - haps, against the anticipated behavior from - implicit requirements or expectations (see - Acceptance Tests in the Software Require- - ments KA). - -``` -In recent years, the view of software testing -has matured into a constructive one. Testing is -no longer seen as an activity that starts only after -the coding phase is complete with the limited -purpose of detecting failures. Software testing -is, or should be, pervasive throughout the entire -development and maintenance life cycle. Indeed, -planning for software testing should start with the -early stages of the software requirements process, -``` - -**4-2** **_SWEBOK® Guide_** **V3.0** - -and test plans and procedures should be system- -atically and continuously developed—and possi- -bly refined—as software development proceeds. -These test planning and test designing activities -provide useful input for software designers and -help to highlight potential weaknesses, such as -design oversights/contradictions, or omissions/ -ambiguities in the documentation. -For many organizations, the approach to soft- -ware quality is one of prevention: it is obviously -much better to prevent problems than to correct -them. Testing can be seen, then, as a means for -providing information about the functionality - -``` -and quality attributes of the software and also -for identifying faults in those cases where error -prevention has not been effective. It is perhaps -obvious but worth recognizing that software can -still contain faults, even after completion of an -extensive testing activity. Software failures expe- -rienced after delivery are addressed by corrective -maintenance. Software maintenance topics are -covered in the Software Maintenance KA. -In the Software Quality KA (see Software Qual- -ity Management Techniques), software quality -management techniques are notably categorized -into static techniques (no code execution) and -``` -``` -Figure 4.1. Breakdown of Topics for the Software Testing KA -``` - -``` -Software Testing 4-3 -``` -dynamic techniques (code execution). Both cat- -egories are useful. This KA focuses on dynamic -techniques. -Software testing is also related to software -construction (see Construction Testing in the -Software Construction KA). In particular, unit -and integration testing are intimately related to -software construction, if not part of it. - -**BREAKDOWN OF TOPICS FOR -SOFTWARE TESTING** - -The breakdown of topics for the Software Test- -ing KA is shown in Figure 4.1. A more detailed -breakdown is provided in the Matrix of Topics -vs. Reference Material at the end of this KA. -The first topic describes Software Testing Fun- -damentals. It covers the basic definitions in the -field of software testing, the basic terminology -and key issues, and software testing’s relation- -ship with other activities. -The second topic, Test Levels, consists of two -(orthogonal) subtopics: the first subtopic lists the -levels in which the testing of large software is -traditionally subdivided, and the second subtopic -considers testing for specific conditions or prop- -erties and is referred to as Objectives of Testing. -Not all types of testing apply to every software -product, nor has every possible type been listed. -The test target and test objective together -determine how the test set is identified, both with -regard to its consistency— _how much testing is -enough for achieving the stated objective_ —and -to its composition— _which test cases should -be selected for achieving the stated objective_ -(although usually “for achieving the stated objec- -tive” remains implicit and only the first part of the -two italicized questions above is posed). Criteria -for addressing the first question are referred to as -_test adequacy criteria_ , while those addressing the -second question are the test _selection criteria_. -Several Test Techniques have been developed -in the past few decades, and new ones are still -being proposed. Generally accepted techniques -are covered in the third topic. -Test-Related Measures are dealt with in the -fourth topic, while the issues relative to Test Pro- -cess are covered in the fifth. Finally, Software -Testing Tools are presented in topic six. - -**1. Software Testing Fundamentals** - -``` -1.1. Testing-Related Terminology -``` -``` -1.1.1. Definitions of Testing and Related -Terminology -[1*, c1, c2] [2*, c8] -``` -``` -Definitions of testing and testing-related termi- -nology are provided in the cited references and -summarized as follows. -``` -``` -1.1.2. Faults vs. Failures -[1*, c1s5] [2*, c11] -``` -``` -Many terms are used in the software engineering -literature to describe a malfunction: notably fault , -failure , and error, among others. This terminol- -ogy is precisely defined in [3, c2]. It is essential -to clearly distinguish between the cause of a mal- -function (for which the term fault will be used -here) and an undesired effect observed in the sys- -tem’s delivered service (which will be called a -failure). Indeed there may well be faults in the -software that never manifest themselves as fail- -ures (see Theoretical and Practical Limitations -of Testing in section 1.2, Key Issues). Thus test- -ing can reveal failures, but it is the faults that can -and must be removed [3]. The more generic term -defect can be used to refer to either a fault or a -failure, when the distinction is not important [3]. -However, it should be recognized that the cause -of a failure cannot always be unequivocally iden- -tified. No theoretical criteria exist to definitively -determine, in general, the fault that caused an -observed failure. It might be said that it was the -fault that had to be modified to remove the failure, -but other modifications might have worked just -as well. To avoid ambiguity, one could refer to -failure-causing inputs instead of faults—that is, -those sets of inputs that cause a failure to appear. -``` -``` -1.2. Key Issues -``` -``` -1.2.1. Test Selection Criteria / Test Adequacy -Criteria (Stopping Rules) -[1*, c1s14, c6s6, c12s7] -``` -``` -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- -quacy criteria can be used to decide when suf- -ficient testing will be, or has been accomplished -[4] (see Termination in section 5.1, Practical -Considerations). - -``` -1.2.2. Testing Effectiveness / Objectives for -Testing -[1*, c11s4, c13s11] -``` -Testing effectiveness is determined by analyzing -a set of program executions. Selection of tests to -be executed can be guided by different objectives: -it is only in light of the objective pursued that the -effectiveness of the test set can be evaluated. - -``` -1.2.3. Testing for Defect Discovery -[1*, c1s14] -``` -In testing for defect discovery, a successful test -is one that causes the system to fail. This is quite -different from testing to demonstrate that the -software meets its specifications or other desired -properties, in which case testing is successful if -no failures are observed under realistic test cases -and test environments. - -``` -1.2.4. The Oracle Problem -[1*, c1s9, c9s7] -``` -An oracle is any human or mechanical agent that -decides whether a program behaved correctly -in a given test and accordingly results in a ver- -dict of “pass” or “fail.” There exist many differ- -ent kinds of oracles; for example, unambiguous -requirements specifications, behavioral models, -and code annotations. Automation of mechanized -oracles can be difficult and expensive. - -``` -1.2.5. Theoretical and Practical Limitations of -Testing -[1*, c2s7] -``` -Testing theory warns against ascribing an unjusti- -fied level of confidence to a series of successful -tests. Unfortunately, most established results of -testing theory are negative ones, in that they state -what testing can never achieve as opposed to what -is actually achieved. The most famous quotation - -``` -in this regard is the Dijkstra aphorism that “pro- -gram testing can be used to show the presence of -bugs, but never to show their absence” [5]. The -obvious reason for this is that complete testing is -not feasible in realistic software. Because of this, -testing must be driven based on risk [6, part 1] -and can be seen as a risk management strategy. -``` -``` -1.2.6. The Problem of Infeasible Paths -[1*, c4s7] -``` -``` -Infeasible paths are control flow paths that cannot -be exercised by any input data. They are a signifi- -cant problem in path-based testing, particularly -in automated derivation of test inputs to exercise -control flow paths. -``` -``` -1.2.7. Testability -[1*, c17s2] -``` -``` -The term “software testability” has two related -but different meanings: on the one hand, it refers -to the ease with which a given test coverage -criterion can be satisfied; on the other hand, it -is defined as the likelihood, possibly measured -statistically, that a set of test cases will expose -a failure if the software is faulty. Both meanings -are important. -``` -``` -1.3. Relationship of Testing to Other Activities -``` -``` -Software testing is related to, but different from, -static software quality management techniques, -proofs of correctness, debugging, and program -construction. However, it is informative to con- -sider testing from the point of view of software -quality analysts and of certifiers. -``` -- Testing vs. Static Software Quality Man- - agement Techniques (see Software Quality - Management Techniques in the Software - Quality KA [1*, c12]). -- Testing vs. Correctness Proofs and Formal - Verification (see the Software Engineering - Models and Methods KA [1*, c17s2]). -- Testing vs. Debugging (see Construction - Testing in the Software Construction KA - and Debugging Tools and Techniques in the - Computing Foundations KA [1*, c3s6]). - - -``` -Software Testing 4-5 -``` -- Testing vs. Program Construction (see Con- - struction Testing in the Software Construc- - tion KA [1*, c3s2]). -**2. Test Levels** - -Software testing is usually performed at differ- -ent _levels_ throughout the development and main- -tenance processes. Levels can be distinguished -based on the object of testing, which is called -the _target_ , or on the purpose, which is called the -_objective_ (of the test level). - -_2.1. The Target of the Test_ -[1*, c1s13] [2*, c8s1] - -The target of the test can vary: a single module, a -group of such modules (related by purpose, use, -behavior, or structure), or an entire system. Three -test stages can be distinguished: unit, integra- -tion, and system. These three test stages do not -imply any process model, nor is any one of them -assumed to be more important than the other two. - -``` -2.1.1. Unit Testing -[1*, c3] [2*, c8] -``` -Unit testing verifies the functioning in isolation -of software elements that are separately testable. -Depending on the context, these could be the -individual subprograms or a larger component -made of highly cohesive units. Typically, unit -testing occurs with access to the code being tested -and with the support of debugging tools. The pro- -grammers who wrote the code typically, but not -always, conduct unit testing. - -``` -2.1.2. Integration Testing -[1*, c7] [2*, c8] -``` -Integration testing is the process of verifying the -interactions among software components. Clas- -sical integration testing strategies, such as top- -down and bottom-up, are often used with hierar- -chically structured software. -Modern, systematic integration strategies are -typically architecture-driven, which involves -incrementally integrating the software com- -ponents or subsystems based on identified - -``` -functional threads. Integration testing is often an -ongoing activity at each stage of development -during which software engineers abstract away -lower-level perspectives and concentrate on the -perspectives of the level at which they are inte- -grating. For other than small, simple software, -incremental integration testing strategies are usu- -ally preferred to putting all of the components -together at once—which is often called “big -bang” testing. -``` -``` -2.1.3. System Testing -[1*, c8] [2*, c8] -``` -``` -System testing is concerned with testing the -behavior of an entire system. Effective unit and -integration testing will have identified many of -the software defects. System testing is usually -considered appropriate for assessing the non- -functional system requirements—such as secu- -rity, speed, accuracy, and reliability (see Func- -tional and Non-Functional Requirements in the -Software Requirements KA and Software Qual- -ity Requirements in the Software Quality KA). -External interfaces to other applications, utilities, -hardware devices, or the operating environments -are also usually evaluated at this level. -``` -``` -2.2. Objectives of Testing -[1*, c1s7] -``` -``` -Testing is conducted in view of specific objec- -tives, which are stated more or less explicitly -and with varying degrees of precision. Stating -the objectives of testing in precise, quantitative -terms supports measurement and control of the -test process. -Testing can be aimed at verifying different prop- -erties. Test cases can be designed to check that -the functional specifications are correctly imple- -mented, which is variously referred to in the lit- -erature as conformance testing, correctness test- -ing, or functional testing. However, several other -nonfunctional properties may be tested as well— -including performance, reliability, and usabil- -ity, among many others (see Models and Quality -Characteristics in the Software Quality KA). -Other important objectives for testing include -but are not limited to reliability measurement, -``` - -**4-6** **_SWEBOK® Guide_** **V3.0** - -identification of security vulnerabilities, usability -evaluation, and software acceptance, for which -different approaches would be taken. Note that, -in general, the test objectives vary with the test -target; different purposes are addressed at differ- -ent levels of testing. -The subtopics listed below are those most -often cited in the literature. Note that some kinds -of testing are more appropriate for custom-made -software packages—installation testing, for -example—and others for consumer products, like -beta testing. - -``` -2.2.1. Acceptance / Qualification Testing -[1*, c1s7] [2*, c8s4] -``` -Acceptance / qualification testing determines -whether a system satisfies its acceptance criteria, -usually by checking desired system behaviors -against the customer’s requirements. The cus- -tomer or a customer’s representative thus speci- -fies or directly undertakes activities to check -that their requirements have been met, or in the -case of a consumer product, that the organization -has satisfied the stated requirements for the tar- -get market. This testing activity may or may not -involve the developers of the system. - -``` -2.2.2. Installation Testing -[1*, c12s2] -``` -Often, after completion of system and acceptance -testing, the software is verified upon installation -in the target environment. Installation testing can -be viewed as system testing conducted in the -operational environment of hardware configura- -tions and other operational constraints. Installa- -tion procedures may also be verified. - -``` -2.2.3. Alpha and Beta Testing -[1*, c13s7, c16s6] [2*, c8s4] -``` -Before software is released, it is sometimes given -to a small, selected group of potential users for -trial use ( _alpha_ testing) and/or to a larger set of -representative users ( _beta_ testing). These users -report problems with the product. Alpha and beta -testing are often uncontrolled and are not always -referred to in a test plan. - -``` -2.2.4. Reliability Achievement and Evaluation -[1*, c15] [2*, c15s2] -``` -``` -Testing improves reliability by identifying and -correcting faults. In addition, statistical measures -of reliability can be derived by randomly generat- -ing test cases according to the operational profile of -the software (see Operational Profile in section 3.5, -Usage-Based Techniques). The latter approach is -called operational testing. Using reliability growth -models, both objectives can be pursued together -[3] (see L ife Test, Reliability Evaluation in section -4.1, Evaluation of the Program under Test). -``` -``` -2.2.5. Regression Testing -[1*, c8s11, c13s3] -``` -``` -According to [7], regression testing is the “selec- -tive retesting of a system or component to verify -that modifications have not caused unintended -effects and that the system or component still -complies with its specified requirements.” In -practice, the approach is to show that software -still passes previously passed tests in a test suite -(in fact, it is also sometimes referred to as nonre- -gression testing). For incremental development, -the purpose of regression testing is to show that -software behavior is unchanged by incremen- -tal changes to the software, except insofar as it -should. In some cases, a tradeoff must be made -between the assurance given by regression testing -every time a change is made and the resources -required to perform the regression tests, which -can be quite time consuming due to the large -number of tests that may be executed. Regression -testing involves selecting, minimizing, and/or -prioritizing a subset of the test cases in an exist- -ing test suite [8]. Regression testing can be con- -ducted at each of the test levels described in sec- -tion 2.1, The Target of the Test, and may apply to -functional and nonfunctional testing. -``` -``` -2.2.6. Performance Testing -[1*, c8s6] -``` -``` -Performance testing verifies that the software -meets the specified performance requirements -and assesses performance characteristics—for -instance, capacity and response time. -``` - -``` -Software Testing 4-7 -``` -``` -2.2.7. Security Testing -[1*, c8s3] [2*, c11s4] -``` -Security testing is focused on the verification that -the software is protected from external attacks. In -particular, security testing verifies the confiden- -tiality, integrity, and availability of the systems -and its data. Usually, security testing includes -verification against misuse and abuse of the soft- -ware or system (negative testing). - -``` -2.2.8. Stress Testing -[1*, c8s8] -``` -Stress testing exercises software at the maximum -design load, as well as beyond it, with the goal -of determining the behavioral limits, and to test -defense mechanisms in critical systems. - -``` -2.2.9. Back-to-Back Testing -[7] -``` -IEEE/ISO/IEC Standard 24765 defines back-to- -back testing as “testing in which two or more -variants of a program are executed with the same -inputs, the outputs are compared, and errors are -analyzed in case of discrepancies.” - -``` -2.2.10. Recovery Testing -[1*, c14s2] -``` -Recovery testing is aimed at verifying software -restart capabilities after a system crash or other -“disaster.” - -``` -2.2.11. Interface Testing -[2*, c8s1.3] [9*, c4s4.5] -``` -Interface defects are common in complex sys- -tems. Interface testing aims at verifying whether -the components interface correctly to provide the -correct exchange of data and control informa- -tion. Usually the test cases are generated from -the interface specification. A specific objective of -interface testing is to simulate the use of APIs by -end-user applications. This involves the genera- -tion of parameters of the API calls, the setting of -external environment conditions, and the defini- -tion of internal data that affect the API. - -``` -2.2.12. Configuration Testing -[1*, c8s5] -``` -``` -In cases where software is built to serve different -users, configuration testing verifies the software -under different specified configurations. -``` -``` -2.2.13. Usability and Human Computer Inter- -action Testing -[10*, c6] -``` -``` -The main task of usability and human computer -interaction testing is to evaluate how easy it is -for end users to learn and to use the software. In -general, it may involve testing the software func- -tions that supports user tasks, documentation that -aids users, and the ability of the system to recover -from user errors (see User Interface Design in the -Software Design KA). -``` -**3. Test Techniques** - -``` -One of the aims of testing is to detect as many -failures as possible. Many techniques have been -developed to do this [6, part 4]. These techniques -attempt to “break” a program by being as sys- -tematic as possible in identifying inputs that will -produce representative program behaviors; for -instance, by considering subclasses of the input -domain, scenarios, states, and data flows. -The classification of testing techniques pre- -sented here is based on how tests are generated: -from the software engineer’s intuition and expe- -rience, the specifications, the code structure, the -real or imagined faults to be discovered, predicted -usage, models, or the nature of the application. -One category deals with the combined use of two -or more techniques. -Sometimes these techniques are classified as -white-box (also called glass-box ), if the tests are -based on information about how the software has -been designed or coded, or as black-box if the test -cases rely only on the input/output behavior of -the software. The following list includes those -testing techniques that are commonly used, but -some practitioners rely on some of the techniques -more than others. -``` - -**4-8** **_SWEBOK® Guide_** **V3.0** - -_3.1. Based on the Software Engineer’s Intuition -and Experience_ - -``` -3.1.1. Ad Hoc -``` -Perhaps the most widely practiced technique is -ad hoc testing: tests are derived relying on the -software engineer’s skill, intuition, and experi- -ence with similar programs. Ad hoc testing can -be useful for identifying tests cases that not easily -generated by more formalized techniques. - -``` -3.1.2. Exploratory Testing -``` -Exploratory testing is defined as simultaneous -learning, test design, and test execution [6, part -1]; that is, the tests are not defined in advance -in an established test plan, but are dynamically -designed, executed, and modified. The effective- -ness of exploratory testing relies on the software -engineer’s knowledge, which can be derived -from various sources: observed product behavior -during testing, familiarity with the application, -the platform, the failure process, the type of pos- -sible faults and failures, the risk associated with a -particular product, and so on. - -_3.2. Input Domain-Based Techniques_ - -``` -3.2.1. Equivalence Partitioning -[1*, c9s4] -``` -Equivalence partitioning involves partitioning the -input domain into a collection of subsets (or equiv- -alent classes) based on a specified criterion or rela- -tion. This criterion or relation may be different -computational results, a relation based on control -flow or data flow, or a distinction made between -valid inputs that are accepted and processed by the -system and invalid inputs, such as out of range val- -ues, that are not accepted and should generate an -error message or initiate error processing. A repre- -sentative set of tests (sometimes only one) is usu- -ally taken from each equivalency class. - -``` -3.2.2. Pairwise Testing -[1*, c9s3] -``` -Test cases are derived by combining interesting -values for every pair of a set of input variables - -``` -instead of considering all possible combinations. -Pairwise testing belongs to combinatorial testing , -which in general also includes higher-level com- -binations than pairs: these techniques are referred -to as t-wise , whereby every possible combination -of t input variables is considered. -``` -``` -3.2.3. Boundary-Value Analysis -[1*, c9s5] -``` -``` -Test cases are chosen on or near the boundaries of -the input domain of variables, with the underly- -ing rationale that many faults tend to concentrate -near the extreme values of inputs. An extension of -this technique is robustness testing, wherein test -cases are also chosen outside the input domain of -variables to test program robustness in processing -unexpected or erroneous inputs. -``` -``` -3.2.4. Random Testing -[1*, c9s7] -``` -``` -Tests are generated purely at random (not to be -confused with statistical testing from the opera- -tional profile, as described in Operational Profile -in section 3.5). This form of testing falls under the -heading of input domain testing since the input -domain must be known in order to be able to pick -random points within it. Random testing provides -a relatively simple approach for test automation; -recently, enhanced forms of random testing have -been proposed in which the random input sam- -pling is directed by other input selection criteria -[11]. Fuzz testing or fuzzing is a special form of -random testing aimed at breaking the software; it -is most often used for security testing. -``` -``` -3.3. Code-Based Techniques -``` -``` -3.3.1. Control Flow-Based Criteria -[1*, c4] -``` -``` -Control flow-based coverage criteria are aimed -at covering all the statements, blocks of state- -ments, or specified combinations of statements -in a program. The strongest of the control flow- -based criteria is path testing, which aims to -execute all entry-to-exit control flow paths in a -program’s control flow graph. Since exhaustive -path testing is generally not feasible because of -``` - -``` -Software Testing 4-9 -``` -loops, other less stringent criteria focus on cov- -erage of paths that limit loop iterations such as -statement coverage, branch coverage, and con- -dition/decision testing. The adequacy of such -tests is measured in percentages; for example, -when all branches have been executed at least -once by the tests, 100% branch coverage has -been achieved. - -``` -3.3.2. Data Flow-Based Criteria -[1*, c5] -``` -In data flow-based testing, the control flow graph -is annotated with information about how the -program variables are defined, used, and killed -(undefined). The strongest criterion, all defini- -tion-use paths, requires that, for each variable, -every control flow path segment from a defini- -tion of that variable to a use of that definition is -executed. In order to reduce the number of paths -required, weaker strategies such as all-definitions -and all-uses are employed. - -``` -3.3.3. Reference Models for Code-Based -Testing -[1*, c4] -``` -Although not a technique in itself, the control -structure of a program can be graphically rep- -resented using a flow graph to visualize code- -based testing techniques. A flow graph is a -directed graph, the nodes and arcs of which cor- -respond to program elements (see Graphs and -Trees in the Mathematical Foundations KA). -For instance, nodes may represent statements or -uninterrupted sequences of statements, and arcs -may represent the transfer of control between -nodes. - -_3.4. Fault-Based Techniques_ -[1*, c1s14] - -With different degrees of formalization, fault- -based testing techniques devise test cases spe- -cifically aimed at revealing categories of likely -or predefined faults. To better focus the test case -generation or selection, a _fault model_ can be -introduced that classifies the different types of -faults. - -``` -3.4.1. Error Guessing -[1*, c9s8] -``` -``` -In error guessing, test cases are specifically -designed by software engineers who try to antici- -pate the most plausible faults in a given program. -A good source of information is the history of -faults discovered in earlier projects, as well as the -software engineer’s expertise. -``` -``` -3.4.2. Mutation Testing -[1*, c3s5] -``` -``` -A mutant is a slightly modified version of the -program under test, differing from it by a small -syntactic change. Every test case exercises both -the original program and all generated mutants: -if a test case is successful in identifying the dif- -ference between the program and a mutant, the -latter is said to be “killed.” Originally conceived -as a technique to evaluate test sets (see section -4.2. Evaluation of the Tests Performed), muta- -tion testing is also a testing criterion in itself: -either tests are randomly generated until enough -mutants have been killed, or tests are specifically -designed to kill surviving mutants. In the latter -case, mutation testing can also be categorized as -a code-based technique. The underlying assump- -tion of mutation testing, the coupling effect, -is that by looking for simple syntactic faults, -more complex but real faults will be found. For -the technique to be effective, a large number of -mutants must be automatically generated and -executed in a systematic way [12]. -``` -``` -3.5. Usage-Based Techniques -``` -``` -3.5.1. Operational Profile -[1*, c15s5] -``` -``` -In testing for reliability evaluation (also called -operational testing), the test environment repro- -duces the operational environment of the soft- -ware, or the operational profile , as closely as -possible. The goal is to infer from the observed -test results the future reliability of the software -when in actual use. To do this, inputs are assigned -probabilities, or profiles, according to their fre- -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 -the achievement of reliability objectives and -exercise relative usage and criticality of different -functions similar to what will be encountered in -the operational environment [3]. - -``` -3.5.2. User Observation Heuristics -[10*, c5, c7] -``` -Usability principles can provide guidelines for dis- -covering problems in the design of the user inter- -face [10*, c1s4] (see User Interface Design in the -Software Design KA). Specialized heuristics, also -called usability inspection methods, are applied -for the systematic observation of system usage -under controlled conditions in order to deter- -mine how well people can use the system and its -interfaces. Usability heuristics include cognitive -walkthroughs, claims analysis, field observations, -thinking aloud, and even indirect approaches such -as user questionnaires and interviews. - -_3.6. Model-Based Testing Techniques_ - -A model in this context is an abstract (formal) -representation of the software under test or of -its software requirements (see Modeling in the -Software Engineering Models and Methods KA). -Model-based testing is used to validate require- -ments, check their consistency, and generate test -cases focused on the behavioral aspects of the -software. The key components of model-based -testing are [13]: the notation used to represent the -model of the software or its requirements; work- -flow models or similar models; the test strategy -or algorithm used for test case generation; the -supporting infrastructure for the test execution; -and the evaluation of test results compared to -expected results. Due to the complexity of the -techniques, model-based testing approaches -are often used in conjunction with test automa- -tion harnesses. Model-based testing techniques -include the following. - -``` -3.6.1. Decision Tables -[1*, c9s6] -``` -Decision tables represent logical relationships -between conditions (roughly, inputs) and actions - -``` -(roughly, outputs). Test cases are systematically -derived by considering every possible combina- -tion of conditions and their corresponding resul- -tant actions. A related technique is cause-effect -graphing [1*, c13s6]. -``` -``` -3.6.2. Finite-State Machines -[1*, c10] -``` -``` -By modeling a program as a finite state machine, -tests can be selected in order to cover the states -and transitions. -``` -``` -3.6.3. Formal Specifications -[1*, c10s11] [2*, c15] -``` -``` -Stating the specifications in a formal language -(see Formal Methods in the Software Engineer- -ing Models and Methods KA) permits automatic -derivation of functional test cases, and, at the -same time, provides an oracle for checking test -results. -TTCN3 (Testing and Test Control Notation -version 3) is a language developed for writing test -cases. The notation was conceived for the specific -needs of testing telecommunication systems, so it -is particularly suitable for testing complex com- -munication protocols. -``` -``` -3.6.4. Workflow Models -[2*, c8s3.2, c19s3.1] -``` -``` -Workflow models specify a sequence of activi- -ties performed by humans and/or software appli- -cations, usually represented through graphical -notations. Each sequence of actions constitutes -one workflow (also called a scenario). Both typi- -cal and alternate workflows should be tested [6, -part 4]. A special focus on the roles in a work- -flow specification is targeted in business process -testing. -``` -``` -3.7. Techniques Based on the Nature of the -Application -``` -``` -The above techniques apply to all kinds of soft- -ware. Additional techniques for test derivation -and execution are based on the nature of the soft- -ware being tested; for example, -``` - -``` -Software Testing 4-11 -``` -- object-oriented software -- component-based software -- web-based software -- concurrent programs -- protocol-based software -- real-time systems -- safety-critical systems -- service-oriented software -- open-source software -- embedded software - -_3.8. Selecting and Combining Techniques_ - -``` -3.8.1. Combining Functional and Structural -[1*, c9] -``` -Model-based and code-based test techniques -are often contrasted as functional vs. structural -testing. These two approaches to test selection -are not to be seen as alternatives but rather as -complements; in fact, they use different sources -of information and have been shown to high- -light different kinds of problems. They could be -used in combination, depending on budgetary -considerations. - -``` -3.8.2. Deterministic vs. Random -[1*, c9s6] -``` -Test cases can be selected in a deterministic way, -according to one of many techniques, or ran- -domly drawn from some distribution of inputs, -such as is usually done in reliability testing. Sev- -eral analytical and empirical comparisons have -been conducted to analyze the conditions that -make one approach more effective than the other. - -**4. Test-Related Measures** - -Sometimes testing techniques are confused with -testing objectives. Testing techniques can be -viewed as aids that help to ensure the achieve- -ment of test objectives [6, part 4]. For instance, -branch coverage is a popular testing technique. -Achieving a specified branch coverage measure -(e.g., 95% branch coverage) should not be the -objective of testing per se: it is a way of improv- -ing the chances of finding failures by attempting -to systematically exercise every program branch - -``` -at every decision point. To avoid such misun- -derstandings, a clear distinction should be made -between test-related measures that provide an -evaluation of the program under test, based on -the observed test outputs, and the measures that -evaluate the thoroughness of the test set. (See -Software Engineering Measurement in the Soft- -ware Engineering Management KA for informa- -tion on measurement programs. See Software -Process and Product Measurement in the Soft- -ware Engineering Process KA for information on -measures.) -Measurement is usually considered fundamen- -tal to quality analysis. Measurement may also be -used to optimize the planning and execution of -the tests. Test management can use several differ- -ent process measures to monitor progress. (See -section 5.1, Practical Considerations, for a dis- -cussion of measures of the testing process useful -for management purposes.) -``` -``` -4.1. Evaluation of the Program Under Test -``` -``` -4.1.1. Program Measurements That Aid in -Planning and Designing Tests -[9*, c11] -``` -``` -Measures based on software size (for example, -source lines of code or functional size; see Mea- -suring Requirements in the Software Require- -ments KA) or on program structure can be used -to guide testing. Structural measures also include -measurements that determine the frequency with -which modules call one another. -``` -``` -4.1.2. Fault Types, Classification, and -Statistics -[9*, c4] -``` -``` -The testing literature is rich in classifications and -taxonomies of faults. To make testing more effec- -tive, it is important to know which types of faults -may be found in the software under test and the -relative frequency with which these faults have -occurred in the past. This information can be use- -ful in making quality predictions as well as in -process improvement (see Defect Characteriza- -tion in the Software Quality KA). -``` - -**4-12** **_SWEBOK® Guide_** **V3.0** - -``` -4.1.3. Fault Density -[1*, c13s4] [9*, c4] -``` -A program under test can be evaluated by counting -discovered faults as the ratio between the number -of faults found and the size of the program. - -``` -4.1.4. Life Test, Reliability Evaluation -[1*, c15] [9*, c3] -``` -A statistical estimate of software reliability, -which can be obtained by observing reliabil- -ity achieved, can be used to evaluate a software -product and decide whether or not testing can be -stopped (see section 2.2, Reliability Achievement -and Evaluation). - -``` -4.1.5. Reliability Growth Models -[1*, c15] [9*, c8] -``` -Reliability growth models provide a prediction of -reliability based on failures. They assume, in gen- -eral, that when the faults that caused the observed -failures have been fixed (although some models -also accept imperfect fixes), the estimated prod- -uct’s reliability exhibits, on average, an increasing -trend. There are many published reliability growth -models. Notably, these models are divided into -_failure-count_ and _time-between-failure_ models. - -_4.2. Evaluation of the Tests Performed_ - -``` -4.2.1. Coverage / Thoroughness Measures -[9*, c11] -``` -Several test adequacy criteria require that the test -cases systematically exercise a set of elements -identified in the program or in the specifications -(see topic 3, Test Techniques). To evaluate the -thoroughness of the executed tests, software engi- -neers can monitor the elements covered so that -they can dynamically measure the ratio between -covered elements and the total number. For exam- -ple, it is possible to measure the percentage of -branches covered in the program flow graph or the -percentage of functional requirements exercised -among those listed in the specifications document. -Code-based adequacy criteria require appropriate -instrumentation of the program under test. - -``` -4.2.2. Fault Seeding -[1*, c2s5] [9*, c6] -``` -``` -In fault seeding, some faults are artificially intro- -duced into a program before testing. When the -tests are executed, some of these seeded faults will -be revealed as well as, possibly, some faults that -were already there. In theory, depending on which -and how many of the artificial faults are discov- -ered, testing effectiveness can be evaluated and the -remaining number of genuine faults can be esti- -mated. In practice, statisticians question the dis- -tribution and representativeness of seeded faults -relative to genuine faults and the small sample size -on which any extrapolations are based. Some also -argue that this technique should be used with great -care since inserting faults into software involves -the obvious risk of leaving them there. -``` -``` -4.2.3. Mutation Score -[1*, c3s5] -``` -``` -In mutation testing (see Mutation Testing in sec- -tion 3.4, Fault-Based Techniques), the ratio of -killed mutants to the total number of generated -mutants can be a measure of the effectiveness of -the executed test set. -``` -``` -4.2.4. Comparison and Relative Effectiveness -of Different Techniques -``` -``` -Several studies have been conducted to com- -pare the relative effectiveness of different testing -techniques. It is important to be precise as to the -property against which the techniques are being -assessed; what, for instance, is the exact meaning -given to the term “effectiveness”? Possible inter- -pretations include the number of tests needed to -find the first failure, the ratio of the number of -faults found through testing to all the faults found -during and after testing, and how much reliabil- -ity was improved. Analytical and empirical com- -parisons between different techniques have been -conducted according to each of the notions of -effectiveness specified above. -``` -**5. Test Process** - -``` -Testing concepts, strategies, techniques, and mea- -sures need to be integrated into a defined and -``` - -``` -Software Testing 4-13 -``` -controlled process. The test process supports test- -ing activities and provides guidance to testers and -testing teams, from test planning to test output -evaluation, in such a way as to provide assurance -that the test objectives will be met in a cost-effec- -tive way. - -_5.1. Practical Considerations_ - -``` -5.1.1. Attitudes / Egoless Programming -[1*c16] [9*, c15] -``` -An important element of successful testing is a -collaborative attitude towards testing and quality -assurance activities. Managers have a key role in -fostering a generally favorable reception towards -failure discovery and correction during software -development and maintenance; for instance, by -overcoming the mindset of individual code own- -ership among programmers and by promoting a -collaborative environment with team responsibil- -ity for anomalies in the code. - -``` -5.1.2. Test Guides -[1*, c12s1] [9*, c15s1] -``` -The testing phases can be guided by various -aims—for example, risk-based testing uses the -product risks to prioritize and focus the test strat- -egy, and scenario-based testing defines test cases -based on specified software scenarios. - -``` -5.1.3. Test Process Management -[1*, c12] [9*, c15] -``` -Test activities conducted at different levels (see -topic 2, Test Levels) must be organized—together -with people, tools, policies, and measures—into a -well-defined process that is an integral part of the -life cycle. - -``` -5.1.4. Test Documentation and Work Products -[1*, c8s12] [9*, c4s5] -``` -Documentation is an integral part of the formaliza- -tion of the test process [6, part 3]. Test documents -may include, among others, the test plan, test -design specification, test procedure specification, -test case specification, test log, and test incident -report. The software under test is documented as - -``` -the test item. Test documentation should be pro- -duced and continually updated to the same level -of quality as other types of documentation in -software engineering. Test documentation should -also be under the control of software configura- -tion management (see the Software Configuration -Management KA). Moreover, test documentation -includes work products that can provide material -for user manuals and user training. -``` -``` -5.1.5. Test-Driven Development -[1*, c1s16] -``` -``` -Test-driven development (TDD) originated as one -of the core XP (extreme programming) practices -and consists of writing unit tests prior to writing -the code to be tested (see Agile Methods in the -Software Engineering Models and Method KA). -In this way, TDD develops the test cases as a sur- -rogate for a software requirements specification -document rather than as an independent check -that the software has correctly implemented the -requirements. Rather than a testing strategy, TDD -is a practice that requires software developers to -define and maintain unit tests; it thus can also -have a positive impact on elaborating user needs -and software requirements specifications. -``` -``` -5.1.6. Internal vs. Independent Test Team -[1*, c16] -``` -``` -Formalizing the testing process may also involve -formalizing the organization of the testing team. -The testing team can be composed of internal -members (that is, on the project team, involved or -not in software construction), of external members -(in the hope of bringing an unbiased, independent -perspective), or of both internal and external mem- -bers. Considerations of cost, schedule, maturity -levels of the involved organizations, and criticality -of the application can guide the decision. -``` -``` -5.1.7. Cost/Effort Estimation and Test Process -Measures -[1*, c18s3] [9*, c5s7] -``` -``` -Several measures related to the resources spent -on testing, as well as to the relative fault-finding -effectiveness of the various test phases, are used -by managers to control and improve the testing -``` - -**4-14** **_SWEBOK® Guide_** **V3.0** - -process. These test measures may cover such -aspects as number of test cases specified, num- -ber of test cases executed, number of test cases -passed, and number of test cases failed, among -others. -Evaluation of test phase reports can be com- -bined with root-cause analysis to evaluate test- -process effectiveness in finding faults as early as -possible. Such an evaluation can be associated -with the analysis of risks. Moreover, the resources -that are worth spending on testing should be com- -mensurate with the use/criticality of the applica- -tion: different techniques have different costs and -yield different levels of confidence in product -reliability. - -``` -5.1.8. Termination -[9*, c10s4] -``` -A decision must be made as to how much test- -ing is enough and when a test stage can be termi- -nated. Thoroughness measures, such as achieved -code coverage or functional coverage, as well as -estimates of fault density or of operational reli- -ability, provide useful support but are not suffi- -cient in themselves. The decision also involves -considerations about the costs and risks incurred -by possible remaining failures, as opposed to -the costs incurred by continuing to test (see Test -Selection Criteria / Test Adequacy Criteria in -section 1.2, Key Issues). - -``` -5.1.9. Test Reuse and Test Patterns -[9*, c2s5] -``` -To carry out testing or maintenance in an orga- -nized and cost-effective way, the means used to -test each part of the software should be reused -systematically. A repository of test materials -should be under the control of software con- -figuration management so that changes to soft- -ware requirements or design can be reflected in -changes to the tests conducted. -The test solutions adopted for testing some -application types under certain circumstances, -with the motivations behind the decisions taken, -form a test pattern that can itself be documented -for later reuse in similar projects. - -``` -5.2. Test Activities -``` -``` -As shown in the following description, successful -management of test activities strongly depends -on the software configuration management pro- -cess (see the Software Configuration Manage- -ment KA). -``` -``` -5.2.1. Planning -[1*, c12s1, c12s8] -``` -``` -Like all other aspects of project management, -testing activities must be planned. Key aspects -of test planning include coordination of person- -nel, availability of test facilities and equipment, -creation and maintenance of all test-related docu- -mentation, and planning for possible undesir- -able outcomes. If more than one baseline of the -software is being maintained, then a major plan- -ning consideration is the time and effort needed -to ensure that the test environment is set to the -proper configuration. -``` -``` -5.2.2. Test-Case Generation -[1*, c12s1, c12s3] -``` -``` -Generation of test cases is based on the level of -testing to be performed and the particular testing -techniques. Test cases should be under the con- -trol of software configuration management and -include the expected results for each test. -``` -``` -5.2.3. Test Environment Development -[1*, c12s6] -``` -``` -The environment used for testing should be com- -patible with the other adopted software engi- -neering tools. It should facilitate development -and control of test cases, as well as logging and -recovery of expected results, scripts, and other -testing materials. -``` -``` -5.2.4. Execution -[1*, c12s7] -``` -``` -Execution of tests should embody a basic prin- -ciple of scientific experimentation: everything -done during testing should be performed and -documented clearly enough that another person -``` - -``` -Software Testing 4-15 -``` -could replicate the results. Hence, testing should -be performed in accordance with documented -procedures using a clearly defined version of the -software under test. - -``` -5.2.5. Test Results Evaluation -[9*, c15] -``` -The results of testing should be evaluated to -determine whether or not the testing has been -successful. In most cases, “successful” means -that the software performed as expected and did -not have any major unexpected outcomes. Not -all unexpected outcomes are necessarily faults -but are sometime determined to be simply noise. -Before a fault can be removed, an analysis and -debugging effort is needed to isolate, identify, -and describe it. When test results are particularly -important, a formal review board may be con- -vened to evaluate them. - -``` -5.2.6. Problem Reporting / Test Log -[1*, c13s9] -``` -Testing activities can be entered into a testing -log to identify when a test was conducted, who -performed the test, what software configuration -was used, and other relevant identification infor- -mation. Unexpected or incorrect test results can -be recorded in a problem reporting system, the -data for which forms the basis for later debug- -ging and fixing the problems that were observed -as failures during testing. Also, anomalies not -classified as faults could be documented in case -they later turn out to be more serious than first -thought. Test reports are also inputs to the change -management request process (see Software Con- -figuration Control in the Software Configuration -Management KA). - -``` -5.2.7. Defect Tracking -[9*, c9] -``` -Defects can be tracked and analyzed to determine -when they were introduced into the software, -why they were created (for example, poorly -defined requirements, incorrect variable declara- -tion, memory leak, programming syntax error), -and when they could have been first observed in - -``` -the software. Defect tracking information is used -to determine what aspects of software testing -and other processes need improvement and how -effective previous approaches have been. -``` -**6. Software Testing Tools** - -``` -6.1. Testing Tool Support -[1*, c12s11] [9*, c5] -``` -``` -Testing requires many labor-intensive tasks, run- -ning numerous program executions, and handling -a great amount of information. Appropriate tools -can alleviate the burden of clerical, tedious opera- -tions and make them less error-prone. Sophisti- -cated tools can support test design and test case -generation, making it more effective. -``` -``` -6.1.1. Selecting Tools -[1*, c12s11] -``` -``` -Guidance to managers and testers on how to select -testing tools that will be most useful to their orga- -nization and processes is a very important topic, -as tool selection greatly affects testing efficiency -and effectiveness. Tool selection depends on -diverse evidence, such as development choices, -evaluation objectives, execution facilities, and so -on. In general, there may not be a unique tool that -will satisfy particular needs, so a suite of tools -could be an appropriate choice. -``` -``` -6.2. Categories of Tools -``` -``` -We categorize the available tools according to -their functionality: -``` -- _Test harnesses_ (drivers, stubs) [1*, c3s9] - provide a controlled environment in which - tests can be launched and the test outputs can - be logged. In order to execute parts of a pro- - gram, drivers and stubs are provided to simu- - late calling and called modules, respectively. -- _Test generators_ [1*, c12s11] provide assis- - tance in the generation test cases. The gen- - eration can be random, path-based, model- - based, or a mix thereof. -- _Capture/replay tools_ [1*, c12s11] auto- - matically reexecute, or replay, previously - - -**4-16** **_SWEBOK® Guide_** **V3.0** - -``` -executed tests which have recorded inputs -and outputs (e.g., screens). -``` -- _Oracle/file comparators/assertion checking_ - _tools_ [1*, c9s7] assist in deciding whether a - test outcome is successful or not. -- _Coverage analyzers and instrumenters_ [1*, - c4] work together. Coverage analyzers assess - which and how many entities of the program - flow graph have been exercised amongst all - those required by the selected test coverage - criterion. The analysis can be done thanks to - program instrumenters that insert recording - probes into the code. - - _Tracers_ [1*, c1s7] record the history of a - program’s execution paths. - - _Regression testing tools_ [1*, c12s16] support - the reexecution of a test suite after a section - of software has been modified. They can also - help to select a test subset according to the - change made. - - _Reliability evaluation tools_ [9*, c8] support - test results analysis and graphical visualiza- - tion in order to assess reliability-related mea- - sures according to selected models. - - -``` -Software Testing 4-17 -``` -##### MATRIX OF TOPICS VS. REFERENCE MATERIAL - -``` -Naik and Tripathy 2008 -``` -##### [1*] - -``` -Sommerville 2011 -``` -##### [2*] - -``` -Kan 2003 -``` -##### [9*] - -``` -Nielsen 1993 -``` -##### [10*] - -**1. Software Testing Fundamentals** - 1.1. Testing-Related Terminology - 1.1.1. Definitions of Testing and - Related Terminology - c1,c2 c8 - -``` -1.1.2. Faults vs. Failures c1s5 c11 -1.2. Key Issues -1.2.1. Test Selection Criteria / -Test Adequacy Criteria -(Stopping Rules) -``` -``` -c1s14, c6s6, -c12s7 -``` -``` -1.2.2. Testing Effectiveness / -Objectives for Testing -c13s11, c11s4 -``` -``` -1.2.3. Testing for Defect -Identification -c1s14 -``` -``` -1.2.4. The Oracle Problem -c1s9, -c9s7 -1.2.5. Theoretical and Practical -Limitations of Testing -c2s7 -``` -``` -1.2.6. The Problem of Infeasible -Paths -c4s7 -``` -``` -1.2.7. Te s t a b i l i t y c17s2 -1.3. Relationship of Testing to -Other Activities -1.3.1. Testing vs. Static -Software Quality Management -Te c h n i q u e s -``` -``` -c12 -``` -``` -1.3.2. Testing vs. Correctness -Proofs and Formal Verification -c17s2 -``` -``` -1.3.3. Testing vs. Debugging c3s6 -1.3.4. Testing vs. Programming c3s2 -``` -**2. Te s t L e ve l s** - 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** - -``` -Naik and Tripathy 2008 -``` -##### [1*] - -``` -Sommerville 2011 -``` -##### [2*] - -``` -Kan 2003 -``` -##### [9*] - -``` -Nielsen 1993 -``` -##### [10*] - -``` -2.2. Objectives of Testing c1s7 -2.2.1. Acceptance / Qualification c1s7 c8s4 -2.2.2. Installation Testing c12s2 -``` -``` -2.2.3. Alpha and Beta Testing -c13s7, -c16s6 -c8s4 -``` -``` -2.2.4. Reliability Achievement -and Evaluation -c15 c15s2 -``` -``` -2.2.5. Regression Testing -c8s11, -c13s3 -2.2.6. Pe r fo r m a n c e Te s t i n g c8s6 -2.2.7. Security Testing c8s3 c11s4 -2.2.8. Stress Testing c8s8 -2.2.9. Back-to-Back Testing -2.2.10. R e c ove r y Te s t i n g c14s2 -2.2.11. Interface Testing c8s1.3 c4s4.5 -2.2.12. Configuration Testing c8s5 -2.2.13. Usability and Human -Computer Interaction Testing -c6 -``` -**3. Te s t Te ch n i que s** - 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 - Te c h n i q u e s - 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 - Criteria - c4 - - -``` -Software Testing 4-19 -``` -``` -Naik and Tripathy 2008 -``` -##### [1*] - -``` -Sommerville 2011 -``` -##### [2*] - -``` -Kan 2003 -``` -##### [9*] - -``` -Nielsen 1993 -``` -##### [10*] - -``` -3.3.2. Data Flow-Based Criteria c5 -3.3.3. Reference Models for -Code-Based Testing -c4 -``` -``` -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 -Heuristics -c5, c7 -``` -``` -3.6. Model-Based Testing -Te c h n i q u e s -3.6.1. Decision Table c9s6 -3.6.2. Finite-State Machines c10 -3.6.3. Testing from Formal -Specifications -c10 s11 c15 -``` -``` -3.7. Techniques Based on the -Nature of the Application -3.8. Selecting and Combining -Te c h n i q u e s -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 -Designing Testing -``` -``` -c11 -``` -``` -4.1.2. Fault Types, Classification, -and Statistics -c4 -``` -``` -4.1.3. Fault Density c13s4 c4 -4.1.4. Life Test, Reliability -Evaluation -c15 c3 -``` -``` -4.1.5. Reliability Growth Models c15 c8 -``` - -**4-20** **_SWEBOK® Guide_** **V3.0** - -``` -Naik and Tripathy 2008 -``` -##### [1*] - -``` -Sommerville 2011 -``` -##### [2*] - -``` -Kan 2003 -``` -##### [9*] - -``` -Nielsen 1993 -``` -##### [10*] - -``` -4.2. Evaluation of the Tests -Performed -4.2.1. Coverage / Thoroughness -Measures -c11 -``` -``` -4.2.2. Fault Seeding c2s5 c6 -4.2.3. Mutation Score c3s5 -4.2.4. Comparison and Relative -Effectiveness of Different -Te c h n i q u e s -``` -**5. Test Process** - 5.1. Practical Considerations - 5.1.1. Attitudes / Egoless - Programming - c16 c15 - -``` -5.1.2. Test Guides c12s1 c15s1 -5.1.3. Test Process Management c12 c15 -5.1.4. Test Documentation and -Work Products -c8s12 c4s5 -``` -``` -5.1.5. Test-Driven Development c1s16 -5.1.6. Internal vs. Independent -Te s t Te a m -c16 -``` -``` -5.1.7. Cost/Effort Estimation and -Other Process Measures -c18s3 c5s7 -``` -``` -5.1.8. Termination c10s4 -5.1.9. Test Reuse and Patterns c2s5 -5.2. Test Activities -``` -``` -5.2.1. Planning -c12s1 -c12s8 -``` -``` -5.2.2. Test-Case Generation -c12s1 -c12s3 -5.2.3. Test Environment -Development -c12s6 -``` -``` -5.2.4. Execution c12s7 -5.2.5. Test Results Evaluation c15 -``` - -``` -Software Testing 4-21 -``` -``` -Naik and Tripathy 2008 -``` -##### [1*] - -``` -Sommerville 2011 -``` -##### [2*] - -``` -Kan 2003 -``` -##### [9*] - -``` -Nielsen 1993 -``` -##### [10*] - -``` -5.2.6. Problem Reporting / Test -Log -c13s9 -``` -``` -5.2.7. Defect Tracking c9 -``` -**6. Software Testing Tools** - -``` -6.1. Testing Tool Support c12 s11 c5 -6.1.1. Selecting Tools c12 s11 -``` -``` -6.2. Categories of Tools -``` -``` -c1s7, c3s9, -c4, c9s7, -c12 s11, -c12s16 -``` -``` -c8 -``` - -**4-22** **_SWEBOK® Guide_** **V3.0** - -##### REFERENCES - -[1*] S. Naik and P. Tripathy, _Software Testing -and Quality Assurance: Theory and -Practice_ , Wiley-Spektrum, 2008. - -[2*] I. Sommerville, _Software Engineering_ , 9th -ed., Addison-Wesley, 2011. - -[3] M.R. Lyu, ed., _Handbook of Software -Reliability Engineering_ , McGraw-Hill and -IEEE Computer Society Press, 1996. - -[4] H. Zhu, P.A.V. Hall, and J.H.R. May, -“Software Unit Test Coverage and -Adequacy,” _ACM Computing Surveys,_ vol. -29, no. 4, Dec. 1997, pp. 366–427. - -[5] E.W. Dijkstra, “Notes on Structured -Programming,” T.H.-Report 70-WSE-03, -Technological University, Eindhoven, 1970; -[http://www.cs.utexas.edu/users/EWD/](http://www.cs.utexas.edu/users/EWD/) -ewd02xx/EWD249.PDF. - -[6] _ISO/IEC/IEEE P29119-1/DIS Draft Standard -for Software and Systems Engineering— -Software Testing—Part 1: Concepts and -Definitions_ , ISO/IEC/IEEE, 2012. - -[7] _ISO/IEC/IEEE 24765:2010 Systems and -Software Engineering—Vocabulary_ , ISO/ -IEC/IEEE, 2010. - -``` -[8] S. Yoo and M. Harman, “Regression Testing -Minimization, Selection and Prioritization: -A Survey,” Software Testing Verification -and Reliability, vol. 22, no. 2, Mar. 2012, -pp. 67–120. -``` -``` -[9*] S.H. Kan, Metrics and Models in Software -Quality Engineering , 2nd ed., Addison- -Wesley, 2002. -``` -``` -[10*] J. Nielsen, Usability Engineering , Morgan -Kaufmann, 1993. -``` -``` -[11] T.Y. Chen et al., “Adaptive Random Testing: -The ART of Test Case Diversity,” Journal -of Systems and Software, vol. 83, no. 1, Jan. -2010, pp. 60–66. -``` -``` -[12] Y. Jia and M. Harman, “An Analysis -and Survey of the Development of -Mutation Testing,” IEEE Trans. Software -Engineering, vol. 37, no. 5, Sep.–Oct. 2011, -pp. 649–678. -``` -``` -[13] M. Utting and B. Legeard, Practical -Model-Based Testing: A Tools Approach , -Morgan Kaufmann, 2007. -``` blob - a4a9aed38dc4d32c7e800b961e766968e5908c46 (mode 644) blob + /dev/null --- 5_software_maintenance.markdown +++ /dev/null @@ -1,1287 +0,0 @@ -``` -5-1 -``` -**CHAPTER 5** - -**SOFTWARE MAINTENANCE** - -##### ACRONYMS - -``` -MR Modification Request -PR Problem Report -``` -``` -SCM -Software Configuration -Management -SLA Service-Level Agreement -SQA Software Quality Assurance -V&V Verification and Validation -``` -##### INTRODUCTION - -Software development efforts result in the deliv- -ery of a software product that satisfies user -requirements. Accordingly, the software product -must change or evolve. Once in operation, defects -are uncovered, operating environments change, -and new user requirements surface. The mainte- -nance phase of the life cycle begins following a -warranty period or postimplementation support -delivery, but maintenance activities occur much -earlier. -Software maintenance is an integral part of a -software life cycle. However, it has not received -the same degree of attention that the other phases -have. Historically, software development has had -a much higher profile than software maintenance -in most organizations. This is now changing, as -organizations strive to squeeze the most out of -their software development investment by keep- -ing software operating as long as possible. The -open source paradigm has brought further atten- -tion to the issue of maintaining software artifacts -developed by others. -In this _Guide_ , software maintenance is defined -as the totality of activities required to provide -cost-effective support to software. Activities are -performed during the predelivery stage as well as - -``` -during the postdelivery stage. Predelivery activi- -ties include planning for postdelivery operations, -maintainability, and logistics determination for -transition activities [1*, c6s9]. Postdelivery -activities include software modification, training, -and operating or interfacing to a help desk. -The Software Maintenance knowledge area -(KA) is related to all other aspects of software -engineering. Therefore, this KA description is -linked to all other software engineering KAs of -the Guide. -``` -``` -BREAKDOWN OF TOPICS FOR -SOFTWARE MAINTENANCE -``` -``` -The breakdown of topics for the Software Main- -tenance KA is shown in Figure 5.1. -``` -**1. Software Maintenance Fundamentals** - -``` -This first section introduces the concepts and -terminology that form an underlying basis to -understanding the role and scope of software -maintenance. The topics provide definitions and -emphasize why there is a need for maintenance. -Categories of software maintenance are critical to -understanding its underlying meaning. -``` -``` -1.1. Definitions and Terminology -[1*, c3] [2*, c1s2, c2s2] -``` -``` -The purpose of software maintenance is defined -in the international standard for software mainte- -nance: ISO/IEC/IEEE 14764 [1*].^1 In the context -of software engineering, software maintenance is -essentially one of the many technical processes. -``` -``` -1 For the purpose of conciseness and ease of read- -ing, this standard is referred to simply as IEEE 14764 -in the subsequent text of this KA. -``` - -**5-2** **_SWEBOK® Guide_** **V3.0** - -The objective of software maintenance is to -modify existing software while preserving its -integrity. The international standard also states -the importance of having some maintenance -activities prior to the final delivery of software -(predelivery activities). Notably, IEEE 14764 -emphasizes the importance of the predelivery -aspects of maintenance—planning, for example. - -_1.2. Nature of Maintenance_ -[2*, c1s3] - -Software maintenance sustains the software prod- -uct throughout its life cycle (from development -to operations). Modification requests are logged -and tracked, the impact of proposed changes is -determined, code and other software artifacts are - -``` -modified, testing is conducted, and a new version -of the software product is released. Also, train- -ing and daily support are provided to users. The -term maintainer is defined as an organization that -performs maintenance activities. In this KA, the -term will sometimes refer to individuals who per- -form those activities, contrasting them with the -developers. -IEEE 14764 identifies the primary activities of -software maintenance as process implementation, -problem and modification analysis, modification -implementation, maintenance review/acceptance, -migration, and retirement. These activities are -discussed in section 3.2, Maintenance Activities. -Maintainers can learn from the develop- -ers’ knowledge of the software. Contact with -the developers and early involvement by the -``` -``` -Figure 5.1. Breakdown of Topics for the Software Maintenance KA -``` - -``` -Software Maintenance 5-3 -``` -maintainer helps reduce the overall maintenance -effort. In some instances, the initial developer -cannot be reached or has moved on to other tasks, -which creates an additional challenge for main- -tainers. Maintenance must take software artifacts -from development (for example, code or docu- -mentation) and support them immediately, then -progressively evolve/maintain them over a soft- -ware life cycle. - -_1.3. Need for Maintenance_ -[2*, c1s5] - -Maintenance is needed to ensure that the software -continues to satisfy user requirements. Mainte- -nance is applicable to software that is developed -using any software life cycle model (for example, -spiral or linear). Software products change due -to corrective and noncorrective software actions. -Maintenance must be performed in order to - -- correct faults; -- improve the design; -- implement enhancements; -- interface with other software; -- adapt programs so that different hardware, - software, system features, and telecommuni- - cations facilities can be used; -- migrate legacy software; and -- retire software. - -Five key characteristics comprise the maintain- -er’s activities: - -- maintaining control over the software’s day- - to-day functions; -- maintaining control over software - modification; -- perfecting existing functions; -- identifying security threats and fixing secu- - rity vulnerabilities; and -- preventing software performance from - degrading to unacceptable levels. - -_1.4. Majority of Maintenance Costs_ -[2*, c4s3, c5s5.2] - -Maintenance consumes a major share of the finan- -cial resources in a software life cycle. A common - -``` -perception of software maintenance is that it -merely fixes faults. However, studies and sur- -veys over the years have indicated that the major- -ity, over 80 percent, of software maintenance is -used for noncorrective actions [2*, figure 4.1]. -Grouping enhancements and corrections together -in management reports contributes to some mis- -conceptions regarding the high cost of correc- -tions. Understanding the categories of software -maintenance helps to understand the structure of -software maintenance costs. Also, understanding -the factors that influence the maintainability of -software can help to contain costs. Some environ- -mental factors and their relationship to software -maintenance costs include the following: -``` -- Operating environment refers to hardware - and software. -- Organizational environment refers to poli- - cies, competition, process, product, and - personnel. - -``` -1.5. Evolution of Software -[2*, c3s5] -``` -``` -Software maintenance in terms of evolution was -first addressed in the late 1960s. Over a period of -twenty years, research led to the formulation of -eight “Laws of Evolution.” Key findings include a -proposal that maintenance is evolutionary devel- -opment and that maintenance decisions are aided -by understanding what happens to software over -time. Some state that maintenance is continued -development, except that there is an extra input -(or constraint)–in other words, existing large soft- -ware is never complete and continues to evolve; -as it evolves, it grows more complex unless some -action is taken to reduce this complexity. -``` -``` -1.6. Categories of Maintenance -[1*, c3, c6s2] [2*, c3s3.1] -``` -``` -Three categories (types) of maintenance have -been defined: corrective, adaptive, and perfec- -tive [2*, c4s3]. IEEE 14764 includes a fourth -category–preventative. -``` -- Corrective maintenance: reactive modifi- - cation (or repairs) of a software product - - -**5-4** **_SWEBOK® Guide_** **V3.0** - -``` -performed after delivery to correct discov- -ered problems. Included in this category -is emergency maintenance, which is an -unscheduled modification performed to tem- -porarily keep a software product operational -pending corrective maintenance. -``` -- Adaptive maintenance: modification of a - software product performed after delivery to - keep a software product usable in a changed - or changing environment. For example, - the operating system might be upgraded - and some changes to the software may be - necessary. -- Perfective maintenance: modification of a - software product after delivery to provide - enhancements for users, improvement of - program documentation, and recoding to - improve software performance, maintain- - ability, or other software attributes. -- Preventive maintenance: modification of a - software product after delivery to detect and - correct latent faults in the software product - before they become operational faults. - -IEEE 14764 classifies adaptive and perfective -maintenance as maintenance enhancements. It -also groups together the corrective and preven- -tive maintenance categories into a correction cat- -egory, as shown in Table 5.1. - -``` -Table 5.1. Software Maintenance Categories -``` -``` -Correction Enhancement -``` -``` -Proactive Preventive Perfective -Reactive Corrective Adaptive -``` -**2. Key Issues in Software Maintenance** - -A number of key issues must be dealt with to -ensure the effective maintenance of software. -Software maintenance provides unique techni- -cal and management challenges for software -engineers—for example, trying to find a fault in -software containing a large number of lines of -code that another software engineer developed. -Similarly, competing with software developers -for resources is a constant battle. Planning for a -future release, which often includes coding the - -``` -next release while sending out emergency patches -for the current release, also creates a challenge. -The following section presents some of the tech- -nical and management issues related to software -maintenance. They have been grouped under the -following topic headings: -``` -- technical issues, -- management issues, -- cost estimation, and -- measurement. - -``` -2.1. Technical Issues -``` -``` -2.1.1. Limited Understanding -[2*, c6] -``` -``` -Limited understanding refers to how quickly a -software engineer can understand where to make -a change or correction in software that he or she -did not develop. Research indicates that about half -of the total maintenance effort is devoted to under- -standing the software to be modified. Thus, the -topic of software comprehension is of great inter- -est to software engineers. Comprehension is more -difficult in text-oriented representation—in source -code, for example—where it is often difficult to -trace the evolution of software through its releases/ -versions if changes are not documented and if the -developers are not available to explain it, which is -often the case. Thus, software engineers may ini- -tially have a limited understanding of the software; -much has to be done to remedy this. -``` -``` -2.1.2. Testing -[1*, c6s2.2.2] [2*, c9] -``` -``` -The cost of repeating full testing on a major -piece of software is significant in terms of time -and money. In order to ensure that the requested -problem reports are valid, the maintainer should -replicate or verify problems by running the -appropriate tests. Regression testing (the selec- -tive retesting of software or a component to ver- -ify that the modifications have not caused unin- -tended effects) is an important testing concept in -maintenance. Additionally, finding time to test is -often difficult. Coordinating tests when different -members of the maintenance team are working -``` - -``` -Software Maintenance 5-5 -``` -on different problems at the same time remains a -challenge. When software performs critical func- -tions, it may be difficult to bring it offline to test. -Tests cannot be executed in the most meaning- -ful place–the production system. The Software -Testing KA provides additional information and -references on this matter in its subtopic on regres- -sion testing. - -``` -2.1.3. Impact Analysis -[1*, c5s2.5] [2*, c13s3] -``` -Impact analysis describes how to conduct, cost- -effectively, a complete analysis of the impact of -a change in existing software. Maintainers must -possess an intimate knowledge of the software’s -structure and content. They use that knowledge -to perform impact analysis, which identifies all -systems and software products affected by a soft- -ware change request and develops an estimate of -the resources needed to accomplish the change. -Additionally, the risk of making the change is -determined. The change request, sometimes called -a modification request (MR) and often called a -problem report (PR), must first be analyzed and -translated into software terms. Impact analysis is -performed after a change request enters the soft- -ware configuration management process. IEEE -14764 states the impact analysis tasks: - -- analyze MRs/PRs; -- replicate or verify the problem; -- develop options for implementing the - modification; -- document the MR/PR, the results, and the - execution options; -- obtain approval for the selected modification - option. - -The severity of a problem is often used to -decide how and when it will be fixed. The soft- -ware engineer then identifies the affected com- -ponents. Several potential solutions are provided, -followed by a recommendation as to the best -course of action. -Software designed with maintainability in mind -greatly facilitates impact analysis. More informa- -tion can be found in the Software Configuration -Management KA. - -``` -2.1.4. Maintainability -[1*, c6s8] [2*, c12s5.5] -``` -``` -IEEE 14764 [1*, c3s4] defines maintainability -as the capability of the software product to be -modified. Modifications may include corrections, -improvements, or adaptation of the software to -changes in environment as well as changes in -requirements and functional specifications. -As a primary software quality characteristic, -maintainability should be specified, reviewed, and -controlled during software development activi- -ties in order to reduce maintenance costs. When -done successfully, the software’s maintainability -will improve. Maintainability is often difficult to -achieve because the subcharacteristics are often -not an important focus during the process of soft- -ware development. The developers are, typically, -more preoccupied with many other activities and -frequently prone to disregard the maintainer’s -requirements. This in turn can, and often does, -result in a lack of software documentation and test -environments, which is a leading cause of difficul- -ties in program comprehension and subsequent -impact analysis. The presence of systematic and -mature processes, techniques, and tools helps to -enhance the maintainability of software. -``` -``` -2.2. Management Issues -``` -``` -2.2.1. Alignment with Organizational -Objectives -[2*, c4] -``` -``` -Organizational objectives describe how to demon- -strate the return on investment of software main- -tenance activities. Initial software development is -usually project-based, with a defined time scale and -budget. The main emphasis is to deliver a product -that meets user needs on time and within budget. -In contrast, software maintenance often has the -objective of extending the life of software for as -long as possible. In addition, it may be driven by -the need to meet user demand for software updates -and enhancements. In both cases, the return on -investment is much less clear, so that the view at -the senior management level is often that of a major -activity consuming significant resources with no -clear quantifiable benefit for the organization. -``` - -**5-6** **_SWEBOK® Guide_** **V3.0** - -``` -2.2.2. Staffing -[2*, c4s5, c10s4] -``` -Staffing refers to how to attract and keep soft- -ware maintenance staff. Maintenance is not often -viewed as glamorous work. As a result, software -maintenance personnel are frequently viewed -as “second-class citizens,” and morale therefore -suffers. - -``` -2.2.3. Process -[1*, c5] [2*, c5] -``` -The software life cycle process is a set of activities, -methods, practices, and transformations that peo- -ple use to develop and maintain software and its -associated products. At the process level, software -maintenance activities share much in common -with software development (for example, software -configuration management is a crucial activity in -both). Maintenance also requires several activities -that are not found in software development (see -section 3.2 on unique activities for details). These -activities present challenges to management. - -``` -2.2.4. Organizational Aspects of Maintenance -[1*, c7s2.3] [2*, c10] -``` -Organizational aspects describe how to iden- -tify which organization and/or function will be -responsible for the maintenance of software. The -team that develops the software is not necessar- -ily assigned to maintain the software once it is -operational. -In deciding where the software maintenance -function will be located, software engineering -organizations may, for example, stay with the -original developer or go to a permanent main- -tenance-specific team (or maintainer). Having a -permanent maintenance team has many benefits: - -- allows for specialization; -- creates communication channels; -- promotes an egoless, collegiate atmosphere; -- reduces dependency on individuals; -- allows for periodic audit checks. - -Since there are many pros and cons to each -option, the decision should be made on a case-by- -case basis. What is important is the delegation or - -``` -assignment of the maintenance responsibility to a -single group or person, regardless of the organi- -zation’s structure. -``` -``` -2.2.5. Outsourcing -[3*] -``` -``` -Outsourcing and offshoring software mainte- -nance has become a major industry. Organiza- -tions are outsourcing entire portfolios of soft- -ware, including software maintenance. More -often, the outsourcing option is selected for less -mission-critical software, as organizations are -unwilling to lose control of the software used in -their core business. One of the major challenges -for outsourcers is to determine the scope of the -maintenance services required, the terms of a ser- -vice-level agreement, and the contractual details. -Outsourcers will need to invest in a maintenance -infrastructure, and the help desk at the remote site -should be staffed with native-language speakers. -Outsourcing requires a significant initial invest- -ment and the setup of a maintenance process that -will require automation. -``` -``` -2.3. Maintenance Cost Estimation -``` -``` -Software engineers must understand the different -categories of software maintenance, discussed -above, in order to address the question of estimat- -ing the cost of software maintenance. For plan- -ning purposes, cost estimation is an important -aspect of planning for software maintenance. -``` -``` -2.3.1. Cost Estimation -[2*, c7s2.4] -``` -``` -Section 2.1.3 describes how impact analysis iden- -tifies all systems and software products affected -by a software change request and develops an -estimate of the resources needed to accomplish -that change. -Maintenance cost estimates are affected -by many technical and nontechnical factors. -IEEE 14764 states that “the two most popular -approaches to estimating resources for software -maintenance are the use of parametric models -and the use of experience” [1*, c7s4.1]. A combi- -nation of these two can also be used. -``` - -``` -Software Maintenance 5-7 -``` -``` -2.3.2. Parametric Models -[2*, c12s5.6] -``` -Parametric cost modeling (mathematical models) -has been applied to software maintenance. Of sig- -nificance is that historical data from past main- -tenance are needed in order to use and calibrate -the mathematical models. Cost driver attributes -affect the estimates. - -``` -2.3.3. Experience -[2*, c12s5.5] -``` -Experience, in the form of expert judgment, -is often used to estimate maintenance effort. -Clearly, the best approach to maintenance esti- -mation is to combine historical data and experi- -ence. The cost to conduct a modification (in terms -of number of people and amount of time) is then -derived. Maintenance estimation historical data -should be provided as a result of a measurement -program. - -_2.4. Software Maintenance Measurement_ -[1*, c6s5] [2*, c12] - -Entities related to software maintenance, whose -attributes can be subjected to measurement, -include process, resource, and product [2*, -c12s3.1]. -There are several software measures that can -be derived from the attributes of the software, -the maintenance process, and personnel, includ- -ing size, complexity, quality, understandability, -maintainability, and effort. Complexity measures -of software can also be obtained using available -commercial tools. These measures constitute a -good starting point for the maintainer’s measure- -ment program. Discussion of software process -and product measurement is also presented in the -Software Engineering Process KA. The topic of -a software measurement program is described in -the Software Engineering Management KA. - -``` -2.4.1. Specific Measures -[2*, c12] -``` -The maintainer must determine which measures -are appropriate for a specific organization based -on that organization’s own context. The software - -``` -quality model suggests measures that are specific -for software maintenance. Measures for subchar- -acteristics of maintainability include the follow- -ing [4*, p. 60]: -``` -- Analyzability: measures of the maintainer’s - effort or resources expended in trying either - to diagnose deficiencies or causes of failure - or to identify parts to be modified. -- Changeability: measures of the maintainer’s - effort associated with implementing a speci- - fied modification. -- Stability: measures of the unexpected behav- - ior of software, including that encountered - during testing. -- Testability: measures of the maintainer’s and - users’ effort in trying to test the modified - software. -- Other measures that maintainers use include -- size of the software, -- complexity of the software , -- understandability, and -- maintainability. - -``` -Providing software maintenance effort, by -categories, for different applications provides -business information to users and their organiza- -tions. It can also enable the comparison of soft- -ware maintenance profiles internally within an -organization. -``` -**3. Maintenance Process** - -``` -In addition to standard software engineering pro- -cesses and activities described in IEEE 14764, -there are a number of activities that are unique to -maintainers. -``` -``` -3.1. Maintenance Processes -[1*, c5] [2*, c5] [5, s5.5] -``` -``` -Maintenance processes provide needed activities -and detailed inputs/outputs to those activities as -described in IEEE 14764. The maintenance pro- -cess activities of IEEE 14764 are shown in Figure -5.2. Software maintenance activities include -``` -- process implementation, -- problem and modification analysis, -- modification implementation, - - -**5-8** **_SWEBOK® Guide_** **V3.0** - -- maintenance review/acceptance, -- migration, and -- software retirement. - -``` -Figure 5.2. Software Maintenance Process -``` -``` -Other maintenance process models include: -``` -- quick fix, -- spiral, -- Osborne’s, -- iterative enhancement, and -- reuse-oriented. - -Recently, agile methodologies, which promote -light processes, have been also adapted to main- -tenance. This requirement emerges from the ever- -increasing demand for fast turnaround of main- -tenance services. Improvement to the software -maintenance process is supported by specialized -software maintenance capability maturity models -(see [6] and [7], which are briefly annotated in the -Further Readings section). - -_3.2. Maintenance Activities_ -[1*, c5, c6s8.2, c7s3.3] - -The maintenance process contains the activities -and tasks necessary to modify an existing soft- -ware product while preserving its integrity. These - -``` -activities and tasks are the responsibility of the -maintainer. As already noted, many maintenance -activities are similar to those of software develop- -ment. Maintainers perform analysis, design, cod- -ing, 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 soft- -ware 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. -- Transition: a controlled and coordinated - sequence of activities during which software - is transferred progressively from the devel- - oper to the maintainer. -- Modification request acceptance/rejection: - modifications requesting work beyond a cer- - tain size/effort/complexity may be rejected - by maintainers and rerouted to a developer. -- Maintenance help desk: an end-user and - maintenance coordinated support function - that triggers the assessment, prioritization, - and costing of modification requests. -- Impact analysis: a technique to identify areas - impacted by a potential change; -- Maintenance Service-Level Agreements - (SLAs) and maintenance licenses and con- - tracts: contractual agreements that describe - the services and quality objectives. - -``` -3.2.2. Supporting Activities -[1*, c4s1, c5, c6s7] [2*, c9] -``` -``` -Maintainers may also perform support activities, -such as documentation, software configuration -management, verification and validation, problem -resolution, software quality assurance, reviews, -``` - -``` -Software Maintenance 5-9 -``` -and audits. Another important support activity -consists of training the maintainers and users. - -``` -3.2.3. Maintenance Planning Activities -[1*, c7s3] -``` -An important activity for software maintenance is -planning, and maintainers must address the issues -associated with a number of planning perspec- -tives, including - -- business planning (organizational level), -- maintenance planning (transition level), -- release/version planning (software level), and -- individual software change request planning - (request level). - -At the individual request level, planning is -carried out during the impact analysis (see sec- -tion 2.1.3, Impact Analysis). The release/version -planning activity requires that the maintainer: - -- collect the dates of availability of individual - requests, -- agree with users on the content of subsequent - releases/versions, -- identify potential conflicts and develop - alternatives, -- assess the risk of a given release and develop - a back-out plan in case problems should - arise, and -- inform all the stakeholders. - -Whereas software development projects can -typically last from some months to a few years, -the maintenance phase usually lasts for many -years. Making estimates of resources is a key ele- -ment of maintenance planning. Software main- -tenance planning should begin with the decision -to develop a new software product and should -consider quality objectives. A concept document -should be developed, followed by a maintenance -plan. The maintenance concept for each software -product needs to be documented in the plan [1*, -c7s2] and should address the - -- scope of the software maintenance, -- adaptation of the software maintenance - process, - - identification of the software maintenance - organization, and - - estimate of software maintenance costs. - -``` -The next step is to develop a corresponding -software maintenance plan. This plan should be -prepared during software development and should -specify how users will request software modifica- -tions or report problems. Software maintenance -planning is addressed in IEEE 14764. It provides -guidelines for a maintenance plan. Finally, at -the highest level, the maintenance organization -will have to conduct business planning activities -(budgetary, financial, and human resources) just -like all the other divisions of the organization. -Management is discussed in the chapter Related -Disciplines of Software Engineering. -``` -``` -3.2.4. Software Configuration Management -[1*, c5s1.2.3] [2*, c11] -``` -``` -IEEE 14764 describes software configuration -management as a critical element of the mainte- -nance process. Software configuration manage- -ment procedures should provide for the verifica- -tion, validation, and audit of each step required -to identify, authorize, implement, and release the -software product. -It is not sufficient to simply track modifica- -tion requests or problem reports. The software -product and any changes made to it must be con- -trolled. This control is established by implement- -ing and enforcing an approved software configu- -ration management (SCM) process. The Software -Configuration Management KA provides details -of SCM and discusses the process by which soft- -ware change requests are submitted, evaluated, -and approved. SCM for software maintenance is -different from SCM for software development in -the number of small changes that must be con- -trolled on operational software. The SCM pro- -cess is implemented by developing and following -a software configuration management plan and -operating procedures. Maintainers participate in -Configuration Control Boards to determine the -content of the next release/version. -``` - -**5-10** **_SWEBOK® Guide_** **V3.0** - -``` -3.2.5. Software Quality -[1*, c6s5, c6s7, c6s8] [2*, c12s5.3] -``` -It is not sufficient to simply hope that increased -quality will result from the maintenance of soft- -ware. Maintainers should have a software qual- -ity program. It must be planned and processes -must be implemented to support the maintenance -process. The activities and techniques for Soft- -ware Quality Assurance (SQA), V&V, reviews, -and audits must be selected in concert with all -the other processes to achieve the desired level -of quality. It is also recommended that the main- -tainer adapt the software development processes, -techniques and deliverables (for instance, testing -documentation), and test results. More details can -be found in the Software Quality KA. - -**4. Techniques for Maintenance** - -This topic introduces some of the generally -accepted techniques used in software maintenance. - -_4.1. Program Comprehension_ -[2*, c6, c14s5] - -Programmers spend considerable time reading and -understanding programs in order to implement -changes. Code browsers are key tools for program -comprehension and are used to organize and pres- -ent source code. Clear and concise documentation -can also aid in program comprehension. - -_4.2. Reengineering_ -[2*, c7] - -Reengineering is defined as the examination and -alteration of software to reconstitute it in a new -form, and includes the subsequent implementa- -tion of the new form. It is often not undertaken to -improve maintainability but to replace aging leg- -acy software. Refactoring is a reengineering tech- -nique that aims at reorganizing a program without -changing its behavior. It seeks to improve a pro- -gram structure and its maintainability. Refactor- -ing techniques can be used during minor changes. - -``` -4.3. Reverse Engineering -[1*, c6s2] [2*, c7, c14s5] -``` -``` -Reverse engineering is the process of analyzing -software to identify the software’s components -and their inter-relationships and to create repre- -sentations of the software in another form or at -higher levels of abstraction. Reverse engineer- -ing is passive; it does not change the software -or result in new software. Reverse engineer- -ing efforts produce call graphs and control flow -graphs from source code. One type of reverse -engineering is redocumentation. Another type is -design recovery. Finally, data reverse engineer- -ing, where logical schemas are recovered from -physical databases, has grown in importance over -the last few years. Tools are key for reverse engi- -neering and related tasks such as redocumenta- -tion and design recovery. -``` -``` -4.4. Migration -[1*, c5s5] -``` -``` -During software’s life, it may have to be modi- -fied to run in different environments. In order to -migrate it to a new environment, the maintainer -needs to determine the actions needed to accom- -plish the migration, and then develop and docu- -ment the steps required to effect the migration in -a migration plan that covers migration require- -ments, migration tools, conversion of product -and data, execution, verification, and support. -Migrating software can also entail a number of -additional activities such as -``` -- notification of intent: a statement of why - the old environment is no longer to be sup- - ported, followed by a description of the new - environment and its date of availability; -- parallel operations: make available the - old and new environments so that the user - experiences a smooth transition to the new - environment; -- notification of completion: when the sched- - uled migration is completed, a notification is - sent to all concerned; - - -``` -Software Maintenance 5-11 -``` -- postoperation review: an assessment of par- - allel operation and the impact of changing to - the new environment; -- data archival: storing the old software data. - -_4.5. Retirement_ -[1*, c5s6] - -Once software has reached the end of its use- -ful life, it must be retired. An analysis should -be performed to assist in making the retirement -decision. This analysis should be included in the -retirement plan, which covers retirement require- -ments, impact, replacement, schedule, and effort. -Accessibility of archive copies of data may also -be included. Retiring software entails a number -of activities similar to migration. - -**5. Software Maintenance Tools** - [1*, c6s4] [2*, c14] - -This topic encompasses tools that are particularly -important in software maintenance where exist- -ing software is being modified. Examples regard- -ing program comprehension include - -- program slicers, which select only parts of a - program affected by a change; -- static analyzers, which allow general view- - ing and summaries of a program content; -- dynamic analyzers, which allow the main- - tainer to trace the execution path of a - program; -- data flow analyzers, which allow the main- - tainer to track all possible data flows of a - program; -- cross-referencers, which generate indices of - program components; and -- dependency analyzers, which help maintain- - ers analyze and understand the interrelation- - ships between components of a program. - -``` -Reverse engineering tools assist the process by -working backwards from an existing product to -create artifacts such as specification and design -descriptions, which can then be transformed to -generate a new product from an old one. Main- -tainers also use software test, software configura- -tion management, software documentation, and -software measurement tools. -``` - -**5-12** **_SWEBOK® Guide_** **V3.0** - -##### MATRIX OF TOPICS VS. REFERENCE MATERIAL - -##### IEEE/ISO/IEC 14764 2006 - -##### [1*] - -``` -Grubb and Takang 2003 -``` -##### [2*] - -``` -Sneed 2008 -``` -##### [3*] - -**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. Te s t i n g 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 -Organizational objectives -c4 -``` -``` -2.2.2. Staffing c4s5, c10s4 -``` -``` -2.2.3. Process c5 c5 -2.2.4. Organizational Aspects of -Maintenance -c7s.2.3 c10 -``` -``` -2.2.5. Outsourcing/Offshoring all -``` -``` -2.3. Maintenance Cost Estimation -2.3.1. Cost Estimation c7s4.1 c7s2.4 -``` - -``` -Software Maintenance 5-13 -``` -##### IEEE/ISO/IEC 14764 2006 - -##### [1*] - -``` -Grubb and Takang 2003 -``` -##### [2*] - -``` -Sneed 2008 -``` -##### [3*] - -``` -2.3.2. Parametric Models c12s5.6 -``` -``` -2.3.3. Experience c12s5.5 -2.4. Software Maintenance -Measurement -c6s5 c12, c12s3.1 -``` -``` -2.4.1. Specific Measures c12 -``` -**3. Maintenance Process** - -``` -3.1. Maintenance Processes c5 c5 -``` -``` -3.2. Maintenance Activities -c5, c5s3.2.2, -c6s8.2, c7s3.3 -``` -``` -3.2.1. Unique Activities -c3s10, c6s9, c7s2, -c7s3 -c6,c7 -``` -``` -3.2.2. Supporting Activities c4s1, c5, c6s7 c9 -3.2.3. Maintenance Planning -Activities -c7s2, c7s.3 -``` -``` -3.2.4. Software Configuration -Management -c5s1.2.3 c11 -``` -``` -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 - -A. April and A. Abran, _Software Maintenance -Management: Evaluation and Continuous -Improvement_ [6]. - -This book explores the domain of small software -maintenance processes (S3M). It provides road- -maps for improving software maintenance pro- -cesses in organizations. It describes a software -maintenance specific maturity model organized -by levels which allow for benchmarking and con- -tinuous improvement. Goals for each key prac- -tice area are provided, and the process model pre- -sented is fully aligned with the architecture and -framework of international standards ISO12207, -ISO14764 and ISO15504 and popular maturity -models like ITIL, CoBIT, CMMI and CM3. - -M. Kajko-Mattsson, “Towards a Business -Maintenance Model,” IEEE Int’l Conf. -Software Maintenance [7]. - -This paper presents an overview of the Correc- -tive Maintenance Maturity Model (CM3). In -contrast to other process models, CM3 is a spe- -cialized model, entirely dedicated to corrective -maintenance of software. It views maintenance in -terms of the activities to be performed and their -order, in terms of the information used by these -activities, goals, rules and motivations for their -execution, and organizational levels and roles -involved at various stages of a typical corrective -maintenance process. - -##### REFERENCES - -``` -[1*] IEEE Std. 14764-2006 (a.k.a. ISO/IEC -14764:2006) Standard for Software -Engineering—Software Life Cycle -Processes—Maintenance , IEEE, 2006. -``` -``` -[2*] P. Grubb and A.A. Takang, Software -Maintenance: Concepts and Practice , 2nd -ed., World Scientific Publishing, 2003. -``` -``` -[3*] H.M. Sneed, “Offering Software -Maintenance as an Offshore Service,” Proc. -IEEE Int’l Conf. Software Maintenance -(ICSM 08), IEEE, 2008, pp. 1–5. -``` -``` -[4*] J.W. Moore, The Road Map to Software -Engineering: A Standards-Based Guide , -Wiley-IEEE Computer Society Press, 2006. -``` -``` -[5] ISO/IEC/IEEE 24765:2010 Systems and -Software Engineering—Vocabulary , ISO/ -IEC/IEEE, 2010. -``` -``` -[6] A. April and A. Abran, Software -Maintenance Management: Evaluation -and Continuous Improvement , Wiley-IEEE -Computer Society Press, 2008. -``` -``` -[7] M. Kajko-Mattsson, “Towards a Business -Maintenance Model,” Proc. Int’l Conf. -Software Maintenance , IEEE, 2001, pp. -500–509. -``` blob - c2db2c7d6a9c5cf56daa41724327cce8827ac1c3 (mode 644) blob + /dev/null --- 6_software_configuration_management.markdown +++ /dev/null @@ -1,1454 +0,0 @@ -``` -6-1 -``` -**CHAPTER 6** - -**SOFTWARE CONFIGURATION MANAGEMENT** - -##### ACRONYMS - -``` -CCB Configuration Control Board -CM Configuration Management -FCA Functional Configuration Audit -``` -``` -PCA Physical Configuration Audit -``` -##### SCCB - -``` -Software Configuration Control -Board -SCI Software Configuration Item -``` -``` -SCM -Software Configuration -Management -``` -``` -SCMP -Software Configuration -Management Plan -SCR Software Change Request -``` -``` -SCSA -Software Configuration Status -Accounting -SDD Software Design Document -``` -``` -SEI/ -CMMI -``` -``` -Software Engineering Institute’s -Capability Maturity Model -Integration -SQA Software Quality Assurance -``` -``` -SRS -Software Requirement -Specification -``` -##### INTRODUCTION - -A system can be defined as the combination of -interacting elements organized to achieve one or -more stated purposes [1]. The configuration of a -system is the functional and physical characteris- -tics of hardware or software as set forth in techni- -cal documentation or achieved in a product [1]; it -can also be thought of as a collection of specific -versions of hardware, firmware, or software items -combined according to specific build procedures - -``` -to serve a particular purpose. Configuration man- -agement (CM), then, is the discipline of identify- -ing the configuration of a system at distinct points -in time for the purpose of systematically control- -ling changes to the configuration and maintaining -the integrity and traceability of the configuration -throughout the system life cycle. It is formally -defined as -``` -``` -A discipline applying technical and admin- -istrative direction and surveillance to: iden- -tify and document the functional and physi- -cal characteristics of a configuration item, -control changes to those characteristics, -record and report change processing and -implementation status, and verify compli- -ance with specified requirements. [1] -``` -``` -Software configuration management (SCM) -is a supporting-software life cycle process that -benefits project management, development and -maintenance activities, quality assurance activi- -ties, as well as the customers and users of the end -product. -The concepts of configuration management -apply to all items to be controlled, although there -are some differences in implementation between -hardware CM and software CM. -SCM is closely related to the software qual- -ity assurance (SQA) activity. As defined in the -Software Quality knowledge area (KA), SQA -processes provide assurance that the software -products and processes in the project life cycle -conform to their specified requirements by plan- -ning, enacting, and performing a set of activities -to provide adequate confidence that quality is -being built into the software. SCM activities help -in accomplishing these SQA goals. In some proj- -ect contexts, specific SQA requirements prescribe -certain SCM activities. -``` - -**6-2** **_SWEBOK® Guide_** **V3.0** - -The SCM activities are management and plan- -ning of the SCM process, software configuration -identification, software configuration control, -software configuration status accounting, soft- -ware configuration auditing, and software release -management and delivery. -The Software Configuration Management KA -is related to all the other KAs, since the object -of configuration management is the artifact pro- -duced and used throughout the software engi- -neering process. - -**BREAKDOWN OF TOPICS FOR -SOFTWARE CONFIGURATION -MANAGEMENT** - -The breakdown of topics for the Software Config- -uration Management KA is shown in Figure 6.1. - -**1. Management of the SCM Process** - -SCM controls the evolution and integrity of a -product by identifying its elements; managing and -controlling change; and verifying, recording, and -reporting on configuration information. From the -software engineer’s perspective, SCM facilitates - -``` -development and change implementation activi- -ties. A successful SCM implementation requires -careful planning and management. This, in turn, -requires an understanding of the organizational -context for, and the constraints placed on, the -design and implementation of the SCM process. -``` -``` -1.1. Organizational Context for SCM -[2*, c6, ann. D] [3*, introduction] [4*, c29] -``` -``` -To plan an SCM process for a project, it is neces- -sary to understand the organizational context and -the relationships among organizational elements. -SCM interacts with several other activities or -organizational elements. -The organizational elements responsible for the -software engineering supporting processes may be -structured in various ways. Although the responsi- -bility for performing certain SCM tasks might be -assigned to other parts of the organization (such as -the development organization), the overall respon- -sibility for SCM often rests with a distinct organi- -zational element or designated individual. -Software is frequently developed as part of a -larger system containing hardware and firmware -elements. In this case, SCM activities take place -``` -``` -Figure 6.1. Breakdown of Topics for the Software Configuration Management KA -``` - -``` -Software Configuration Management 6-3 -``` -in parallel with hardware and firmware CM activ- -ities and must be consistent with system-level -CM. Note that firmware contains hardware and -software; therefore, both hardware and software -CM concepts are applicable. -SCM might interface with an organization’s -quality assurance activity on issues such as -records management and nonconforming items. -Regarding the former, some items under SCM -control might also be project records subject to -provisions of the organization’s quality assurance -program. Managing nonconforming items is usu- -ally the responsibility of the quality assurance -activity; however, SCM might assist with track- -ing and reporting on software configuration items -falling into this category. -Perhaps the closest relationship is with the -software development and maintenance orga- -nizations. It is within this context that many of -the software configuration control tasks are con- -ducted. Frequently, the same tools support devel- -opment, maintenance, and SCM purposes. - -_1.2. Constraints and Guidance for the SCM -Process_ -[2*, c6, ann. D, ann. E] [3*, c2, c5] -[5*, c19s2.2] - -Constraints affecting, and guidance for, the SCM -process come from a number of sources. Poli- -cies and procedures set forth at corporate or other -organizational levels might influence or prescribe -the design and implementation of the SCM pro- -cess for a given project. In addition, the contract -between the acquirer and the supplier might con- -tain provisions affecting the SCM process. For -example, certain configuration audits might be -required, or it might be specified that certain items -be placed under CM. When software products to -be developed have the potential to affect public -safety, external regulatory bodies may impose -constraints. Finally, the particular software life -cycle process chosen for a software project and -the level of formalism selected to implement the -software affect the design and implementation of -the SCM process. -Guidance for designing and implementing an -SCM process can also be obtained from “best -practice,” as reflected in the standards on software - -``` -engineering issued by the various standards orga- -nizations (see Appendix B on standards). -``` -``` -1.3. Planning for SCM -[2*, c6, ann. D, ann. E] [3*, c23] [4*, c29] -``` -``` -The planning of an SCM process for a given -project should be consistent with the organi- -zational context, applicable constraints, com- -monly accepted guidance, and the nature of the -project (for example, size, safety criticality, and -security). The major activities covered are soft- -ware configuration identification, software con- -figuration control, software configuration status -accounting, software configuration auditing, and -software release management and delivery. In -addition, issues such as organization and respon- -sibilities, resources and schedules, tool selection -and implementation, vendor and subcontractor -control, and interface control are typically con- -sidered. The results of the planning activity are -recorded in an SCM Plan (SCMP), which is typi- -cally subject to SQA review and audit. -Branching and merging strategies should be -carefully planned and communicated, since they -impact many SCM activities. From an SCM stand- -point, a branch is defined as a set of evolving source -file versions [1]. Merging consists in combining -different changes to the same file [1]. This typi- -cally occurs when more than one person changes a -configuration item. There are many branching and -merging strategies in common use (see the Further -Readings section for additional discussion). -The software development life cycle model -(see Software Life Cycle Models in the Software -Engineering Process KA) also impacts SCM -activities, and SCM planning should take this -into account. For instance, continuous integration -is a common practice in many software develop- -ment approaches. It is typically characterized by -frequent build-test-deploy cycles. SCM activities -must be planned accordingly. -``` -``` -1.3.1. SCM Organization and Responsibilities -[2*, ann. Ds5, ann. Ds6] [3*, c10-11] -[4*, introduction, c29] -``` -``` -To prevent confusion about who will perform -given SCM activities or tasks, organizational -``` - -**6-4** **_SWEBOK® Guide_** **V3.0** - -roles to be involved in the SCM process need -to be clearly identified. Specific responsibilities -for given SCM activities or tasks also need to be -assigned to organizational entities, either by title -or by organizational element. The overall author- -ity and reporting channels for SCM should also be -identified, although this might be accomplished -at the project management or quality assurance -planning stage. - -``` -1.3.2. SCM Resources and Schedules -[2*, ann. Ds8] [3*, c23] -``` -Planning for SCM identifies the staff and tools -involved in carrying out SCM activities and tasks. -It addresses scheduling questions by establishing -necessary sequences of SCM tasks and identify- -ing their relationships to the project schedules -and milestones established at the project manage- -ment planning stage. Any training requirements -necessary for implementing the plans and train- -ing new staff members are also specified. - -``` -1.3.3. Tool Selection and Implementation -[3*, c26s2, c26s6] [4*, c29s5] -``` -As for any area of software engineering, the -selection and implementation of SCM tools -should be carefully planned. The following ques- -tions should be considered: - -- Organization: what motivates tool acquisi- - tion from an organizational perspective? -- Tools: can we use commercial tools or - develop them ourselves? -- Environment: what are the constraints - imposed by the organization and its techni- - cal context? -- Legacy: how will projects use (or not) the - new tools? -- Financing: who will pay for the tools’ - acquisition, maintenance, training, and - customization? -- Scope: how will the new tools be deployed— - for instance, through the entire organization - or only on specific projects? -- Ownership: who is responsible for the intro- - duction of new tools? - - Future: what is the plan for the tools’ use in - the future? - - Change: how adaptable are the tools? - - Branching and merging: are the tools’ capa- - bilities compatible with the planned branch- - ing and merging strategies? - - Integration: do the various SCM tools inte- - grate among themselves? With other tools in - use in the organization? - - Migration: can the repository maintained by - the version control tool be ported to another - version control tool while maintaining com- - plete history of the configuration items it - contains? - -``` -SCM typically requires a set of tools, as -opposed to a single tool. Such tool sets are some- -times referred to as workbenches. In such a con- -text, another important consideration in plan- -ning for tool selection is determining if the SCM -workbench will be open (in other words, tools -from different suppliers will be used in differ- -ent activities of the SCM process) or integrated -(where elements of the workbench are designed -to work together). -The size of the organization and the type of -projects involved may also impact tool selection -(see topic 7, Software Configuration Manage- -ment Tools). -``` -``` -1.3.4. Vendor/Subcontractor Control -[2*, c13] [3*, c13s9, c14s2] -``` -``` -A software project might acquire or make use of -purchased software products, such as compilers -or other tools. SCM planning considers if and -how these items will be taken under configura- -tion control (for example, integrated into the proj- -ect libraries) and how changes or updates will be -evaluated and managed. -Similar considerations apply to subcontracted -software. When using subcontracted software, -both the SCM requirements to be imposed on -the subcontractor’s SCM process as part of the -subcontract and the means for monitoring com- -pliance need to be established. The latter includes -consideration of what SCM information must be -available for effective compliance monitoring. -``` - -``` -Software Configuration Management 6-5 -``` -``` -1.3.5. Interface Control -[2*, c12] [3*, c24s4] -``` -When a software item will interface with -another software or hardware item, a change -to either item can affect the other. Planning for -the SCM process considers how the interfacing -items will be identified and how changes to the -items will be managed and communicated. The -SCM role may be part of a larger, system-level -process for interface specification and control; -it may involve interface specifications, interface -control plans, and interface control documents. -In this case, SCM planning for interface control -takes place within the context of the system- -level process. - -_1.4. SCM Plan_ -[2*, ann. D] [3*, c23] [4*, c29s1] - -The results of SCM planning for a given project -are recorded in a software configuration manage- -ment plan (SCMP), a “living document” which -serves as a reference for the SCM process. It is -maintained (that is, updated and approved) as -necessary during the software life cycle. In imple- -menting the SCMP, it is typically necessary to -develop a number of more detailed, subordinate -procedures defining how specific requirements -will be carried out during day-to-day activities— -for example, which branching strategies will be -used and how frequently builds occur and auto- -mated tests of all kinds are run. -Guidance on the creation and maintenance of -an SCMP, based on the information produced by -the planning activity, is available from a number -of sources, such as [2*]. This reference provides -requirements for the information to be contained -in an SCMP; it also defines and describes six cat- -egories of SCM information to be included in an -SCMP: - -- Introduction (purpose, scope, terms used) -- SCM Management (organization, respon- - sibilities, authorities, applicable policies, - directives, and procedures) -- SCM Activities (configuration identification, - configuration control, and so on) - - SCM Schedules (coordination with other - project activities) - - SCM Resources (tools, physical resources, - and human resources) - - SCMP Maintenance. - -``` -1.5. Surveillance of Software Configuration -Management -[3*, c11s3] -``` -``` -After the SCM process has been implemented, -some degree of surveillance may be necessary -to ensure that the provisions of the SCMP are -properly carried out. There are likely to be spe- -cific SQA requirements for ensuring compliance -with specified SCM processes and procedures. -The person responsible for SCM ensures that -those with the assigned responsibility perform -the defined SCM tasks correctly. The software -quality assurance authority, as part of a compli- -ance auditing activity, might also perform this -surveillance. -The use of integrated SCM tools with process -control capability can make the surveillance -task easier. Some tools facilitate process com- -pliance while providing flexibility for the soft- -ware engineer to adapt procedures. Other tools -enforce process, leaving the software engineer -with less flexibility. Surveillance requirements -and the level of flexibility to be provided to the -software engineer are important considerations -in tool selection. -``` -``` -1.5.1. SCM Measures and Measurement -[3*, c9s2, c25s2–s3] -``` -``` -SCM measures can be designed to provide spe- -cific information on the evolving product or to -provide insight into the functioning of the SCM -process. A related goal of monitoring the SCM -process is to discover opportunities for process -improvement. Measurements of SCM processes -provide a good means for monitoring the effec- -tiveness of SCM activities on an ongoing basis. -These measurements are useful in characteriz- -ing the current state of the process as well as in -providing a basis for making comparisons over -time. Analysis of the measurements may produce -``` - -**6-6** **_SWEBOK® Guide_** **V3.0** - -insights leading to process changes and corre- -sponding updates to the SCMP. -Software libraries and the various SCM tool -capabilities provide sources for extracting infor- -mation about the characteristics of the SCM -process (as well as providing project and man- -agement information). For example, information -about the time required to accomplish various -types of changes would be useful in an evalua- -tion of the criteria for determining what levels of -authority are optimal for authorizing certain types -of changes and for estimating future changes. -Care must be taken to keep the focus of the -surveillance on the insights that can be gained -from the measurements, not on the measurements -themselves. Discussion of software process and -product measurement is presented in the Soft- -ware Engineering Process KA. Software mea- -surement programs are described in the Software -Engineering Management KA. - -``` -1.5.2. In-Process Audits of SCM -[3*, c1s1] -``` -Audits can be carried out during the software -engineering process to investigate the current sta- -tus of specific elements of the configuration or to -assess the implementation of the SCM process. -In-process auditing of SCM provides a more for- -mal mechanism for monitoring selected aspects -of the process and may be coordinated with the -SQA function (see topic 5, Software Configura- -tion Auditing). - -**2. Software Configuration Identification** - [2*, c8] [4*, c29s1.1] - -Software configuration identification identifies -items to be controlled, establishes identification -schemes for the items and their versions, and -establishes the tools and techniques to be used in -acquiring and managing controlled items. These -activities provide the basis for the other SCM -activities. - -_2.1. Identifying Items to Be Controlled_ -[2*, c8s2.2] [4*, c29s1.1] - -One of the first steps in controlling change is -identifying the software items to be controlled. - -``` -This involves understanding the software config- -uration within the context of the system configu- -ration, selecting software configuration items, -developing a strategy for labeling software items -and describing their relationships, and identifying -both the baselines to be used and the procedure -for a baseline’s acquisition of the items. -``` -``` -2.1.1. Software Configuration -[1, c3] -``` -``` -Software configuration is the functional and phys- -ical characteristics of hardware or software as set -forth in technical documentation or achieved in -a product. It can be viewed as part of an overall -system configuration. -``` -``` -2.1.2. Software Configuration Item -[4*, c29s1.1] -``` -``` -A configuration item (CI) is an item or aggre- -gation of hardware or software or both that is -designed to be managed as a single entity. A soft- -ware configuration item (SCI) is a software entity -that has been established as a configuration item -[1]. The SCM typically controls a variety of items -in addition to the code itself. Software items with -potential to become SCIs include plans, specifi- -cations and design documentation, testing mate- -rials, software tools, source and executable code, -code libraries, data and data dictionaries, and -documentation for installation, maintenance, -operations, and software use. -Selecting SCIs is an important process in -which a balance must be achieved between pro- -viding adequate visibility for project control pur- -poses and providing a manageable number of -controlled items. -``` -``` -2.1.3. Software Configuration Item -Relationships -[3*, c7s4] -``` -``` -Structural relationships among the selected -SCIs, and their constituent parts, affect other -SCM activities or tasks, such as software -building or analyzing the impact of proposed -changes. Proper tracking of these relationships -is also important for supporting traceability. -The design of the identification scheme for SCIs -``` - -``` -Software Configuration Management 6-7 -``` -should consider the need to map identified items -to the software structure, as well as the need to -support the evolution of the software items and -their relationships. - -``` -2.1.4. Software Version -[1, c3] [4*, c29s3] -``` -Software items evolve as a software project pro- -ceeds. A version of a software item is an identi- -fied instance of an item. It can be thought of as a -state of an evolving item. A variant is a version of -a program resulting from the application of soft- -ware diversity. - -``` -2.1.5. Baseline -[1, c3] -``` -A software baseline is a formally approved ver- -sion of a configuration item (regardless of media) -that is formally designated and fixed at a specific -time during the configuration item’s life cycle. -The term is also used to refer to a particular ver- -sion of a software configuration item that has -been agreed on. In either case, the baseline can -only be changed through formal change con- -trol procedures. A baseline, together with all -approved changes to the baseline, represents the -current approved configuration. -Commonly used baselines include func- -tional, allocated, developmental, and product - -``` -baselines. The functional baseline corresponds -to the reviewed system requirements. The allo- -cated baseline corresponds to the reviewed -software requirements specification and soft- -ware interface requirements specification. The -developmental baseline represents the evolving -software configuration at selected times during -the software life cycle. Change authority for -this baseline typically rests primarily with the -development organization but may be shared -with other organizations (for example, SCM or -Test). The product baseline corresponds to the -completed software product delivered for sys- -tem integration. The baselines to be used for a -given project, along with the associated levels of -authority needed for change approval, are typi- -cally identified in the SCMP. -``` -``` -2.1.6. Acquiring Software Configuration Items -[3*, c18] -``` -``` -Software configuration items are placed under -SCM control at different times; that is, they are -incorporated into a particular baseline at a particu- -lar point in the software life cycle. The triggering -event is the completion of some form of formal -acceptance task, such as a formal review. Figure -6.2 characterizes the growth of baselined items as -the life cycle proceeds. This figure is based on the -waterfall model for purposes of illustration only; -the subscripts used in the figure indicate versions -``` -``` -Figure 6.2. Acquisition of Items -``` - -**6-8** **_SWEBOK® Guide_** **V3.0** - -of the evolving items. The software change request -(SCR) is described in section 3.1. -In acquiring an SCI, its origin and initial integ- -rity must be established. Following the acquisi- -tion of an SCI, changes to the item must be for- -mally approved as appropriate for the SCI and -the baseline involved, as defined in the SCMP. -Following approval, the item is incorporated into -the software baseline according to the appropriate -procedure. - -_2.2. Software Library_ -[3*, c1s3] [4*, c29s1.2] - -A software library is a controlled collection of -software and related documentation designed to -aid in software development, use, or maintenance -[1]. It is also instrumental in software release man- -agement and delivery activities. Several types of -libraries might be used, each corresponding to the -software item’s particular level of maturity. For -example, a working library could support coding -and a project support library could support test- -ing, while a master library could be used for fin- -ished products. An appropriate level of SCM con- -trol (associated baseline and level of authority for -change) is associated with each library. Security, -in terms of access control and the backup facili- -ties, is a key aspect of library management. -The tool(s) used for each library must support -the SCM control needs for that library—both in -terms of controlling SCIs and controlling access -to the library. At the working library level, this is -a code management capability serving develop- -ers, maintainers, and SCM. It is focused on man- -aging the versions of software items while sup- -porting the activities of multiple developers. At -higher levels of control, access is more restricted -and SCM is the primary user. -These libraries are also an important source -of information for measurements of work and -progress. - -**3. Software Configuration Control** - [2*, c9] [4*, c29s2] - -Software configuration control is concerned -with managing changes during the software -life cycle. It covers the process for determining - -``` -what changes to make, the authority for approv- -ing certain changes, support for the implementa- -tion of those changes, and the concept of formal -deviations from project requirements as well as -waivers of them. Information derived from these -activities is useful in measuring change traffic -and breakage as well as aspects of rework. -``` -``` -3.1. Requesting, Evaluating, and Approving -Software Changes -[2*, c9s2.4] [4*, c29s2] -``` -``` -The first step in managing changes to controlled -items is determining what changes to make. The -software change request process (see a typical -flow of a change request process in Figure 6.3) -provides formal procedures for submitting and -recording change requests, evaluating the poten- -tial cost and impact of a proposed change, and -accepting, modifying, deferring, or rejecting -the proposed change. A change request (CR) is -a request to expand or reduce the project scope; -modify policies, processes, plans, or procedures; -modify costs or budgets; or revise schedules -[1]. Requests for changes to software configura- -tion items may be originated by anyone at any -point in the software life cycle and may include -a suggested solution and requested priority. One -source of a CR is the initiation of corrective -action in response to problem reports. Regardless -of the source, the type of change (for example, -defect or enhancement) is usually recorded on the -Software CR (SCR). -This provides an opportunity for tracking -defects and collecting change activity measure- -ments by change type. Once an SCR is received, -a technical evaluation (also known as an impact -analysis) is performed to determine the extent of -the modifications that would be necessary should -the change request be accepted. A good under- -standing of the relationships among software -(and, possibly, hardware) items is important for -this task. Finally, an established authority—com- -mensurate with the affected baseline, the SCI -involved, and the nature of the change—will -evaluate the technical and managerial aspects -of the change request and either accept, modify, -reject, or defer the proposed change. -``` - -``` -Software Configuration Management 6-9 -``` -``` -3.1.1. Software Configuration Control Board -[2*, c9s2.2] [3*, c11s1] [4*, c29s2] -``` -The authority for accepting or rejecting proposed -changes rests with an entity typically known as a -Configuration Control Board (CCB). In smaller -projects, this authority may actually reside with -the leader or an assigned individual rather than a -multiperson board. There can be multiple levels -of change authority depending on a variety of cri- -teria—such as the criticality of the item involved, -the nature of the change (for example, impact on -budget and schedule), or the project’s current -point in the life cycle. The composition of the -CCBs used for a given system varies depending -on these criteria (an SCM representative would -always be present). All stakeholders, appropriate -to the level of the CCB, are represented. When -the scope of authority of a CCB is strictly soft- -ware, it is known as a Software Configuration -Control Board (SCCB). The activities of the CCB -are typically subject to software quality audit or -review. - -``` -3.1.2. Software Change Request Process -[3*, c1s4, c8s4] -``` -An effective software change request (SCR) pro- -cess requires the use of supporting tools and pro- -cedures for originating change requests, enforc- -ing the flow of the change process, capturing - -``` -CCB decisions, and reporting change process -information. A link between this tool capability -and the problem-reporting system can facilitate -the tracking of solutions for reported problems. -``` -``` -3.2. Implementing Software Changes -[4*, c29] -``` -``` -Approved SCRs are implemented using the -defined software procedures in accordance with -the applicable schedule requirements. Since a -number of approved SCRs might be implemented -simultaneously, it is necessary to provide a means -for tracking which SCRs are incorporated into -particular software versions and baselines. As -part of the closure of the change process, com- -pleted changes may undergo configuration audits -and software quality verification—this includes -ensuring that only approved changes have been -made. The software change request process -described above will typically document the -SCM (and other) approval information for the -change. -Changes may be supported by source code ver- -sion control tools. These tools allow a team of -software engineers, or a single software engineer, -to track and document changes to the source code. -These tools provide a single repository for storing -the source code, can prevent more than one soft- -ware engineer from editing the same module at -the same time, and record all changes made to the -``` -``` -Figure 6.3. Flow of a Change Control Process -``` - -**6-10** **_SWEBOK® Guide_** **V3.0** - -source code. Software engineers check modules -out of the repository, make changes, document -the changes, and then save the edited modules -in the repository. If needed, changes can also be -discarded, restoring a previous baseline. More -powerful tools can support parallel development -and geographically distributed environments. -These tools may be manifested as separate, -specialized applications under the control of an -independent SCM group. They may also appear -as an integrated part of the software engineering -environment. Finally, they may be as elementary -as a rudimentary change control system provided -with an operating system. - -_3.3. Deviations and Waivers_ -[1, c3] - -The constraints imposed on a software engineer- -ing effort or the specifications produced during the -development activities might contain provisions -that cannot be satisfied at the designated point -in the life cycle. A deviation is a written autho- -rization, granted prior to the manufacture of an -item, to depart from a particular performance or -design requirement for a specific number of units -or a specific period of time. A waiver is a writ- -ten authorization to accept a configuration item or -other designated item that is found, during produc- -tion or after having been submitted for inspection, -to depart from specified requirements but is nev- -ertheless considered suitable for use as-is or after -rework by an approved method. In these cases, a -formal process is used for gaining approval for -deviations from, or waivers of, the provisions. - -**4. Software Configuration Status Accounting** - [2*, c10] - -Software configuration status accounting (SCSA) -is an element of configuration management con- -sisting of the recording and reporting of informa- -tion needed to manage a configuration effectively. - -_4.1. Software Configuration Status Information_ -[2*, c10s2.1] - -The SCSA activity designs and operates a sys- -tem for the capture and reporting of necessary -information as the life cycle proceeds. As in any - -``` -information system, the configuration status infor- -mation to be managed for the evolving configura- -tions must be identified, collected, and maintained. -Various information and measurements are needed -to support the SCM process and to meet the con- -figuration status reporting needs of management, -software engineering, and other related activities. -The types of information available include the -approved configuration identification as well as -the identification and current implementation sta- -tus of changes, deviations, and waivers. -Some form of automated tool support is neces- -sary to accomplish the SCSA data collection and -reporting tasks; this could be a database capabil- -ity, a stand-alone tool, or a capability of a larger, -integrated tool environment. -``` -``` -4.2. Software Configuration Status Reporting -[2*, c10s2.4] [3*, c1s5, c9s1, c17] -``` -``` -Reported information can be used by various -organizational and project elements—including -the development team, the maintenance team, -project management, and software quality activi- -ties. Reporting can take the form of ad hoc que- -ries to answer specific questions or the periodic -production of predesigned reports. Some infor- -mation produced by the status accounting activity -during the course of the life cycle might become -quality assurance records. -In addition to reporting the current status of the -configuration, the information obtained by the -SCSA can serve as a basis of various measure- -ments. Examples include the number of change -requests per SCI and the average time needed to -implement a change request. -``` -**5. Software Configuration Auditing** - [2*, c11] - -``` -A software audit is an independent examina- -tion of a work product or set of work products to -assess compliance with specifications, standards, -contractual agreements, or other criteria [1]. -Audits are conducted according to a well-defined -process consisting of various auditor roles and -responsibilities. Consequently, each audit must -be carefully planned. An audit can require a num- -ber of individuals to perform a variety of tasks -over a fairly short period of time. Tools to support -``` - -``` -Software Configuration Management 6-11 -``` -the planning and conduct of an audit can greatly -facilitate the process. -Software configuration auditing determines -the extent to which an item satisfies the required -functional and physical characteristics. Informal -audits of this type can be conducted at key points -in the life cycle. Two types of formal audits might -be required by the governing contract (for exam- -ple, in contracts covering critical software): the -Functional Configuration Audit (FCA) and the -Physical Configuration Audit (PCA). Successful -completion of these audits can be a prerequisite -for the establishment of the product baseline. - -_5.1. Software Functional Configuration Audit_ -[2*, c11s2.1] - -The purpose of the software FCA is to ensure that -the audited software item is consistent with its -governing specifications. The output of the soft- -ware verification and validation activities (see -Verification and Validation in the Software Qual- -ity KA) is a key input to this audit. - -_5.2. Software Physical Configuration Audit_ -[2*, c11s2.2] - -The purpose of the software physical configura- -tion audit (PCA) is to ensure that the design and -reference documentation is consistent with the -as-built software product. - -_5.3. In-Process Audits of a Software Baseline_ -[2*, c11s2.3] - -As mentioned above, audits can be carried out -during the development process to investigate -the current status of specific elements of the con- -figuration. In this case, an audit could be applied -to sampled baseline items to ensure that per- -formance is consistent with specifications or to -ensure that evolving documentation continues to -be consistent with the developing baseline item. - -**6. Software Release Management and -Delivery** - [2*, c14] [3*, c8s2] - -In this context, _release_ refers to the distribu- -tion of a software configuration item outside - -``` -the development activity; this includes internal -releases as well as distribution to customers. When -different versions of a software item are available -for delivery (such as versions for different plat- -forms or versions with varying capabilities), it is -frequently necessary to recreate specific versions -and package the correct materials for delivery of -the version. The software library is a key element -in accomplishing release and delivery tasks. -``` -``` -6.1. Software Building -[4*, c29s4] -``` -``` -Software building is the activity of combining the -correct versions of software configuration items, -using the appropriate configuration data, into an -executable program for delivery to a customer or -other recipient, such as the testing activity. For -systems with hardware or firmware, the executable -program is delivered to the system-building activ- -ity. Build instructions ensure that the proper build -steps are taken in the correct sequence. In addition -to building software for new releases, it is usually -also necessary for SCM to have the capability to -reproduce previous releases for recovery, testing, -maintenance, or additional release purposes. -Software is built using particular versions of -supporting tools, such as compilers (see Com- -piler Basics in the Computing Foundations KA). -It might be necessary to rebuild an exact copy of -a previously built software configuration item. In -this case, supporting tools and associated build -instructions need to be under SCM control to -ensure availability of the correct versions of the -tools. -A tool capability is useful for selecting the cor- -rect versions of software items for a given target -environment and for automating the process of -building the software from the selected versions -and appropriate configuration data. For projects -with parallel or distributed development envi- -ronments, this tool capability is necessary. Most -software engineering environments provide this -capability. These tools vary in complexity from -requiring the software engineer to learn a spe- -cialized scripting language to graphics-oriented -approaches that hide much of the complexity of -an “intelligent” build facility. -The build process and products are often sub- -ject to software quality verification. Outputs of -``` - -**6-12** **_SWEBOK® Guide_** **V3.0** - -the build process might be needed for future refer- -ence and may become quality assurance records. - -_6.2. Software Release Management_ -[4*, c29s3.2] - -Software release management encompasses the -identification, packaging, and delivery of the -elements of a product—for example, an execut- -able program, documentation, release notes, and -configuration data. Given that product changes -can occur on a continuing basis, one concern for -release management is determining when to issue -a release. The severity of the problems addressed -by the release and measurements of the fault den- -sities of prior releases affect this decision. The -packaging task must identify which product items -are to be delivered and then select the correct -variants of those items, given the intended appli- -cation of the product. The information document- -ing the physical contents of a release is known -as a version description document_._ The release -notes typically describe new capabilities, known -problems, and platform requirements necessary -for proper product operation. The package to be -released also contains installation or upgrading -instructions. The latter can be complicated by the -fact that some current users might have versions -that are several releases old. In some cases, release -management might be required in order to track -distribution of the product to various customers -or target systems—for example, in a case where -the supplier was required to notify a customer of -newly reported problems. Finally, a mechanism -to ensure the integrity of the released item can be -implemented—for example by releasing a digital -signature with it. -A tool capability is needed for supporting -these release management functions. It is use- -ful to have a connection with the tool capability -supporting the change request process in order to -map release contents to the SCRs that have been -received. This tool capability might also maintain -information on various target platforms and on -various customer environments. - -**7. Software Configuration Management Tools** - [3*, c26s1] [4*, c8s2] - -``` -When discussing software configuration manage- -ment tools, it is helpful to classify them. SCM -tools can be divided into three classes in terms -of the scope at which they provide support: indi- -vidual support, project-related support, and com- -panywide-process support. -Individual support tools are appropriate and -typically sufficient for small organizations or -development groups without variants of their -software products or other complex SCM require- -ments. They include: -``` -- Version control tools: track, document, and - store individual configuration items such as - source code and external documentation. -- Build handling tools: in their simplest form, - such tools compile and link an executable - version of the software. More advanced - building tools extract the latest version from - the version control software, perform qual- - ity checks, run regression tests, and produce - various forms of reports, among other tasks. -- Change control tools: mainly support the - control of change requests and events noti- - fication (for example, change request status - changes, milestones reached). - -``` -Project-related support tools mainly support -workspace management for development teams -and integrators; they are typically able to sup- -port distributed development environments. Such -tools are appropriate for medium to large organi- -zations with variants of their software products -and parallel development but no certification -requirements. -Companywide-process support tools can typi- -cally automate portions of a companywide pro- -cess, providing support for workflow manage- -ments, roles, and responsibilities. They are able -to handle many items, data, and life cycles. Such -tools add to project-related support by supporting -a more formal development process, including -certification requirements. -``` - -``` -Software Configuration Management 6-13 -``` -##### MATRIX OF TOPICS VS. REFERENCE MATERIAL - -##### IEEE 828-2012 - -##### [2*] - -``` -Hass 2003 -``` -##### [3*] - -``` -Moore 2006 -``` -##### [5*] - -``` -Sommerville 2011 -``` -##### [4*] - -**1. Management of the SCM -Process** - 1.1. Organizational Context for - SCM - c6, ann.D introduction c29 - -``` -1.2. Constraints and Guidance -for the SCM Process -``` -``` -c6, ann.D, -ann.E -c2 c19s2.2 c29 intro -``` -``` -1.3. Planning for SCM -c6, ann.D, -ann.E -c23 c29 -``` -``` -1.3.1. SCM Organization and -Responsibilities -ann.Ds5–6 c10–11 c29 intro -``` -``` -1.3.2. SCM Resources and -Schedules -ann.Ds8 c23 -``` -``` -1.3.3. Tool Selection and -Implementation -c26s2; s6 c29s5 -``` -``` -1.3.4. Vendor/Subcontractor -Control -c13 c13s9–c14s2 -``` -``` -1.3.5. Interface Control c12 c24s4 -1.4. SCM Plan ann.D c23 c29s1 -1.5. Surveillance of Software -Configuration Management -c11s3 -``` -``` -1.5.1. SCM Measures and -Measurement -``` -``` -c9s2; -c25s2–s3 -1.5.2. In-Process Audits of -SCM -c1s1 -``` -**2. Software Configuration -Identification** - c29s1.1 - -``` -2.1. Identifying Items to Be -Controlled -c8s2.2 c29s1.1 -``` -``` -2.1.1. Software Configuration -2.1.2. Software Configuration -Item -c29s1.1 -``` -``` -2.1.3. Software Configuration -Item Relationships -c7s4 -``` -``` -2.1.4. Software Version c29s3 -``` - -**6-14** **_SWEBOK® Guide_** **V3.0** - -##### IEEE 828-2012 - -##### [2*] - -``` -Hass 2003 -``` -##### [3*] - -``` -Moore 2006 -``` -##### [5*] - -``` -Sommerville 2011 -``` -##### [4*] - -``` -2.1.5. Baseline -2.1.6. Acquiring Software -Configuration Items -c18 -``` -``` -2.2. Software Library c1s3 c29s1.2 -``` -**3. Software Configuration -Control** - c9 c29s2 - -``` -3.1. Requesting, Evaluating, and -Approving Software Changes -c9s2.4 c29s2 -``` -``` -3.1.1. Software Configuration -Control Board -c9s2.2 c11s1 c29s2 -``` -``` -3.1.2. Software Change -Request Process -c1s4, c8s4 -``` -``` -3.2. Implementing Software -Changes -c29 -``` -``` -3.3. Deviations and Waivers -``` -**4. Software Configuration -Status Accounting** - c10 - -``` -4.1. Software Configuration -Status Information -c10 s2.1 -``` -``` -4.2. Software Configuration -Status Reporting -c10s2.4 -c1s5, c9s1, -c17 -``` -**5. Software Configuration -Auditing** - c11 - -``` -5.1. Software Functional -Configuration Audit -c11s 2 .1 -``` -``` -5.2. Software Physical -Configuration Audit -c11s 2. 2 -``` -``` -5.3. In-Process Audits of a -Software Baseline -c11s2.3 -``` -**6. Software Release -Management and Delivery** c14 c8s2 c29s3 - 6.1. Software Building c29s4 - 6.2. Software Release - Management - c29s3.2 -**7. Software Configuration -Management Tools** - c26s1 - - -``` -Software Configuration Management 6-15 -``` -##### FURTHER READINGS - -Stephen P. Berczuk and Brad Appleton, -_Software Configuration Management -Patterns: Effective Teamwork, Practical -Integration_ [6]. - -This book expresses useful SCM practices and -strategies as patterns. The patterns can be imple- -mented using various tools, but they are expressed -in a tool-agnostic fashion. - -“CMMI for Development,” Version 1.3, pp. -137–147 [7]. - -This model presents a collection of best prac- -tices to help software development organizations -improve their processes. At maturity level 2, it -suggests configuration management activities. - -##### REFERENCES - -``` -[1] ISO/IEC/IEEE 24765:2010 Systems and -Software Engineering—Vocabulary , ISO/ -IEC/IEEE, 2010. -``` -``` -[2*] IEEE Std. 828-2012, Standard for -Configuration Management in Systems and -Software Engineering , IEEE, 2012. -``` -``` -[3*] A.M.J. Hass, Configuration Management -Principles and Practices , 1st ed., Addison- -Wesley, 2003. -``` -``` -[4*] I. Sommerville, Software Engineering , 9th -ed., Addison-Wesley, 2011. -``` -``` -[5*] J.W. Moore, The Road Map to Software -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. -``` blob - 36f6bd023595773c93f3df2cffc67b9e533f681f (mode 644) blob + /dev/null --- 7_software_engineering_management.markdown +++ /dev/null @@ -1,1399 +0,0 @@ -``` -7-1 -``` -**CHAPTER 7** - -**SOFTWARE ENGINEERING MANAGEMENT** - -##### ACRONYMS - -##### PMBOK ® - -``` -Guide -``` -``` -Guide to the Project Management -Body of Knowledge -SDLC Software Development Life Cycle -SEM Software Engineering Management -SQA Software Quality Assurance -``` -``` -SWX -Software Extension to the PMBOK ® -Guide -WBS Work Breakdown Structure -``` -##### INTRODUCTION - -Software engineering management can be defined -as the application of management activities—plan- -ning, coordinating, measuring, monitoring, con- -trolling, and reporting^1 —to ensure that software -products and software engineering services are -delivered efficiently, effectively, and to the benefit -of stakeholders. The related discipline of manage- -ment is an important element of all the knowledge -areas (KAs), but it is of course more relevant to -this KA than to other KAs. Measurement is also an -important aspect of all KAs; the topic of measure- -ment programs is presented in this KA. -In one sense, it should be possible to manage -a software engineering project in the same way -other complex endeavors are managed. However, -there are aspects specific to software projects -and software life cycle processes that complicate -effective management, including these: - -1 The terms Initiating, Planning, Executing, -Monitoring and Controlling, and Closing are used to -describe process groups in the _PMBOK_ ® _Guide_ and -_SWX_. - -- Clients often don’t know what is needed or - what is feasible. -- Clients often lack appreciation for the com- - plexities inherent in software engineering, - particularly regarding the impact of chang- - ing requirements. -- It is likely that increased understanding and - changing conditions will generate new or - changed software requirements. -- As a result of changing requirements, soft- - ware is often built using an iterative process - rather than as a sequence of closed tasks. -- Software engineering necessarily incorpo- - rates creativity and discipline. Maintaining - an appropriate balance between the two is - sometimes difficult. -- The degree of novelty and complexity is - often high. -- There is often a rapid rate of change in the - underlying technology. - -``` -Software engineering management activities -occur at three levels: organizational and infra- -structure management, project management, -and management of the measurement program. -The last two are covered in detail in this KA -description. However, this is not to diminish the -importance of organizational and infrastructure -management issues. It is generally agreed that -software organizational engineering managers -should be conversant with the project manage- -ment and software measurement knowledge -described in this KA. They should also possess -some target domain knowledge. Likewise, it is -also helpful if managers of complex projects and -programs in which software is a component of -the system architecture are aware of the differ- -ences that software processes introduce into proj- -ect management and project measurement. -``` - -**7-2** **_SWEBOK® Guide_** **V3.0** - -Other aspects of organizational management -exert an impact on software engineering (for -example, organizational policies and procedures -that provide the framework in which software -engineering projects are undertaken). These poli- -cies and procedures may need to be adjusted by -the requirements for effective software develop- -ment and maintenance. In addition, a number of -policies specific to software engineering may -need to be in place or established for effective -management of software engineering at the orga- -nizational level. For example, policies are usually -necessary to establish specific organization-wide -processes or procedures for software engineering -tasks such as software design, software construc- -tion, estimating, monitoring, and reporting. Such -policies are important for effective long-term -management of software engineering projects -across an organization (for example, establishing -a consistent basis by which to analyze past proj- -ect performance and implement improvements). - -``` -Another important aspect of organizational -management is personnel management policies -and procedures for hiring, training, and mentor- -ing personnel for career development, not only at -the project level, but also to the longer-term suc- -cess of an organization. Software engineering per- -sonnel may present unique training or personnel -management challenges (for example, maintaining -currency in a context where the underlying tech- -nology undergoes rapid and continuous change). -Communication management is also often -mentioned as an overlooked but important aspect -of the performance of individuals in a field where -precise understanding of user needs, software -requirements, and software designs is necessary. -Furthermore, portfolio management, which pro- -vides an overall view, not only of software cur- -rently under development in various projects and -programs (integrated projects), but also of soft- -ware planned and currently in use in an organiza- -tion, is desirable. Also, software reuse is a key -``` -``` -Figure 7.1. Breakdown of Topics for the Software Engineering Management KA -``` - -``` -Software Engineering Management 7-3 -``` -factor in maintaining and improving productivity -and competitiveness. Effective reuse requires a -strategic vision that reflects the advantages and -disadvantages of reuse. -In addition to understanding the aspects of -management that are uniquely influenced by soft- -ware projects, software engineers should have -some knowledge of the more general aspects of -management that are discussed in this KA (even -in the first few years after graduation). -Attributes of organizational culture and behav- -ior, plus management of other functional areas -of the enterprise, have an influence, albeit indi- -rectly, on an organization’s software engineering -processes. -Extensive information concerning software -project management can be found in the _Guide -to the Project Management Body of Knowledge -(PMBOK_ ® _Guide)_ and the _Software Extension to -the PMBOK_ ® _Guide_ ( _SWX_ ) [1] [2]. Each of these -guides includes ten project management KAs: -project integration management, project scope -management, project time management, project -cost management, project quality management, -project human resource management, project -communications management, project risk man- -agement, project procurement management, and -project stakeholder management. Each KA has -direct relevance to this Software Engineering -Management KA. -Additional information is also provided in the -other references and further readings for this KA. -This Software Engineering Management KA -consists of the software project management pro- -cesses in the first five topics in Figure 7.1 (Initia- -tion and Scope Definition, Software Project Plan- -ning, Software Project Enactment, Review and -Evaluation, Closure), plus Software Engineering -Measurement in the sixth topic and Software -Engineering Management Tools in the seventh -topic. While project management and measure- -ment management are often regarded as being -separate, and indeed each does possess many -unique attributes, the close relationship has led to -combined treatment in this KA. -Unfortunately, a common perception of the soft- -ware industry is that software products are deliv- -ered late, over budget, of poor quality, and with -incomplete functionality. Measurement-informed - -``` -management—a basic principle of any true engi- -neering discipline (see Measurement in the Engi- -neering Foundations KA)—can help improve -the perception and the reality. In essence, man- -agement without measurement (qualitative and -quantitative) suggests a lack of discipline, and -measurement without management suggests a -lack of purpose or context. Effective management -requires a combination of both measurement and -experience. -The following working definitions are adopted -here: -``` -- _Management_ is a system of processes and - controls required to achieve the strategic - objectives set by the organization. -- _Measurement_ refers to the assignment of val- - ues and labels to software engineering work - products, processes, and resources plus the - models that are derived from them, whether - these models are developed using statistical - or other techniques [3* , c7, c8]. - -``` -The software engineering project management -sections in this KA make extensive use of the -software engineering measurement section. -This KA is closely related to others in the -SWEBOK Guide , and reading the following KA -descriptions in conjunction with this one will be -particularly helpful: -``` -- The Engineering Foundations KA describes - some general concepts of measurement that - are directly applicable to the Software Engi- - neering Measurement section of this KA. - In addition, the concepts and techniques - presented in the Statistical Analysis section - of the Engineering Foundations KA apply - directly to many topics in this KA. -- The Software Requirements KA describes - some of the activities that should be per- - formed during the Initiation and Scope defi- - nition phase of the project. -- The Software Configuration Management - KA deals with identification, control, status - accounting, and auditing of software con- - figurations along with software release man- - agement and delivery and software configu- - ration management tools. - - -**7-4** **_SWEBOK® Guide_** **V3.0** - -- The Software Engineering Process KA - describes software life cycle models and the - relationships between processes and work - products. -- The Software Quality KA emphasizes qual- - ity as a goal of management and as an aim of - many software engineering activities. -- The Software Engineering Economics KA - discusses how to make software-related - decisions in a business context. - -**BREAKDOWN OF TOPICS FOR -SOFTWARE ENGINEERING -MANAGEMENT** - -Because most software development life cycle -models require similar activities that may be exe- -cuted in different ways, the breakdown of topics -is activity-based. That breakdown is shown in -Figure 7.1. The elements of the top-level break- -down shown in that figure are the activities that -are usually performed when a software develop- -ment project is being managed, independent of -the software development life cycle model (see -Software Life Cycle Models in the Software -Engineering Process KA) that has been chosen for -a specific project. There is no intent in this break- -down to recommend a specific life cycle model. -The breakdown implies only what happens and -does not imply when, how, or how many times -each activity occurs. The seven topics are: - -- Initiation and Scope Definition, which deal - with the decision to embark on a software - engineering project; -- Software Project Planning, which addresses - the activities undertaken to prepare for a suc- - cessful software engineering project from - the management perspective; -- Software Project Enactment, which deals - with generally accepted software engineering - management activities that occur during the - execution of a software engineering project; -- Review and Evaluation, which deal with - ensuring that technical, schedule, cost, and - quality engineering activities are satisfactory; -- Closure, which addresses the activities - accomplished to complete a project; -- Software Engineering Measurement, which - deals with the effective development and - -``` -implementation of measurement programs in -software engineering organizations; -``` -- Software Engineering Management Tools, - which describes the selection and use of tools - for managing a software engineering project. -**1. Initiation and Scope Definition** - -``` -The focus of these activities is on effective deter- -mination of software requirements using vari- -ous elicitation methods and the assessment of -project feasibility from a variety of standpoints. -Once project feasibility has been established, the -remaining tasks within this section are the speci- -fication of requirements and selection of the pro- -cesses for revision and review of requirements. -``` -``` -1.1. Determination and Negotiation of -Requirements -[3*, c3] -``` -``` -Determining and negotiating requirements set -the visible boundaries for the set of tasks being -undertaken (see the Software Requirements KA). -Activities include requirements elicitation, analy- -sis, specification, and validation. Methods and -techniques should be selected and applied, taking -into account the various stakeholder perspectives. -This leads to the determination of project scope in -order to meet objectives and satisfy constraints. -``` -``` -1.2. Feasibility Analysis -[4*, c4] -``` -``` -The purpose of feasibility analysis is to develop a -clear description of project objectives and evalu- -ate alternative approaches in order to determine -whether the proposed project is the best alterna- -tive given the constraints of technology, resources, -finances, and social/political considerations. An -initial project and product scope statement, project -deliverables, project duration constraints, and an -estimate of resources needed should be prepared. -Resources include a sufficient number of -people who have the needed skills, facilities, -infrastructure, and support (either internally or -externally). Feasibility analysis often requires -approximate estimations of effort and cost based -on appropriate methods (see section 2.3, Effort, -Schedule, and Cost Estimation). -``` - -``` -Software Engineering Management 7-5 -``` -_1.3. Process for the Review and Revision of -Requirements_ -[3*, c3] - -Given the inevitability of change, stakeholders -should agree on the means by which requirements -and scope are to be reviewed and revised (for -example, change management procedures, itera- -tive cycle retrospectives). This clearly implies -that scope and requirements will not be “set in -stone” but can and should be revisited at predeter- -mined points as the project unfolds (for example, -at the time when backlog priorities are created or -at milestone reviews). If changes are accepted, -then some form of traceability analysis and risk -analysis should be used to ascertain the impact -of those changes (see section 2.5, Risk Manage- -ment, and Software Configuration Control in the -Software Configuration Management KA). -A managed-change approach can also form the -basis for evaluation of success during closure of -an incremental cycle or an entire project, based -on changes that have occurred along the way (see -topic 5, Closure). - -**2. Software Project Planning** - -The first step in software project planning should -be selection of an appropriate software develop- -ment life cycle model and perhaps tailoring it -based on project scope, software requirements, -and a risk assessment. Other factors to be consid- -ered include the nature of the application domain, -functional and technical complexity, and soft- -ware quality requirements (see Software Quality -Requirements in the Software Quality KA). -In all SDLCs, risk assessment should be an -element of initial project planning, and the “risk -profile” of the project should be discussed and -accepted by all relevant stakeholders. Software -quality management processes (see Software -Quality Management Processes in the Software -Quality KA) should be determined as part of the -planning process and result in procedures and -responsibilities for software quality assurance, -verification and validation, reviews, and audits -(see the Software Quality KA). Processes and -responsibilities for ongoing review and revision -of the project plan and related plans should also -be clearly stated and agreed upon. - -``` -2.1. Process Planning -[3*, c3, c4, c5] [5*, c1] -``` -``` -Software development life cycle (SDLC) mod- -els span a continuum from predictive to adaptive -(see Software Life Cycle Models in the Software -Engineering Process KA). Predictive SDLCs are -characterized by development of detailed soft- -ware requirements, detailed project planning, and -minimal planning for iteration among develop- -ment phases. Adaptive SDLCs are designed to -accommodate emergent software requirements -and iterative adjustment of plans. A highly pre- -dictive SDLC executes the first five processes -listed in Figure 7.1 in a linear sequence with revi- -sions to earlier phases only as necessary. Adap- -tive SDLCs are characterized by iterative devel- -opment cycles. SDLCs in the mid-range of the -SDLC continuum produce increments of func- -tionality on either a preplanned schedule (on the -predictive side of the continuum) or as the prod- -ucts of frequently updated development cycles -(on the adaptive side of the continuum). -Well-known SDLCs include the waterfall, -incremental, and spiral models plus various forms -of agile software development [2] [3*, c2]. -Relevant methods (see the Software Engineer- -ing Models and Methods KA) and tools should be -selected as part of planning. Automated tools that -will be used throughout the project should also -be planned for and acquired. Tools may include -tools for project scheduling, software require- -ments, software design, software construction, -software maintenance, software configuration -management, software engineering process, soft- -ware quality, and others. While many of these -tools should be selected based primarily on the -technical considerations discussed in other KAs, -some of them are closely related to the manage- -ment considerations discussed in this chapter. -``` -``` -2.2. Determine Deliverables -[3*, c4, c5, c6] -``` -``` -The work product(s) of each project activity (for -example, software architecture design docu- -ments, inspection reports, tested software) should -be identified and characterized. Opportunities to -reuse software components from previous proj- -ects or to utilize off-the-shelf software products -``` - -**7-6** **_SWEBOK® Guide_** **V3.0** - -should be evaluated. Procurement of software -and use of third parties to develop deliverables -should be planned and suppliers selected (see -section 3.2, Software Acquisition and Supplier -Contract Management). - -_2.3. Effort, Schedule, and Cost Estimation_ -[3*, c6] - -The estimated range of effort required for a proj- -ect, or parts of a project, can be determined using -a calibrated estimation model based on historical -size and effort data (when available) and other -relevant methods such as expert judgment and -analogy. Task dependencies can be established -and potential opportunities for completing tasks -concurrently and sequentially can be identified -and documented using a Gantt chart, for exam- -ple. For predictive SDLC projects, the expected -schedule of tasks with projected start times, dura- -tions, and end times is typically produced during -planning. For adaptive SDLC projects, an over- -all estimate of effort and schedule is typically -developed from the initial understanding of the -requirements, or, alternatively, constraints on -overall effort and schedule may be specified and -used to determine an initial estimate of the num- -ber of iterative cycles and estimates of effort and -other resources allocated to each cycle. -Resource requirements (for example, people -and tools) can be translated into cost estimates. -Initial estimation of effort, schedule, and cost is -an iterative activity that should be negotiated and -revised among affected stakeholders until con- -sensus is reached on resources and time available -for project completion. - -_2.4. Resource Allocation_ -[3*, c5, c10, c11] - -Equipment, facilities, and people should be allo- -cated to the identified tasks, including the allo- -cation of responsibilities for completion of vari- -ous elements of a project and the overall project. -A matrix that shows who is responsible for, -accountable for, consulted about, and informed -about each of the tasks can be used. Resource -allocation is based on, and constrained by, the -availability of resources and their optimal use, as - -``` -well as by issues relating to personnel (for exam- -ple, productivity of individuals and teams, team -dynamics, and team structures). -``` -``` -2.5. Risk Management -[3*, c9] [5*, c5] -``` -``` -Risk and uncertainty are related but distinct con- -cepts. Uncertainty results from lack of informa- -tion. Risk is characterized by the probability of an -event that will result in a negative impact plus a -characterization of the negative impact on a proj- -ect. Risk is often the result of uncertainty. The -converse of risk is opportunity, which is charac- -terized by the probability that an event having a -positive outcome might occur. -Risk management entails identification of risk -factors and analysis of the probability and poten- -tial impact of each risk factor, prioritization of -risk factors, and development of risk mitigation -strategies to reduce the probability and minimize -the negative impact if a risk factor becomes a -problem. Risk assessment methods (for example, -expert judgment, historical data, decision trees, -and process simulations) can sometimes be used -in order to identify and evaluate risk factors. -Project abandonment conditions can also be -determined at this point in discussion with all -relevant stakeholders. Software-unique aspects -of risk, such as software engineers’ tendency to -add unneeded features, or the risks related to soft- -ware’s intangible nature, can influence risk man- -agement of a software project. Particular atten- -tion should be paid to the management of risks -related to software quality requirements such as -safety or security (see the Software Quality KA). -Risk management should be done not only at the -beginning of a project, but also at periodic inter- -vals throughout the project life cycle. -``` -``` -2.6. Quality Management -[3*, c4] [4*, c24] -``` -``` -Software quality requirements should be identi- -fied, perhaps in both quantitative and qualitative -terms, for a software project and the associated -work products. Thresholds for acceptable qual- -ity measurements should be set for each software -quality requirement based on stakeholder needs -``` - -``` -Software Engineering Management 7-7 -``` -and expectations. Procedures concerned with -ongoing Software Quality Assurance (SQA) and -quality improvement throughout the development -process, and for verification and validation of -the deliverable software product, should also be -specified during quality planning (for example, -technical reviews and inspections or demonstra- -tions of completed functionality; see the Software -Quality KA). - -_2.7. Plan Management_ -[3*, c4] - -For software projects, where change is an expec- -tation, plans should be managed. Managing the -project plan should thus be planned. Plans and -processes selected for software development -should be systematically monitored, reviewed, -reported, and, when appropriate, revised. Plans -associated with supporting processes (for exam- -ple, documentation, software configuration man- -agement, and problem resolution) also should be -managed. Reporting, monitoring, and controlling -a project should fit within the selected SDLC and -the realities of the project; plans should account -for the various artifacts that will be used to man- -age the project. - -**3. Software Project Enactment** - -During software project enactment (also known -as project execution) plans are implemented and -the processes embodied in the plans are enacted. -Throughout, there should be a focus on adher- -ence to the selected SDLC processes, with an -overriding expectation that adherence will lead to -the successful satisfaction of stakeholder require- -ments and achievement of the project’s objec- -tives. Fundamental to enactment are the ongoing -management activities of monitoring, control- -ling, and reporting. - -_3.1. Implementation of Plans_ -[4*, c2] - -Project activities should be undertaken in accor- -dance with the project plan and supporting plans. -Resources (for example, personnel, technology, -and funding) are utilized and work products (for - -``` -example, software design, software code, and -software test cases) are generated. -``` -``` -3.2. Software Acquisition and Supplier Contract -Management -[3*, c3, c4] -``` -``` -Software acquisition and supplier contract man- -agement is concerned with issues involved in -contracting with customers of the software devel- -opment organization who acquire the deliverable -work products and with suppliers who supply -products or services to the software engineering -organization. -This may involve selection of appropriate kinds -of contracts, such as fixed price, time and materi- -als, cost plus fixed fee, or cost plus incentive fee. -Agreements with customers and suppliers typi- -cally specify the scope of work and the deliver- -ables and include clauses such as penalties for late -delivery or nondelivery and intellectual property -agreements that specify what the supplier or sup- -pliers are providing and what the acquirer is pay- -ing for, plus what will be delivered to and owned -by the acquirer. For software being developed by -suppliers (both internal to or external to the soft- -ware development organization), agreements com- -monly indicate software quality requirements for -acceptance of the delivered software. -After the agreement has been put in place, exe- -cution of the project in compliance with the terms -of the agreement should be managed (see chapter -12 of SWX, Software Procurement Management, -for more information on this topic [2]). -``` -``` -3.3. Implementation of Measurement Process -[3*, c7] -``` -``` -The measurement process should be enacted dur- -ing the software project to ensure that relevant -and useful data are collected (see sections 6.2, -Plan the Measurement Process, and 6.3, Perform -the Measurement Process). -``` -``` -3.4. Monitor Process -[3*, c8] -``` -``` -Adherence to the project plan and related -plans should be assessed continually and at -``` - -**7-8** **_SWEBOK® Guide_** **V3.0** - -predetermined intervals. Also, outputs and com- -pletion criteria for each task should be assessed. -Deliverables should be evaluated in terms of their -required characteristics (for example, via inspec- -tions or by demonstrating working functionality). -Effort expenditure, schedule adherence, and costs -to date should be analyzed, and resource usage -examined. The project risk profile (see section -2.5, Risk Management) should be revisited, and -adherence to software quality requirements eval- -uated (see Software Quality Requirements in the -Software Quality KA). -Measurement data should be analyzed (see Sta- -tistical Analysis in the Engineering Foundations -KA). Variance analysis based on the deviation of -actual from expected outcomes and values should -be determined. This may include cost overruns, -schedule slippage, or other similar measures. -Outlier identification and analysis of quality and -other measurement data should be performed (for -example, defect analysis; see Software Quality -Measurement in the Software Quality KA). Risk -exposures should be recalculated (see section 2.5, -Risk Management). These activities can enable -problem detection and exception identification -based on thresholds that have been exceeded. -Outcomes should be reported when thresholds -have been exceeded, or as necessary. - -_3.5. Control Process_ -[3*, c7, c8] - -The outcomes of project monitoring activities -provide the basis on which decisions can be made. -Where appropriate, and when the probability and -impact of risk factors are understood, changes can -be made to the project. This may take the form of -corrective action (for example, retesting certain -software components); it may involve incorpo- -rating additional actions (for example, deciding -to use prototyping to assist in software require- -ments validation; see Prototyping in the Software -Requirements KA); and/or it may entail revision -of the project plan and other project documents -(for example, the software requirements specifi- -cation) to accommodate unanticipated events and -their implications. -In some instances, the control process may -lead to abandonment of the project. In all cases, - -``` -software configuration control and software con- -figuration management procedures should be -adhered to (see the Software Configuration Man- -agement KA), decisions should be documented -and communicated to all relevant parties, plans -should be revisited and revised when necessary, -and relevant data recorded (see section 6.3, Per- -form the Measurement Process). -``` -``` -3.6. Reporting -[3*, c11] -``` -``` -At specified and agreed-upon times, progress to -date should be reported—both within the orga- -nization (for example, to a project steering com- -mittee) and to external stakeholders (for exam- -ple, clients or users). Reports should focus on -the information needs of the target audience as -opposed to the detailed status reporting within the -project team. -``` -**4. Review and Evaluation** - -``` -At prespecified times and as needed, overall prog- -ress towards achievement of the stated objectives -and satisfaction of stakeholder (user and customer) -requirements should be evaluated. Similarly, -assessments of the effectiveness of the software -process, the personnel involved, and the tools and -methods employed should also be undertaken reg- -ularly and as determined by circumstances. -``` -``` -4.1. Determining Satisfaction of Requirements -[4*, c8] -``` -``` -Because achieving stakeholder satisfaction is -a principal goal of the software engineering -manager, progress towards this goal should -be assessed periodically. Progress should be -assessed on achievement of major project mile- -stones (for example, completion of software -design architecture or completion of a soft- -ware technical review), or upon completion of -an iterative development cycle that results in -a product increment. Variances from software -requirements should be identified and appropri- -ate actions should be taken. -As in the control process activity above (see sec- -tion 3.5, Control Process), software configuration -``` - -``` -Software Engineering Management 7-9 -``` -control and software configuration management -procedures should be followed (see the Software -Configuration Management KA), decisions docu- -mented and communicated to all relevant parties, -plans revisited and revised where necessary, and -relevant data recorded (see section 6.3, Perform -the Measurement Process). - -_4.2. Reviewing and Evaluating Performance_ -[3*, c8, c10] - -Periodic performance reviews for project per- -sonnel can provide insights as to the likelihood -of adherence to plans and processes as well as -possible areas of difficulty (for example, team -member conflicts). The various methods, tools, -and techniques employed should be evaluated for -their effectiveness and appropriateness, and the -process being used by the project should also be -systematically and periodically assessed for rel- -evance, utility, and efficacy in the project context. -Where appropriate, changes should be made and -managed. - -**5. Closure** - -An entire project, a major phase of a project, -or an iterative development cycle reaches clo- -sure when all the plans and processes have been -enacted and completed. The criteria for project, -phase, or iteration success should be evaluated. -Once closure is established, archival, retrospec- -tive, and process improvement activities can be -performed. - -_5.1. Determining Closure_ -[1, s3.7, s4.6] - -Closure occurs when the specified tasks for a -project, a phase, or an iteration have been com- -pleted and satisfactory achievement of the com- -pletion criteria has been confirmed. Software -requirements can be confirmed as satisfied or not, -and the degree of achieving the objectives can -be determined. Closure processes should involve -relevant stakeholders and result in documentation -of relevant stakeholders’ acceptance; any known -problems should be documented. - -``` -5.2. Closure Activities -[2, s3.7, s4.8] -``` -``` -After closure has been confirmed, archiving of -project materials should be accomplished in -accordance with stakeholder agreed-upon meth- -ods, location, and duration—possibly including -destruction of sensitive information, software, -and the medium on which copies are resident. -The organization’s measurement database should -be updated with relevant project data. A project, -phase, or iteration retrospective analysis should -be undertaken so that issues, problems, risks, -and opportunities encountered can be analyzed -(see topic 4, Review and Evaluation). Lessons -learned should be drawn from the project and fed -into organizational learning and improvement -endeavors. -``` -**6. Software Engineering Measurement** - -``` -The importance of measurement and its role in -better management and engineering practices is -widely acknowledged (see Measurement in the -Engineering Foundations KA). Effective mea- -surement has become one of the cornerstones -of organizational maturity. Measurement can be -applied to organizations, projects, processes, and -work products. In this section the focus is on the -application of measurement at the levels of proj- -ects, processes, and work products. -This section follows the IEEE 15939:2008 -standard [6], which describes a process to define -the activities and tasks necessary to implement a -software measurement process. The standard also -includes a measurement information model. -``` -``` -6.1. Establish and Sustain Measurement -Commitment -[7*, c1, c2]^2 -``` -- Requirements for measurement. Each mea- - surement endeavor should be guided by - organizational objectives and driven by a set - of measurement requirements established by - -``` -2 Please note that these two chapters can be -downloaded free of charge from http://www.psmsc.com/ -PSMBook.asp. -``` - -**7-10** **_SWEBOK® Guide_** **V3.0** - -``` -the organization and the project (for exam- -ple, an organizational objective might be -“first-to-market with new products”). -``` -- Scope of measurement_._ The organizational - unit to which each measurement requirement - is to be applied should be established. This - may consist of a functional area, a single - project, a single site, or an entire enterprise. - The temporal scope of the measurement - effort should also be considered because - time series of some measurements may be - required; for example, to calibrate estima- - tion models (see section 2.3, Effort, Sched- - ule, and Cost Estimation). -- Team commitment to measurement. The - commitment should be formally established, - communicated, and supported by resources - (see next item). -- Resources for measurement. An organiza- - tion’s commitment to measurement is an - essential factor for success, as evidenced by - the assignment of resources for implement- - ing the measurement process. Assigning - resources includes allocation of responsibil- - ity for the various tasks of the measurement - process (such as analyst and librarian). Ade- - quate funding, training, tools, and support to - conduct the process should also be allocated. - -_6.2. Plan the Measurement Process_ -[7*, c1, c2] - -- Characterize the organizational unit. The - organizational unit provides the context for - measurement, so the organizational context - should be made explicit, including the con- - straints that the organization imposes on - the measurement process. The characteriza- - tion can be stated in terms of organizational - processes, application domains, technology, - organizational interfaces, and organizational - structure. -- Identify information needs. Information - needs are based on the goals, constraints, - risks, and problems of the organizational - unit. They may be derived from business, - organizational, regulatory, and/or product - objectives. They should be identified and - -``` -prioritized. Then a subset of objectives to be -addressed can be selected, documented, com- -municated, and reviewed by stakeholders. -``` -- Select measures. Candidate measures should - be selected, with clear links to the informa- - tion needs. Measures should be selected - based on the priorities of the information - needs and other criteria such as cost of col- - lection, degree of process disruption during - collection, ease of obtaining accurate, con- - sistent data, and ease of analysis and report- - ing. Because internal quality characteristics - (see Models and Quality Characteristics in - the Software Quality KA) are often not con- - tained in the contractually binding software - requirements, it is important to consider mea- - suring the internal quality of the software to - provide an early indicator of potential issues - that may impact external stakeholders. -- Define data collection, analysis, and report- - ing procedures. This encompasses collection - procedures and schedules, storage, verifica- - tion, analysis, reporting, and configuration - management of data. -- Select criteria for evaluating the information - products. Criteria for evaluation are influ- - enced by the technical and business objec- - tives of the organizational unit. Information - products include those associated with the - product being produced, as well as those - associated with the processes being used to - manage and measure the project. -- Provide resources for measurement tasks. The - measurement plan should be reviewed and - approved by the appropriate stakeholders to - include all data collection procedures; storage, - analysis, and reporting procedures; evaluation - criteria; schedules; and responsibilities. Crite- - ria for reviewing these artifacts should have - been established at the organizational-unit - level or higher and should be used as the basis - for these reviews. Such criteria should take - into consideration previous experience, avail- - ability of resources, and potential disruptions - to projects when changes from current prac- - tices are proposed. Approval demonstrates - commitment to the measurement process. -- Identify resources to be made available for - implementing the planned and approved - - -``` -Software Engineering Management 7-11 -``` -``` -measurement tasks. Resource availability -may be staged in cases where changes are -to be piloted before widespread deployment. -Consideration should be paid to the resources -necessary for successful deployment of new -procedures or measures. -``` -- Acquire and deploy supporting technologies. - This includes evaluation of available supporting - technologies, selection of the most appropriate - technologies, acquisition of those technologies, - and deployment of those technologies. - -_6.3. Perform the Measurement Process_ -[7*, c1, c2] - -- Integrate measurement procedures with rel- - evant software processes. The measurement - procedures, such as data collection, should - be integrated into the software processes - they are measuring. This may involve chang- - ing current software processes to accommo- - date data collection or generation activities. - It may also involve analysis of current soft- - ware processes to minimize additional effort - and evaluation of the effect on employees to - ensure that the measurement procedures will - be accepted. Morale issues and other human - factors should be considered. In addition, the - measurement procedures should be commu- - nicated to those providing the data. Training - and support may also need to be provided. - Data analysis and reporting procedures are - typically integrated into organizational and/ - or project processes in a similar manner. -- Collect data. Data should be collected, veri- - fied, and stored. Collection can sometimes - be automated by using software engineer- - ing management tools (see topic 7, Soft- - ware Engineering Management Tools) to - analyze data and develop reports. Data may - be aggregated, transformed, or recoded as - part of the analysis process, using a degree - of rigor appropriate to the nature of the data - and the information needs. The results of - this analysis are typically indicators such as - graphs, numbers, or other indications that - will be interpreted, resulting in conclusions - and recommendations to be presented to - stakeholders (see Statistical Analysis in the - -``` -Engineering Foundations KA). The results -and conclusions are usually reviewed, using -a process defined by the organization (which -may be formal or informal). Data providers -and measurement users should participate -in reviewing the data to ensure that they are -meaningful and accurate and that they can -result in reasonable actions. -``` -- Communicate results. Information products - should be documented and communicated to - users and stakeholders. - -``` -6.4. Evaluate Measurement -[7*, c1, c2] -``` -- Evaluate information products and the mea- - surement process against specified evalu- - ation criteria and determine strengths and - weaknesses of the information products or - process, respectively. Evaluation may be - performed by an internal process or an exter- - nal audit; it should include feedback from - measurement users. Lessons learned should - be recorded in an appropriate database. -- Identify potential improvements. Such - improvements may be changes in the format - of indicators, changes in units measured, or - reclassification of measurement categories. - The costs and benefits of potential improve- - ments should be determined and appropriate - improvement actions should be reported. -- Communicate proposed improvements to the - measurement process owner and stakehold- - ers for review and approval. Also, lack of - potential improvements should be commu- - nicated if the analysis fails to identify any - improvements. -**7. Software Engineering Management Tools** -[3*, c5, c6, c7] - -``` -Software engineering management tools are often -used to provide visibility and control of software -engineering management processes. Some tools -are automated while others are manually imple- -mented. There has been a recent trend towards -the use of integrated suites of software engineer- -ing tools that are used throughout a project to -plan, collect and record, monitor and control, and -``` - -**7-12** **_SWEBOK® Guide_** **V3.0** - -report project and product information. Tools can -be divided into the following categories: -_Project Planning and Tracking Tools._ Project -planning and tracking tools can be used to esti- -mate project effort and cost and to prepare project -schedules. Some projects use automated estima- -tion tools that accept as input the estimated size -and other characteristics of a software product -and produce estimates of the required total effort, -schedule, and cost. Planning tools also include -automated scheduling tools that analyze the tasks -within a work breakdown structure, their esti- -mated durations, their precedence relationships, -and the resources assigned to each task to pro- -duce a schedule in the form of a Gantt chart. -Tracking tools can be used to track project -milestones, regularly scheduled project status -meetings, scheduled iteration cycles, product -demonstrations, and/or action items. -_Risk Management Tools._ Risk management -tools (see section 2.5, Risk Management _)_ can -be used to track risk identification, estimation, -and monitoring. These tools include the use of -approaches such as simulation or decision trees -to analyze the effect of costs versus payoffs - -``` -and subjective estimates of the probabilities of -risk events. Monte Carlo simulation tools can -be used to produce probability distributions of -effort, schedule, and risk by combining multiple -input probability distributions in an algorithmic -manner. -Communications Tools. Communication tools -can assist in providing timely and consistent -information to relevant stakeholders involved in a -project. These tools can include things like email -notifications and broadcasts to team members -and stakeholders. They also include communica- -tion of minutes from regularly scheduled project -meetings, daily stand-up meetings, plus charts -showing progress, backlogs, and maintenance -request resolutions. -Measurement Tools. Measurement tools sup- -port activities related to the software measure- -ment program (see topic 6, Software Engineer- -ing Measurement). There are few completely -automated tools in this category. Measurement -tools used to gather, analyze, and report project -measurement data may be based on spreadsheets -developed by project team members or organiza- -tional employees. -``` - -``` -Software Engineering Management 7-13 -``` -##### MATRIX OF TOPICS VS. REFERENCE MATERIAL - -``` -Fairley 2009 -``` -##### [3*] - -``` -Sommerville 2011 -``` -##### [4*] - -``` -Boehm and Turner 2003 -``` -##### [5*] - -``` -McGarry et al. 2001 -``` -##### [7*] - -**1. Initiation and Scope -Definition** - 1.1. Determination and - Negotiation of Requirements - c3 - -``` -1.2. Feasibility Analysis c4 -1.3. Process for the Review and -Revision of Requirements -c3 -``` -**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 - Estimation - c6 - -``` -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 - Supplier Contract Management - c3, c4 - -``` -3.3. Implementation of -Measurement Process -c7 -``` -``` -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 - Performance - c8, c10 - - -**7-14** **_SWEBOK® Guide_** **V3.0** - -``` -Fairley 2009 -``` -##### [3*] - -``` -Sommerville 2011 -``` -##### [4*] - -``` -Boehm and Turner 2003 -``` -##### [5*] - -``` -McGarry et al. 2001 -``` -##### [7*] - -**5. Closure** - 5.1. Determining Closure - 5.2. Closure Activities -**6. Software Engineering -Measurement** - 6.1. Establish and Sustain - Measurement Commitment - c1, c2 - -``` -6.2. Plan the Measurement -Process -c1, c2 -``` -``` -6.3. Perform the Measurement -Process -c1, c2 -``` -``` -6.4. Evaluate Measurement c1, c2 -``` -**7. Software Engineering -Management Tools** - c5, c6, c7 - - -``` -Software Engineering Management 7-15 -``` -##### FURTHER READINGS - -_A Guide to the Project Management Body of -Knowledge (PMBOK_ ® _Guide)_ [1]. - -The _PMBOK_ ® _Guide_ provides guidelines for -managing individual projects and defines project -management-related concepts. It also describes -the project management life cycle and its related -processes, as well as the project life cycle. It is -a globally recognized guide for the project man- -agement profession. - -_Software Extension to the Guide to the -Project Management Body of Knowledge -(PMBOK® Guide)_ [2]. - -SWX provides adaptations and extensions to -the generic practices of project management -documented in the _PMBOK® Guide_ for manag- -ing software projects. The primary contribution -of this extension to the _PMBOK® Guide_ is a -description of processes that are applicable for -managing adaptive life cycle software projects. - -_IEEE Standard Adoption of ISO/IEC 15939_ [6]. - -This international standard identifies a process -that supports defining a suitable set of measures -to address specific information needs. It identi- -fies the activities and tasks that are necessary to -successfully identify, define, select, apply, and -improve measurement within an overall project -or organizational measurement structure. - -J. McDonald, _Managing the Development of -Software Intensive Systems_ , Wiley, 2010 [8]. - -This textbook provides an introduction to project -management for beginning software and hard- -ware developers plus unique advanced material -for experienced project managers. Case studies -are included for planning and managing verifica- -tion and validation for large software projects, -complex software, and hardware systems, as well -as inspection results and testing metrics to moni- -tor project status. - -##### REFERENCES - -``` -[1] Project Management Institute, A Guide to the -Project Management Body of Knowledge -(PMBOK(R) Guide) , 5th ed., Project -Management Institute, 2013. -``` -``` -[2] Project Management Institute and IEEE -Computer Society, Software Extension to -the PMBOK® Guide Fifth Edition , Project -Management Institute, 2013. -``` -``` -[3*] R.E. Fairley, Managing and Leading -Software Projects , Wiley-IEEE Computer -Society Press, 2009. -``` -``` -[4*] I. Sommerville, Software Engineering , 9th -ed., Addison-Wesley, 2011. -``` -``` -[5*] B. Boehm and R. Turner, Balancing Agility -and Discipline: A Guide for the Perplexed , -Addison-Wesley, 2003. -``` -``` -[6] IEEE Std. 15939-2008 Standard Adoption of -ISO/IEC 15939:2007 Systems and Software -Engineering—Measurement Process , -IEEE, 2008. -``` -``` -[7*] J. McGarry et al., Practical Software -Measurement: Objective Information -for Decision Makers , Addison-Wesley -Professional, 2001. -``` -``` -[8] J. McDonald, Managing the Development of -Software Intensive Systems , John Wiley and -Sons, Inc., 2010. -``` blob - ffd989f26e5738d548a747b22423564ffd467082 (mode 644) blob + /dev/null --- 8_software_engineering_process.markdown +++ /dev/null @@ -1,1375 +0,0 @@ -``` -8-1 -``` -**CHAPTER 8** - -**SOFTWARE ENGINEERING PROCESS** - -##### ACRONYMS - -##### BPMN - -``` -Business Process Modeling -Notation -``` -``` -CASE -Computer-Assisted Software -Engineering -CM Configuration Management -``` -``` -CMMI -Capability Maturity Model -Integration -GQM Goal-Question-Metric -IDEF0 Integration Definition -LOE Level of Effort -ODC Orthogonal Defect Classification -SDLC Software Development Life Cycle -SPLC Software Product Life Cycle -UML Unified Modeling Language -``` -##### INTRODUCTION - -An engineering process consists of a set of inter- -related activities that transform one or more inputs -into outputs while consuming resources to accom- -plish the transformation. Many of the processes of -traditional engineering disciplines (e.g., electrical, -mechanical, civil, chemical) are concerned with -transforming energy and physical entities from -one form into another, as in a hydroelectric dam -that transforms potential energy into electrical -energy or a petroleum refinery that uses chemical -processes to transform crude oil into gasoline. -In this knowledge area (KA), software engineer- -ing processes are concerned with work activities -accomplished by software engineers to develop, -maintain, and operate software, such as require- -ments, design, construction, testing, configura- -tion management, and other software engineering -processes. For readability, “software engineering - -``` -process” will be referred to as “software process” -in this KA. In addition, please note that “software -process” denotes work activities—not the execu- -tion process for implemented software. -Software processes are specified for a number -of reasons: to facilitate human understanding, -communication, and coordination; to aid man- -agement of software projects; to measure and -improve the quality of software products in an -efficient manner; to support process improve- -ment; and to provide a basis for automated sup- -port of process execution. -SWEBOK KAs closely related to this Soft- -ware Engineering Process KA include Software -Engineering Management, Software Engineer- -ing Models and Methods, and Software Quality; -the Measurement and Root Cause Analysis topic -found in the Engineering Foundations KA is also -closely related. Software Engineering Manage- -ment is concerned with tailoring, adapting, and -implementing software processes for a specific -software project (see Process Planning in the -Software Engineering Management KA). Mod- -els and methods support a systematic approach to -software development and modification. -The Software Quality KA is concerned with -the planning, assurance, and control processes -for project and product quality. Measurement and -measurement results in the Engineering Founda- -tions KA are essential for evaluating and control- -ling software processes. -``` -``` -BREAKDOWN OF TOPICS FOR -SOFTWARE ENGINEERING PROCESS -``` -``` -As illustrated in Figure 8.1, this KA is concerned -with software process definition, software life -cycles, software process assessment and improve- -ment, software measurement, and software engi- -neering process tools. -``` - -**8-2** **_SWEBOK® Guide_** **V3.0** - -**1. Software Process Definition** - [1*, p177] [2*, p295] [3*, p28–29, p36, c5] - -This topic is concerned with a definition of soft- -ware process, software process management, and -software process infrastructure. -As stated above, a software process is a set of -interrelated activities and tasks that transform -input work products into output work products. -At minimum, the description of a software pro- -cess includes required inputs, transforming work -activities, and outputs generated. As illustrated in -Figure 8.2, a software process may also include -its entry and exit criteria and decomposition -of the work activities into tasks, which are the -smallest units of work subject to management -accountability. A process input may be a trigger- -ing event or the output of another process. Entry -criteria should be satisfied before a process can -commence. All specified conditions should be -satisfied before a process can be successfully - -``` -concluded, including the acceptance criteria for -the output work product or work products. -A software process may include subprocesses. -For example, software requirements validation is -a process used to determine whether the require- -ments will provide an adequate basis for software -development; it is a subprocess of the software -requirements process. Inputs for requirements val- -idation are typically a software requirements spec- -ification and the resources needed to perform vali- -dation (personnel, validation tools, sufficient time). -The tasks of the requirements validation activity -might include requirements reviews, prototyping, -and model validation. These tasks involve work -assignments for individuals and teams. The output -of requirements validation is typically a validated -software requirements specification that provides -inputs to the software design and software test- -ing processes. Requirements validation and other -subprocesses of the software requirements process -are often interleaved and iterated in various ways; -``` -``` -Figure 8.1. Breakdown of Topics for the Software Engineering Process KA -``` - -``` -Software Engineering Process 8-3 -``` -the software requirements process and its subpro- -cesses may be entered and exited multiple times -during software development or modification. -Complete definition of a software process may -also include the roles and competencies, IT sup- -port, software engineering techniques and tools, -and work environment needed to perform the -process, as well as the approaches and measures -(Key Performance Indicators) used to determine -the efficiency and effectiveness of performing the -process. -In addition, a software process may include -interleaved technical, collaborative, and adminis- -trative activities. -Notations for defining software processes -include textual lists of constituent activities and -tasks described in natural language; data-flow -diagrams; state charts; BPMN; IDEF0; Petri nets; -and UML activity diagrams. The transforming -tasks within a process may be defined as proce- -dures; a procedure may be specified as an ordered -set of steps or, alternatively, as a checklist of the -work to be accomplished in performing a task. -It must be emphasized that there is no best soft- -ware process or set of software processes. Soft- -ware processes must be selected, adapted, and -applied as appropriate for each project and each -organizational context. No ideal process, or set of -processes, exists. - -_1.1. Software Process Management_ -[3*, s26.1] [4*, p453–454] - -Two objectives of software process management -are to realize the efficiency and effectiveness that - -``` -result from a systematic approach to accomplish- -ing software processes and producing work prod- -ucts—be it at the individual, project, or organiza- -tional level—and to introduce new or improved -processes. -Processes are changed with the expectation that -a new or modified process will improve the effi- -ciency and/or effectiveness of the process and the -quality of the resulting work products. Changing -to a new process, improving an existing process, -organizational change, and infrastructure change -(technology insertion or changes in tools) are -closely related, as all are usually initiated with the -goal of improving the cost, development sched- -ule, or quality of the software products. Process -change has impacts not only for the software -product; they often lead to organizational change. -Changing a process or introducing a new process -can have ripple effects throughout an organiza- -tion. For example, changes in IT infrastruc- -ture tools and technology often require process -changes. -Existing processes may be modified when -other new processes are deployed for the first -time (for example, introducing an inspection -activity within a software development project -will likely impact the software testing process— -see Reviews and Audits in the Software Quality -KA and in the Software Testing KA). These situ- -ations can also be termed “process evolution.” -If the modifications are extensive, then changes -in the organizational culture and business model -will likely be necessary to accommodate the pro- -cess changes. -``` -``` -Figure 8.2. Elements of a Software Process -``` - -**8-4** **_SWEBOK® Guide_** **V3.0** - -_1.2. Software Process Infrastructure_ -[2*, p183, p186] [4*, p437–438] - -Establishing, implementing, and managing soft- -ware processes and software life cycle models -often occurs at the level of individual software -projects. However, systematic application of -software processes and software life cycle mod- -els across an organization can provide benefits -to all software work within the organization, -although it requires commitment at the organi- -zational level. A software process infrastructure -can provide process definitions, policies for inter- -preting and applying the processes, and descrip- -tions of the procedures to be used to implement -the processes. Additionally, a software process -infrastructure may provide funding, tools, train- -ing, and staff members who have been assigned -responsibilities for establishing and maintaining -the software process infrastructure. -Software process infrastructure varies, depend- -ing on the size and complexity of the organization -and the projects undertaken within the organiza- -tion. Small, simple organizations and projects -have small, simple infrastructure needs. Large, -complex organizations and projects, by neces- -sity, have larger and more complex software -process infrastructures. In the latter case, various -organizational units may be established (such as -a software engineering process group or a steer- -ing committee) to oversee implementation and -improvement of the software processes. -A common misperception is that establishing a -software process infrastructure and implementing -repeatable software processes will add time and -cost to software development and maintenance. -There is a cost associated with introducing or -improving a software process; however, experi- -ence has shown that implementing systematic -improvement of software processes tends to result -in lower cost through improved efficiency, avoid- -ance of rework, and more reliable and affordable -software. Process performance thus influences -software product quality. - -**2. Software Life Cycles** - [1*, c2] [2*, p190] - -This topic addresses categories of software pro- -cesses, software life cycle models, software - -``` -process adaptation, and practical considerations. -A software development life cycle (SDLC) -includes the software processes used to specify -and transform software requirements into a deliv- -erable software product. A software product life -cycle (SPLC) includes a software development -life cycle plus additional software processes that -provide for deployment, maintenance, support, -evolution, retirement, and all other inception- -to-retirement processes for a software product, -including the software configuration management -and software quality assurance processes that are -applied throughout a software product life cycle. -A software product life cycle may include multi- -ple software development life cycles for evolving -and enhancing the software. -Individual software processes have no tempo- -ral ordering among them. The temporal relation- -ships among software processes are provided by -a software life cycle model: either an SDLC or -SPLC. Life cycle models typically emphasize -the key software processes within the model -and their temporal and logical interdependen- -cies and relationships. Detailed definitions of -the software processes in a life cycle model may -be provided directly or by reference to other -documents. -In addition to conveying the temporal and -logical relationships among software processes, -the software development life cycle model (or -models used within an organization) includes the -control mechanisms for applying entry and exit -criteria (e.g., project reviews, customer approv- -als, software testing, quality thresholds, dem- -onstrations, team consensus). The output of one -software process often provides the input for oth- -ers (e.g., software requirements provide input for -a software architectural design process and the -software construction and software testing pro- -cesses). Concurrent execution of several software -process activities may produce a shared output -(e.g., the interface specifications for interfaces -among multiple software components developed -by different teams). Some software processes -may be regarded as less effective unless other -software processes are being performed at the -same time (e.g., software test planning during -software requirements analysis can improve the -software requirements). -``` - -``` -Software Engineering Process 8-5 -``` -_2.1. Categories of Software Processes_ -[1*, Preface] [2* , p294–295] [3*, c22–c24] - -Many distinct software processes have been -defined for use in the various parts of the soft- -ware development and software maintenance life -cycles. These processes can be categorized as -follows: - -1. _Primary processes_ include software pro- - cesses for development, operation, and - maintenance of software. -2. _Supporting processes_ are applied intermit- - tently or continuously throughout a software - product life cycle to support primary pro- - cesses; they include software processes such - as configuration management, quality assur- - ance, and verification and validation. -3. _Organizational processes_ provide sup- - port for software engineering; they include - training, process measurement analysis, - infrastructure management, portfolio and - reuse management, organizational process - improvement, and management of software - life cycle models. -4. _Cross-project processes,_ such as reuse, soft- - ware product line, and domain engineering; - they involve more than a single software - project in an organization. - -Software processes in addition to those listed -above include the following. -Project management processes include pro- -cesses for planning and estimating, resource -management, measuring and controlling, leading, -managing risk, managing stakeholders, and coor- -dinating the primary, supporting, organizational, -and cross-project processes of software develop- -ment and maintenance projects. -Software processes are also developed for -particular needs, such as process activities that -address software quality characteristics (see -the Software Quality KA). For example, secu- -rity concerns during software development may -necessitate one or more software processes to -protect the security of the development environ- -ment and reduce the risk of malicious acts. Soft- -ware processes may also be developed to provide -adequate grounds for establishing confidence in -the integrity of the software. - -``` -2.2. Software Life Cycle Models -[1*, c2] [2*, s3.2] [3*, s2.1] [5] -``` -``` -The intangible and malleable nature of software -permits a wide variety of software development -life cycle models, ranging from linear models in -which the phases of software development are -accomplished sequentially with feedback and -iteration as needed followed by integration, test- -ing, and delivery of a single product; to iterative -models in which software is developed in incre- -ments of increasing functionality on iterative -cycles; to agile models that typically involve -frequent demonstrations of working software to -a customer or user representative who directs -development of the software in short iterative -cycles that produce small increments of working, -deliverable software. Incremental, iterative, and -agile models can deliver early subsets of working -software into the user environment, if desired. -Linear SDLC models are sometimes referred -to as predictive software development life cycle -models, while iterative and agile SDLCs are -referred to as adaptive software development -life cycle models. It should be noted that vari- -ous maintenance activities during an SPLC can -be conducted using different SDLC models, as -appropriate to the maintenance activities. -A distinguishing feature of the various soft- -ware development life cycle models is the way in -which software requirements are managed. Lin- -ear development models typically develop a com- -plete set of software requirements, to the extent -possible, during project initiation and planning. -The software requirements are then rigorously -controlled. Changes to the software requirements -are based on change requests that are processed -by a change control board (see Requesting, -Evaluating and Approving Software Changes in -the Change Control Board in the Software Con- -figuration Management KA). An incremental -model produces successive increments of work- -ing, deliverable software based on partitioning -of the software requirements to be implemented -in each of the increments. The software require- -ments may be rigorously controlled, as in a linear -model, or there may be some flexibility in revising -the software requirements as the software product -evolves. Agile models may define product scope -and high-level features initially; however, agile -``` - -**8-6** **_SWEBOK® Guide_** **V3.0** - -models are designed to facilitate evolution of the -software requirements during the project. -It must be emphasized that the continuum of -SDLCs from linear to agile is not a thin, straight -line. Elements of different approaches may be -incorporated into a specific model; for exam- -ple, an incremental software development life -cycle model may incorporate sequential soft- -ware requirements and design phases but permit -considerable flexibility in revising the software -requirements and architecture during software -construction. - -_2.3. Software Process Adaptation_ -[1*, s2.7] [2*, p51] - -Predefined SDLCs, SPLCs, and individual soft- -ware processes often need to be adapted (or -“tailored”) to better serve local needs. Organiza- -tional context, innovations in technology, project -size, product criticality, regulatory requirements, -industry practices, and corporate culture may -determine needed adaptations. Adaptation of -individual software processes and software life -cycle models (development and product) may -consist of adding more details to software pro- -cesses, activities, tasks, and procedures to address -critical concerns. It may consist of using an alter- -nate set of activities that achieves the purpose and -outcomes of the software process. Adaptation -may also include omitting software processes -or activities from a development or product life -cycle model that are clearly inapplicable to the -scope of work to be accomplished. - -_2.4. Practical Considerations_ -[2*, p188–190] - -In practice, software processes and activities are -often interleaved, overlapped, and applied concur- -rently. Software life cycle models that specify dis- -crete software processes, with rigorously specified -entry and exit criteria and prescribed boundaries -and interfaces, should be recognized as idealiza- -tions that must be adapted to reflect the realities of -software development and maintenance within the -organizational context and business environment. -Another practical consideration: software -processes (such as configuration management, - -``` -construction, and testing) can be adapted to facili- -tate operation, support, maintenance, migration, -and retirement of the software. -Additional factors to be considered when -defining and tailoring a software life cycle model -include required conformance to standards, direc- -tives, and policies; customer demands; criticality -of the software product; and organizational matu- -rity and competencies. Other factors include the -nature of the work (e.g., modification of exist- -ing software versus new development) and the -application domain (e.g., aerospace versus hotel -management). -``` -**3. Software Process Assessment and -Improvement** - [2*, p188, p194] [3*, c26] [4*, p397, c15] - -``` -This topic addresses software process assess- -ment models, software process assessment meth- -ods, software process improvement models, and -continuous and staged process ratings. Software -process assessments are used to evaluate the form -and content of a software process, which may -be specified by a standardized set of criteria. In -some instances, the terms “process appraisal” -and “capability evaluation” are used instead of -process assessment. Capability evaluations are -typically performed by an acquirer (or potential -acquirer) or by an external agent on behalf of -an acquirer (or potential acquirer). The results -are used as an indicator of whether the software -processes used by a supplier (or potential sup- -plier) are acceptable to the acquirer. Performance -appraisals are typically performed within an orga- -nization to identify software processes in need of -improvement or to determine whether a process -(or processes) satisfies the criteria at a given level -of process capability or maturity. -Process assessments are performed at the lev- -els of entire organizations, organizational units -within organizations, and individual projects. -Assessment may involve issues such as assess- -ing whether software process entry and exit cri- -teria are being met, to review risk factors and -risk management, or to identify lessons learned. -Process assessment is carried out using both an -assessment model and an assessment method. The -model can provide a norm for a benchmarking -``` - -``` -Software Engineering Process 8-7 -``` -comparison among projects within an organiza- -tion and among organizations. -A process audit differs from a process assess- -ment. Assessments are performed to determine -levels of capability or maturity and to identify -software processes to be improved. Audits are -typically conducted to ascertain compliance with -policies and standards. Audits provide manage- -ment visibility into the actual operations being -performed in the organization so that accurate -and meaningful decisions can be made concern- -ing issues that are impacting a development proj- -ect, a maintenance activity, or a software-related -topic. -Success factors for software process assess- -ment and improvement within software engineer- -ing organizations include management sponsor- -ship, planning, training, experienced and capable -leaders, team commitment, expectation manage- -ment, the use of change agents, plus pilot projects -and experimentation with tools. Additional fac- -tors include independence of the assessor and the -timeliness of the assessment. - -_3.1. Software Process Assessment Models_ -[2*, s4.5, s4.6] [3*, s26.5] [4*, p44–48] - -Software process assessment models typically -include assessment criteria for software processes -that are regarded as constituting good practices. -These practices may address software develop- -ment processes only, or they may also include -topics such as software maintenance, software -project management, systems engineering, or -human resources management. - -_3.2. Software Process Assessment Methods_ -[1*, p322–331] [3*, s26.3] -[4*, p44–48, s16.4] [6] - -A software process assessment method can be -qualitative or quantitative. Qualitative assess- -ments rely on the judgment of experts; quanti- -tative assessments assign numerical scores to -software processes based on analysis of objective -evidence that indicates attainment of the goals -and outcomes of a defined software process. For -example, a quantitative assessment of the soft- -ware inspection process might be performed by - -``` -examining the procedural steps followed and -results obtained plus data concerning defects -found and time required to find and fix the defects -as compared to software testing. -A typical method of software process assess- -ment includes planning, fact-finding (by collect- -ing evidence through questionnaires, interviews, -and observation of work practices), collection -and validation of process data, and analysis and -reporting. Process assessments may rely on the -subjective, qualitative judgment of the assessor, -or on the objective presence or absence of defined -artifacts, records, and other evidence. -The activities performed during a software pro- -cess assessment and the distribution of effort for -assessment activities are different depending on -the purpose of the software process assessment. -Software process assessments may be undertaken -to develop capability ratings used to make recom- -mendations for process improvements or may be -undertaken to obtain a process maturity rating in -order to qualify for a contract or award. -The quality of assessment results depends on -the software process assessment method, the -integrity and quality of the obtained data, the -assessment team’s capability and objectivity, and -the evidence examined during the assessment. -The goal of a software process assessment is to -gain insight that will establish the current status -of a process or processes and provide a basis for -process improvement; performing a software -process assessment by following a checklist for -conformance without gaining insight adds little -value. -``` -``` -3.3. Software Process Improvement Models -[2*, p187–188] [3*, s26.5] [4*, s2.7] -``` -``` -Software process improvement models empha- -size iterative cycles of continuous improvement. -A software process improvement cycle typically -involves the subprocesses of measuring, ana- -lyzing, and changing. The Plan-Do-Check-Act -model is a well-known iterative approach to -software process improvement. Improvement -activities include identifying and prioritizing -desired improvements (planning); introducing -an improvement, including change management -and training (doing); evaluating the improvement -``` - -**8-8** **_SWEBOK® Guide_** **V3.0** - -as compared to previous or exemplary process -results and costs (checking); and making further -modifications (acting). The Plan-Do-Check-Act -process improvement model can be applied, for -example, to improve software processes that -enhance defect prevention. - -_3.4. Continuous and Staged Software Process -Ratings_ -[1*, p28–34] [3*, s26.5] [4*, p39–45] - -Software process capability and software process -maturity are typically rated using five or six levels -to characterize the capability or maturity of the -software processes used within an organization. -A _continuous_ rating system involves assign- -ing a rating to each software process of interest; -a _staged_ rating system is established by assign- -ing the same maturity rating to all of the software -processes within a specified process level. A rep- -resentation of continuous and staged process lev- -els is provided in Table 8.1. Continuous models -typically use a level 0 rating; staged models typi- -cally do not. - -``` -Table 8.1. Software Process Rating Levels -``` -``` -Level -``` -``` -Continuous -Representation -of Capability -Levels -``` -``` -Staged -Representation -of Maturity -Levels -0 Incomplete -1 Performed Initial -2 Managed Managed -3 Defined Defined -``` -``` -4 -Quantitatively -Managed -5 Optimizing -``` -In Table 8.1, level 0 indicates that a software -process is incompletely performed or may not be -performed. At level 1, a software process is being -performed (capability rating), or the software -processes in a maturity level 1 group are being -performed but on an ad hoc, informal basis. At -level 2, a software process (capability rating) or -the processes in maturity level 2 are being per- -formed in a manner that provides management - -``` -visibility into intermediate work products and -can exert some control over transitions between -processes. At level 3, a single software process or -the processes in a maturity level 3 group plus the -process or processes in maturity level 2 are well -defined (perhaps in organizational policies and -procedures) and are being repeated across dif- -ferent projects. Level 3 of process capability or -maturity provides the basis for process improve- -ment across an organization because the process -is (or processes are) conducted in a similar man- -ner. This allows collection of performance data -in a uniform manner across multiple projects. At -maturity level 4, quantitative measures can be -applied and used for process assessment; statis- -tical analysis may be used. At maturity level 5, -the mechanisms for continuous process improve- -ments are applied. -Continuous and staged representations can be -used to determine the order in which software -processes are to be improved. In the continuous -representation, the different capability levels for -different software processes provide a guideline -for determining the order in which software pro- -cesses will be improved. In the staged representa- -tion, satisfying the goals of a set of software pro- -cesses within a maturity level is accomplished for -that maturity level, which provides a foundation -for improving all of the software processes at the -next higher level. -``` -**4. Software Measurement** - [3*, s26.2] [4*, s18.1.1] - -``` -This topic addresses software process and prod- -uct measurement, quality of measurement results, -software information models, and software pro- -cess measurement techniques (see Measurement -in the Engineering Foundations KA). -Before a new process is implemented or a cur- -rent process is modified, measurement results for -the current situation should be obtained to pro- -vide a baseline for comparison between the cur- -rent situation and the new situation. For exam- -ple, before introducing the software inspection -process, effort required to fix defects discovered -by testing should be measured. Following an ini- -tial start-up period after the inspection process -is introduced, the combined effort of inspection -``` - -``` -Software Engineering Process 8-9 -``` -plus testing can be compared to the previous -amount of effort required for testing alone. Simi- -lar considerations apply if a process is changed. - -_4.1. Software Process and Product Measurement_ -[1*, s6.3, p273] [3*, s26.2, p638] - -Software process and product measurement are -concerned with determining the efficiency and -effectiveness of a software process, activity, or -task. The _efficiency_ of a software process, activity, -or task is the ratio of resources actually consumed -to resources expected or desired to be consumed -in accomplishing a software process, activity, or -task (see Efficiency in the Software Engineering -Economics KA). Effort (or equivalent cost) is the -primary measure of resources for most software -processes, activities, and tasks; it is measured in -units such as person-hours, person-days, staff- -weeks, or staff-months of effort or in equivalent -monetary units—such as euros or dollars. -_Effectiveness_ is the ratio of actual output to -expected output produced by a software process, -activity, or task; for example, actual number of -defects detected and corrected during software -testing to expected number of defects to be -detected and corrected—perhaps based on his- -torical data for similar projects (see Effectiveness -in the Software Engineering Economics KA). -Note that measurement of software process effec- -tiveness requires measurement of the relevant -product attributes; for example, measurement of -software defects discovered and corrected during -software testing. -One must take care when measuring product -attributes for the purpose of determining process -effectiveness. For example, the number of defects -detected and corrected by testing may not achieve -the expected number of defects and thus provide -a misleadingly low effectiveness measure, either -because the software being tested is of better- -than-usual quality or perhaps because introduc- -tion of a newly introduced upstream inspection -process has reduced the remaining number of -defects in the software. -Product measures that may be important in -determining the effectiveness of software pro- -cesses include product complexity, total defects, -defect density, and the quality of requirements, - -``` -design documentation, and other related work -products. -Also note that efficiency and effectiveness are -independent concepts. An effective software pro- -cess can be inefficient in achieving a desired soft- -ware process result; for example, the amount of -effort expended to find and fix software defects -could be very high and result in low efficiency, as -compared to expectations. -An efficient process can be ineffective in accom- -plishing the desired transformation of input work -products into output work products; for example, -failure to find and correct a sufficient number of -software defects during the testing process. -Causes of low efficiency and/or low effective- -ness in the way a software process, activity, or -task is executed might include one or more of the -following problems: deficient input work prod- -ucts, inexperienced personnel, lack of adequate -tools and infrastructure, learning a new process, -a complex product, or an unfamiliar product -domain. The efficiency and effectiveness of soft- -ware process execution are also affected (either -positively or negatively) by factors such as turn- -over in software personnel, schedule changes, a -new customer representative, or a new organiza- -tional policy. -In software engineering, productivity in per- -forming a process, activity, or task is the ratio of -output produced divided by resources consumed; -for example, the number of software defects dis- -covered and corrected divided by person-hours of -effort (see Productivity in the Software Engineer- -ing Economics KA). Accurate measurement of -productivity must include total effort used to sat- -isfy the exit criteria of a software process, activ- -ity, or task; for example, the effort required to -correct defects discovered during software test- -ing must be included in software development -productivity. -Calculation of productivity must account for -the context in which the work is accomplished. -For example, the effort to correct discovered -defects will be included in the productivity cal- -culation of a software team if team members -correct the defects they find—as in unit testing -by software developers or in a cross-functional -agile team. Or the productivity calculation -may include either the effort of the software -``` - -**8-10** **_SWEBOK® Guide_** **V3.0** - -developers or the effort of an independent test- -ing team, depending on who fixes the defects -found by the independent testers. Note that this -example refers to the effort of teams of devel- -opers or teams of testers and not to individuals. -Software productivity calculated at the level of -individuals can be misleading because of the -many factors that can affect the individual pro- -ductivity of software engineers. -Standardized definitions and counting rules -for measurement of software processes and work -products are necessary to provide standardized -measurement results across projects within an -organization, to populate a repository of histori- -cal data that can be analyzed to identify software -processes that need to be improved, and to build -predictive models based on accumulated data. In -the example above, definitions of software defects -and staff-hours of testing effort plus counting -rules for defects and effort would be necessary to -obtain satisfactory measurement results. -The extent to which the software process is -institutionalized is important; failure to institu- -tionalize a software process may explain why -“good” software processes do not always pro- -duce anticipated results. Software processes may -be institutionalized by adoption within the local -organizational unit or across larger units of an -enterprise. - -_4.2. Quality of Measurement Results_ -[4*, s3.4–3.7] - -The quality of process and product measurement -results is primarily determined by the reliability -and validity of the measured results. Measure- -ments that do not satisfy these quality criteria -can result in incorrect interpretations and faulty -software process improvement initiatives. Other -desirable properties of software measurements -include ease of collection, analysis, and presenta- -tion plus a strong correlation between cause and -effect. -The Software Engineering Measurement topic -in the Software Engineering Management KA -describes a process for implementing a software -measurement program. - -``` -4.3. Software Information Models -[1*, p310–311] [3*, p712–713] [4*, s19.2] -``` -``` -Software information models allow modeling, -analysis, and prediction of software process and -software product attributes to provide answers to -relevant questions and achieve process and product -improvement goals. Needed data can be collected -and retained in a repository; the data can be ana- -lyzed and models can be constructed. Validation -and refinement of software information models -occur during software projects and after projects -are completed to ensure that the level of accuracy -is sufficient and that their limitations are known -and understood. Software information models may -also be developed for contexts other than software -projects; for example, a software information -model might be developed for processes that apply -across an organization, such as software configu- -ration management or software quality assurance -processes at the organizational level. -Analysis-driven software information model -building involves the development, calibration, -and evaluation of a model. A software infor- -mation model is developed by establishing a -hypothesized transformation of input variables -into desired outputs; for example, product size -and complexity might be transformed into esti- -mated effort needed to develop a software prod- -uct using a regression equation developed from -observed data from past projects. A model is -calibrated by adjusting parameters in the model -to match observed results from past projects; for -example, the exponent in a nonlinear regression -model might be changed by applying the regres- -sion equation to a different set of past projects -other than the projects used to develop the model. -A model is evaluated by comparing computed -results to actual outcomes for a different set of -similar data. There are three possible evaluation -outcomes: -``` -1. results computed for a different data set vary - widely from actual outcomes for that data - set, in which case the derived model is not - applicable for the new data set and should - 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 - close to actual outcomes for that data set, - in which case minor adjustments are made - to the parameters of the model to improve - agreement; -3. results computed for the new data set and - subsequent data sets are very close and no - adjustments to the model are needed. - -Continuous evaluation of the model may indi- -cate a need for adjustments over time as the con- -text in which the model is applied changes. -The Goals/Questions/Metrics (GQM) method -was originally intended for establishing measure- -ment activities, but it can also be used to guide -analysis and improvement of software processes. -It can be used to guide analysis-driven software -information model building; results obtained -from the software information model can be used -to guide process improvement. -The following example illustrates application -of the GQM method: - -- Goal: Reduce the average change request - processing time by 10% within six months. -- Question 1-1: What is the baseline change - request processing time? -- Metric 1-1-1: Average of change request - processing times on starting date -- Metric 1-1-2: Standard deviation of change - request processing times on starting date -- Question 1-2: What is the current change - request processing time? -- Metric 1-2-1: Average of change request - processing times currently -- Metric 1-2-2: Standard deviation of change - request processing times currently - -_4.4. Software Process Measurement Techniques_ -[1*, c8] - -Software process measurement techniques are -used to collect process data and work product -data, transform the data into useful information, -and analyze the information to identify process -activities that are candidates for improvement. -In some cases, new software processes may be -needed. - -``` -Process measurement techniques also provide -the information needed to measure the effects of -process improvement initiatives. Process mea- -surement techniques can be used to collect both -quantitative and qualitative data. -``` -``` -4.4.1. Quantitative Process Measurement -Techniques -[4*, s5.1, s5.7, s9.8] -``` -``` -The purpose of quantitative process measurement -techniques is to collect, transform, and analyze -quantitative process and work product data that -can be used to indicate where process improve- -ments are needed and to assess the results of -process improvement initiatives. Quantitative -process measurement techniques are used to col- -lect and analyze data in numerical form to which -mathematical and statistical techniques can be -applied. -Quantitative process data can be collected as -a byproduct of software processes. For example, -the number of defects discovered during software -testing and the staff-hours expended can be col- -lected by direct measurement, and the productiv- -ity of defect discovery can be derived by calculat- -ing defects discovered per staff-hour. -Basic tools for quality control can be used to -analyze quantitative process measurement data -(e.g., check sheets, Pareto diagrams, histograms, -scatter diagrams, run charts, control charts, and -cause-and-effect diagrams) (see Root Cause -Analysis in the Engineering Foundations KA). In -addition, various statistical techniques can be used -that range from calculation of medians and means -to multivariate analysis methods (see Statistical -Analysis in the Engineering Foundations KA). -Data collected using quantitative process mea- -surement techniques can also be used as inputs -to simulation models (see Modeling, Prototyp- -ing, and Simulation in the Engineering Founda- -tions KA); these models can be used to assess the -impact of various approaches to software process -improvement. -Orthogonal Defect Classification (ODC) can -be used to analyze quantitative process measure- -ment data. ODC can be used to group detected -defects into categories and link the defects in -``` - -**8-12** **_SWEBOK® Guide_** **V3.0** - -each category to the software process or soft- -ware processes where a group of defects origi- -nated (see Defect Characterization in the Soft- -ware Quality KA). Software interface defects, -for example, may have originated during an inad- -equate software design process; improving the -software design process will reduce the number -of software interface defects. ODC can provide -quantitative data for applying root cause analysis. -Statistical Process Control can be used to track -process stability, or the lack of process stability, -using control charts. - -``` -4.4.2. Qualitative Process Measurement -Techniques -[1*, s6.4] -``` -Qualitative process measurement techniques— -including interviews, questionnaires, and expert -judgment—can be used to augment quantitative -process measurement techniques. Group consen- -sus techniques, including the Delphi technique, -can be used to obtain consensus among groups of -stakeholders. - -**5. Software Engineering Process Tools** - [1*, s8.7] - -Software process tools support many of the nota- -tions used to define, implement, and manage -individual software processes and software life -cycle models. They include editors for notations -such as data-flow diagrams, state charts, BPMN, -IDEF0 diagrams, Petri nets, and UML activity -diagrams. In some cases, software process tools -allow different types of analyses and simula- -tions (for example, discrete event simulation). In - -``` -addition, general purpose business tools, such as -a spreadsheet, may be useful. -Computer-Assisted Software Engineering -(CASE) tools can reinforce the use of integrated -processes, support the execution of process defi- -nitions, and provide guidance to humans in per- -forming well-defined processes. Simple tools -such as word processors and spreadsheets can -be used to prepare textual descriptions of pro- -cesses, activities, and tasks; these tools also sup- -port traceability among the inputs and outputs of -multiple software processes (such as stakeholder -needs analysis, software requirements specifica- -tion, software architecture, and software detailed -design) as well as the results of software pro- -cesses such as documentation, software compo- -nents, test cases, and problem reports. -Most of the knowledge areas in this Guide -describe specialized tools that can be used to -manage the processes within that KA. In particu- -lar, see the Software Configuration Management -KA for a discussion of software configuration -management tools that can be used to manage the -construction, integration, and release processes -for software products. Other tools, such as those -for requirements management and testing, are -described in the appropriate KAs. -Software process tools can support projects -that involve geographically dispersed (virtual) -teams. Increasingly, software process tools are -available through cloud computing facilities as -well as through dedicated infrastructures. -A project control panel or dashboard can dis- -play selected process and product attributes for -software projects and indicate measurements that -are within control limits and those needing cor- -rective action. -``` - -``` -Software Engineering Process 8-13 -``` -##### MATRIX OF TOPICS VS. REFERENCE MATERIAL - -``` -Fairley 2009 -``` -##### [1*] - -``` -Moore 2009 -``` -##### [2*] - -``` -Sommerville 2011 -``` -##### [3*] - -``` -Kan 2003 -``` -##### [4*] - -**1. Software Process Definition** p177 p295 - -``` -p28–29, -p36, -c5 -1.1. Software Process Management s26.1 p453–454 -``` -``` -1.2. Software Process Infrastructure -p183, p186 -p437–438 -``` -**2. Software Life Cycles** c2 p190 - -``` -2.1. Categories of Software Processes preface p294–295 -c22, c23, -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 -Improvement** - p188, p194 c26 p397, c15 - -``` -3.1. Software Process Assessment Models -s4.5, -s4.6 -s26.5 p44–48 -``` -``` -3.2. Software Process Assessment -Methods -p322–331 s26.3 -p44–48, -s16.4 -3.3. Software Process Improvement -Models -p187–188 s26.5 s2.7 -``` -``` -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 - Measurement - -``` -s6.3, -p273 -``` -``` -s26.2, -p638 -``` -``` -4.2. Quality of Measurement Results -``` -``` -s3.4, -s3.5, -s3.6, -s3.7 -4.3. Software Information Models p310–311 p. 712–713 s19.2 -``` -``` -4.4. Software Process Measurement -Te c h n i q u e s -``` -``` -s6.4, -c8 -``` -``` -s5.1, -s5.7, -s9.8 -``` -**5. Software Engineering Process Tools** s8.7 - - -**8-14** **_SWEBOK® Guide_** **V3.0** - -##### FURTHER READINGS - -_Software Extension to the Guide to the Project -Management Body of Knowledge®_ (SWX) -[5]. - -SWX provides adaptations and extensions to the -generic practices of project management docu- -mented in the _PMBOK® Guide_ for managing -software projects. The primary contribution of -this extension to the _PMBOK® Guide_ is descrip- -tion of processes that are applicable for managing -adaptive life cycle software projects. - -D. Gibson, D. Goldenson, and K. Kost, -“Performance Results of CMMI-Based -Process Improvement” [6]. - -This technical report summarizes publicly avail- -able empirical evidence about the performance -results that can occur as a consequence of CMMI- -based process improvement. The report contains -a series of brief case descriptions that were cre- -ated with collaboration from representatives -from 10 organizations that have achieved notable -quantitative performance results through their -CMMI-based improvement efforts. - -_CMMI_ ® _for Development, Version 1.3_ [7]. - -_CMMI_ ® _for Development, Version 1.3_ provides an -integrated set of process guidelines for develop- -ing and improving products and services. These -guidelines include best practices for developing -and improving products and services to meet the -needs of customers and end users. - -_ISO/IEC 15504-1:2004 Information tech- -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 per- -forming process assessments. - -##### REFERENCES - -``` -[1*] R.E. Fairley, Managing and Leading -Software Projects , Wiley-IEEE Computer -Society Press, 2009. -``` -``` -[2*] J.W. Moore, The Road Map to Software -Engineering: A Standards-Based Guide , -Wiley-IEEE Computer Society Press, 2006. -``` -``` -[3*] I. Sommerville, Software Engineering , 9th -ed., Addison-Wesley, 2011. -``` -``` -[4*] S.H. Kan, Metrics and Models in Software -Quality Engineering , 2nd ed., Addison- -Wesley, 2002. -``` -``` -[5] Project Management Institute and IEEE -Computer Society, Software Extension -to the PMBOK® Guide Fifth Edition , ed: -Project Management Institute, 2013. -``` -``` -[6] D. Gibson, D. Goldenson, and K. Kost, -“Performance Results of CMMI-Based -Process Improvement,” Software -Engineering Institute, 2006; http:// -resources.sei.cmu.edu/library/asset-view. -cfm?assetID=8065. -``` -``` -[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. -``` -``` -[8] ISO/IEC 15504-1:2004, Information -Technology—Process Assessment—Part 1: -Concepts and Vocabulary , ISO/IEC, 2004. -``` blob - fb5f86d97e8ae8e2a9fe86e00a3c16d39d0d8d45 (mode 644) blob + /dev/null --- 9_software_engineering_models.markdown +++ /dev/null @@ -1,1138 +0,0 @@ -``` -9-1 -``` -**CHAPTER 9** - -**SOFTWARE ENGINEERING MODELS** - -**AND METHODS** - -##### ACRONYMS - -``` -3GL 3rd Generation Language -BNF Backus-Naur Form -FDD Feature-Driven Development -``` -``` -IDE -Integrated Development -Environment -PBI Product Backlog Item -RAD Rapid Application Development -UML Unified Modeling Language -XP eXtreme Programming -``` -##### INTRODUCTION - -Software engineering models and methods -impose structure on software engineering with -the goal of making that activity systematic, -repeatable, and ultimately more success-oriented. -Using models provides an approach to problem -solving, a notation, and procedures for model -construction and analysis. Methods provide an -approach to the systematic specification, design, -construction, test, and verification of the end-item -software and associated work products. -Software engineering models and methods -vary widely in scope—from addressing a single -software life cycle phase to covering the com- -plete software life cycle. The emphasis in this -knowledge area (KA) is on software engineer- -ing models and methods that encompass multiple -software life cycle phases, since methods specific -for single life cycle phases are covered by other -KAs. - -##### BREAKDOWN OF TOPICS FOR - -##### SOFTWARE ENGINEERING MODELS - -##### AND METHODS - -``` -This chapter on software engineering models and -methods is divided into four main topic areas: -``` -- _Modeling_ : discusses the general practice - of modeling and presents topics in model- - ing principles; properties and expression of - models; modeling syntax, semantics, and - pragmatics; and preconditions, postcondi- - tions, and invariants. -- _Types of Models_ : briefly discusses models - and aggregation of submodels and provides - some general characteristics of model types - commonly found in the software engineering - practice. -- _Analysis of Models_ : presents some of the - common analysis techniques used in model- - ing to verify completeness, consistency, cor- - rectness, traceability, and interaction. -- _Software Engineering Methods_ : presents a - brief summary of commonly used software - engineering methods. The discussion guides - the reader through a summary of heuristic - methods, formal methods, prototyping, and - agile methods. - -``` -The breakdown of topics for the Software -Engineering Models and Methods KA is shown -in Figure 9.1. -``` -**1. Modeling** - -``` -Modeling of software is becoming a pervasive -technique to help software engineers understand, -``` - -**9-2** **_SWEBOK® Guide_** **V3.0** - -engineer, and communicate aspects of the soft- -ware to appropriate stakeholders. Stakeholders -are those persons or parties who have a stated -or implied interest in the software (for example, -user, buyer, supplier, architect, certifying author- -ity, evaluator, developer, software engineer, and -perhaps others). -While there are many modeling languages, -notations, techniques, and tools in the literature -and in practice, there are unifying general con- -cepts that apply in some form to them all. The -following sections provide background on these -general concepts. - -_1.1. Modeling Principles_ -[1*, c2s2, c5s1, c5s2] [2*, c2s2] [3*, c5s0] - -Modeling provides the software engineer with -an organized and systematic approach for repre- -senting significant aspects of the software under -study, facilitating decision-making about the soft- -ware or elements of it, and communicating those - -``` -significant decisions to others in the stakeholder -communities. There are three general principles -guiding such modeling activities: -``` -- _Model the Essentials_ : good models do not - usually represent every aspect or feature of - the software under every possible condition. - Modeling typically involves developing only - those aspects or features of the software that - need specific answers, abstracting away any - nonessential information. This approach - keeps the models manageable and useful. -- _Provide Perspective_ : modeling provides - views of the software under study using - a defined set of rules for expression of the - model within each view. This perspective- - driven approach provides dimensionality to - the model (for example, a structural view, - behavioral view, temporal view, organiza- - tional view, and other views as relevant). - Organizing information into views focuses - the software modeling efforts on specific - -``` -Figure 9.1. Breakdown of Topics for the Software Engineering Models and Methods KA -``` - -``` -Software Engineering Models and Methods 9-3 -``` -``` -concerns relevant to that view using the -appropriate notation, vocabulary, methods, -and tools. -``` -- _Enable Effective Communications_ : modeling - employs the application domain vocabulary - of the software, a modeling language, and - semantic expression (in other words, mean- - ing within context). When used rigorously - and systematically, this modeling results in - a reporting approach that facilitates effective - communication of software information to - project stakeholders. - -A model is an _abstraction_ or simplification of -a software component. A consequence of using -abstraction is that no single abstraction com- -pletely describes a software component. Rather, -the model of the software is represented as an -aggregation of abstractions, which—when taken -together—describe only selected aspects, per- -spectives, or views—only those that are needed -to make informed decisions and respond to the -reasons for creating the model in the first place. -This simplification leads to a set of assumptions -about the context within which the model is -placed that should also be captured in the model. -Then, when reusing the model, these assumptions -can be validated first to establish the relevancy of -the reused model within its new use and context. - -_1.2. Properties and Expression of Models_ -[1*, c5s2, c5s3] [3*, c4s1.1p7, c4s6p3, -c5s0p3] - -Properties of models are those distinguishing fea- -tures of a particular model used to characterize -its completeness, consistency, and correctness -within the chosen modeling notation and tooling -used. Properties of models include the following: - -- _Completeness_ : the degree to which all - requirements have been implemented and - verified within the model. -- _Consistency_ : the degree to which the model - contains no conflicting requirements, asser- - tions, constraints, functions, or component - descriptions. -- _Correctness_ : the degree to which the model - satisfies its requirements and design specifi- - cations and is free of defects. - -``` -Models are constructed to represent real-world -objects and their behaviors to answer specific -questions about how the software is expected -to operate. Interrogating the models—either -through exploration, simulation, or review—may -expose areas of uncertainty within the model and -the software to which the model refers. These -uncertainties or unanswered questions regarding -the requirements, design, and/or implementation -can then be handled appropriately. -The primary expression element of a model is -an entity. An entity may represent concrete arti- -facts (for example, processors, sensors, or robots) -or abstract artifacts (for example, software mod- -ules or communication protocols). Model enti- -ties are connected to other entities using rela- -tions (in other words, lines or textual operators -on target entities). Expression of model entities -may be accomplished using textual or graphical -modeling languages; both modeling language -types connect model entities through specific lan- -guage constructs. The meaning of an entity may -be represented by its shape, textual attributes, or -both. Generally, textual information adheres to -language-specific syntactic structure. The pre- -cise meanings related to the modeling of context, -structure, or behavior using these entities and -relations is dependent on the modeling language -used, the design rigor applied to the modeling -effort, the specific view being constructed, and -the entity to which the specific notation element -may be attached. Multiple views of the model -may be required to capture the needed semantics -of the software. -When using models supported with automa- -tion, models may be checked for completeness -and consistency. The usefulness of these checks -depends greatly on the level of semantic and syn- -tactic rigor applied to the modeling effort in addi- -tion to explicit tool support. Correctness is typi- -cally checked through simulation and/or review. -``` -``` -1.3. Syntax, Semantics, and Pragmatics -[2* c2s2.2.2p6] [3*, c5s0] -``` -``` -Models can be surprisingly deceptive. The fact -that a model is an abstraction with missing infor- -mation can lead one into a false sense of com- -pletely understanding the software from a single -model. A complete model (“complete” being -``` - -**9-4** **_SWEBOK® Guide_** **V3.0** - -relative to the modeling effort) may be a union -of multiple submodels and any special function -models. Examination and decision-making rela- -tive to a single model within this collection of -submodels may be problematic. -Understanding the precise meanings of mod- -eling constructs can also be difficult. Modeling -languages are defined by syntactic and semantic -rules. For textual languages, syntax is defined -using a notation grammar that defines valid lan- -guage constructs (for example, Backus-Naur -Form (BNF)). For graphical languages, syntax is -defined using graphical models called metamod- -els. As with BNF, metamodels define the valid -syntactical constructs of a graphical modeling -language; the metamodel defines how these con- -structs can be composed to produce valid models. -Semantics for modeling languages specify the -meaning attached to the entities and relations -captured within the model. For example, a simple -diagram of two boxes connected by a line is open -to a variety of interpretations. Knowing that the -diagram on which the boxes are placed and con- -nected is an object diagram or an activity diagram -can assist in the interpretation of this model. -As a practical matter, there is usually a good -understanding of the semantics of a specific -software model due to the modeling language -selected, how that modeling language is used to -express entities and relations within that model, -the experience base of the modeler(s), and the -context within which the modeling has been -undertaken and so represented. Meaning is com- -municated through the model even in the presence -of incomplete information through abstraction; -pragmatics explains how meaning is embodied -in the model and its context and communicated -effectively to other software engineers. -There are still instances, however, where cau- -tion is needed regarding modeling and semantics. -For example, any model parts imported from -another model or library must be examined for -semantic assumptions that conflict in the new -modeling environment; this may not be obvious. -The model should be checked for documented -assumptions. While modeling syntax may be -identical, the model may mean something quite -different in the new environment, which is a dif- -ferent context. Also, consider that as software -matures and changes are made, semantic discord - -``` -can be introduced, leading to errors. With many -software engineers working on a model part over -time coupled with tool updates and perhaps new -requirements, there are opportunities for portions -of the model to represent something different -from the original author’s intent and initial model -context. -``` -``` -1.4. Preconditions, Postconditions, and -Invariants -[2*, c4s4] [4*, c10s4p2, c10s5p2p4] -``` -``` -When modeling functions or methods, the soft- -ware engineer typically starts with a set of -assumptions about the state of the software prior -to, during, and after the function or method exe- -cutes. These assumptions are essential to the cor- -rect operation of the function or method and are -grouped, for discussion, as a set of preconditions, -postconditions, and invariants. -``` -- _Preconditions_ : a set of conditions that must - be satisfied prior to execution of the function - or method. If these preconditions do not hold - prior to execution of the function or method, - the function or method may produce errone- - ous results. -- _Postconditions_ : a set of conditions that is - guaranteed to be true after the function or - method has executed successfully. Typically, - the postconditions represent how the state - of the software has changed, how param- - eters passed to the function or method have - changed, how data values have changed, or - how the return value has been affected. -- _Invariants_ : a set of conditions within the - operational environment that persist (in - other words, do not change) before and after - execution of the function or method. These - invariants are relevant and necessary to the - software and the correct operation of the - function or method. -**2. Types of Models** - -``` -A typical model consists of an aggregation of -submodels. Each submodel is a partial descrip- -tion and is created for a specific purpose; it may -be comprised of one or more diagrams. The -collection of submodels may employ multiple -``` - -``` -Software Engineering Models and Methods 9-5 -``` -modeling languages or a single modeling lan- -guage. The Unified Modeling Language (UML) -recognizes a rich collection of modeling dia- -grams. Use of these diagrams, along with the -modeling language constructs, brings about three -broad model types commonly used: information -models, behavioral models, and structure models -(see section 1.1). - -_2.1. Information Modeling_ -[1*, c7s2.2] [3*, c8s1] - -Information models provide a central focus on -data and information. An information model is an -abstract representation that identifies and defines -a set of concepts, properties, relations, and con- -straints on data entities. The semantic or concep- -tual information model is often used to provide -some formalism and context to the software being -modeled as viewed from the problem perspective, -without concern for how this model is actually -mapped to the implementation of the software. -The semantic or conceptual information model -is an abstraction and, as such, includes only the -concepts, properties, relations, and constraints -needed to conceptualize the real-world view of -the information. Subsequent transformations of -the semantic or conceptual information model -lead to the elaboration of logical and then physi- -cal data models as implemented in the software. - -_2.2. Behavioral Modeling_ -[1*, c7s2.1, c7s2.3, c7s2.4] [2*, c9s2] -[3*, c5s4] - -Behavioral models identify and define the func- -tions of the software being modeled. Behav- -ioral models generally take three basic forms: -state machines, control-flow models, and data- -flow models. State machines provide a model -of the software as a collection of defined states, -events, and transitions. The software transitions -from one state to the next by way of a guarded -or unguarded triggering event that occurs in the -modeled environment. Control-flow models -depict how a sequence of events causes processes -to be activated or deactivated. Data-flow behav- -ior is typified as a sequence of steps where data -moves through processes toward data stores or -data sinks. - -``` -2.3. Structure Modeling -[1*, c7s2.5, c7s3.1, c7s3.2] [3*, c5s3] [4*, c4] -``` -``` -Structure models illustrate the physical or logical -composition of software from its various com- -ponent parts. Structure modeling establishes the -defined boundary between the software being -implemented or modeled and the environment -in which it is to operate. Some common struc- -tural constructs used in structure modeling are -composition, decomposition, generalization, and -specialization of entities; identification of rel- -evant relations and cardinality between entities; -and the definition of process or functional inter- -faces. Structure diagrams provided by the UML -for structure modeling include class, component, -object, deployment, and packaging diagrams. -``` -**3. Analysis of Models** - -``` -The development of models affords the software -engineer an opportunity to study, reason about, -and understand the structure, function, opera- -tional usage, and assembly considerations asso- -ciated with software. Analysis of constructed -models is needed to ensure that these models are -complete, consistent, and correct enough to serve -their intended purpose for the stakeholders. -The sections that follow briefly describe the -analysis techniques generally used with soft- -ware models to ensure that the software engineer -and other relevant stakeholders gain appropriate -value from the development and use of models. -``` -``` -3.1. Analyzing for Completeness -[3*, c4s1.1p7, c4s6] [5*, p8–11] -``` -``` -In order to have software that fully meets the needs -of the stakeholders, completeness is critical—from -the requirements elicitation process to code imple- -mentation. Completeness is the degree to which -all of the specified requirements have been imple- -mented and verified. Models may be checked for -completeness by a modeling tool that uses tech- -niques such as structural analysis and state-space -reachability analysis (which ensure that all paths in -the state models are reached by some set of correct -inputs); models may also be checked for complete- -ness manually by using inspections or other review -techniques (see the Software Quality KA). Errors -``` - -**9-6** **_SWEBOK® Guide_** **V3.0** - -and warnings generated by these analysis tools and -found by inspection or review indicate probable -needed corrective actions to ensure completeness -of the models. - -_3.2. Analyzing for Consistency_ -[3*, c4s1.1p7, c4s6] [5*, p8–11] - -Consistency is the degree to which models con- -tain no conflicting requirements, assertions, con- -straints, functions, or component descriptions. -Typically, consistency checking is accomplished -with the modeling tool using an automated analysis -function; models may also be checked for consis- -tency manually using inspections or other review -techniques (see the Software Quality KA). As -with completeness, errors and warnings generated -by these analysis tools and found by inspection or -review indicate the need for corrective action. - -_3.3. Analyzing for Correctness_ -[5*, p8–11] - -Correctness is the degree to which a model sat- -isfies its software requirements and software -design specifications, is free of defects, and ulti- -mately meets the stakeholders’ needs. Analyzing -for correctness includes verifying syntactic cor- -rectness of the model (that is, correct use of the -modeling language grammar and constructs) and -verifying semantic correctness of the model (that -is, use of the modeling language constructs to -correctly represent the meaning of that which is -being modeled). To analyze a model for syntactic -and semantic correctness, one analyzes it—either -automatically (for example, using the modeling -tool to check for model syntactic correctness) -or manually (using inspections or other review -techniques)—searching for possible defects and -then removing or repairing the confirmed defects -before the software is released for use. - -_3.4. Traceability_ -[3*, c4s7.1, c4s7.2] - -Developing software typically involves the use, -creation, and modification of many work products -such as planning documents, process specifica- -tions, software requirements, diagrams, designs - -``` -and pseudo-code, handwritten and tool-generated -code, manual and automated test cases and reports, -and files and data. These work products may be -related through various dependency relationships -(for example, uses, implements, and tests). As soft- -ware is being developed, managed, maintained, or -extended, there is a need to map and control these -traceability relationships to demonstrate soft- -ware requirements consistency with the software -model (see Requirements Tracing in the Software -Requirements KA) and the many work products. -Use of traceability typically improves the manage- -ment of software work products and software pro- -cess quality; it also provides assurances to stake- -holders that all requirements have been satisfied. -Traceability enables change analysis once the soft- -ware is developed and released, since relationships -to software work products can easily be traversed -to assess change impact. Modeling tools typically -provide some automated or manual means to spec- -ify and manage traceability links between require- -ments, design, code, and/or test entities as may be -represented in the models and other software work -products. (For more information on traceability, -see the Software Configuration Management KA). -``` -``` -3.5. Interaction Analysis -[2*, c10, c11] [3*, c29s1.1, c29s5] [4*, c5] -``` -``` -Interaction analysis focuses on the communica- -tions or control flow relations between entities -used to accomplish a specific task or function -within the software model. This analysis exam- -ines the dynamic behavior of the interactions -between different portions of the software model, -including other software layers (such as the oper- -ating system, middleware, and applications). It -may also be important for some software applica- -tions to examine interactions between the com- -puter software application and the user interface -software. Some software modeling environments -provide simulation facilities to study aspects of -the dynamic behavior of modeled software. Step- -ping through the simulation provides an analysis -option for the software engineer to review the -interaction design and verify that the different -parts of the software work together to provide the -intended functions. -``` - -``` -Software Engineering Models and Methods 9-7 -``` -**4. Software Engineering Methods** - -Software engineering methods provide an orga- -nized and systematic approach to developing soft- -ware for a target computer. There are numerous -methods from which to choose, and it is important -for the software engineer to choose an appropriate -method or methods for the software development -task at hand; this choice can have a dramatic effect -on the success of the software project. Use of these -software engineering methods coupled with people -of the right skill set and tools enable the software -engineers to visualize the details of the software -and ultimately transform the representation into a -working set of code and data. -Selected software engineering methods are dis- -cussed below. The topic areas are organized into -discussions of Heuristic Methods, Formal Meth- -ods, Prototyping Methods, and Agile Methods. - -_4.1. Heuristic Methods_ -[1*, c13, c15, c16] [3*, c2s2.2, c5s4.1, c7s1,] - -Heuristic methods are those experience-based -software engineering methods that have been and -are fairly widely practiced in the software indus- -try. This topic area contains three broad discus- -sion categories: structured analysis and design -methods, data modeling methods, and object- -oriented analysis and design methods. - -- _Structured Analysis and Design Methods_ : - The software model is developed primarily - from a functional or behavioral viewpoint, - starting from a high-level view of the soft- - ware (including data and control elements) - and then progressively decomposing or refin- - ing the model components through increas- - ingly detailed designs. The detailed design - eventually converges to very specific details - or specifications of the software that must be - coded (by hand, automatically generated, or - both), built, tested, and verified. -- _Data Modeling Methods_ : The data model is - constructed from the viewpoint of the data or - information used. Data tables and relation- - ships define the data models. This data mod- - eling method is used primarily for defining - and analyzing data requirements supporting - -``` -database designs or data repositories typi- -cally found in business software, where data -is actively managed as a business systems -resource or asset. -``` -- _Object-Oriented Analysis and Design Meth-_ - _ods_ : The object-oriented model is represented - as a collection of objects that encapsulate - data and relationships and interact with other - objects through methods. Objects may be - real-world items or virtual items. The soft- - ware model is constructed using diagrams - to constitute selected views of the software. - Progressive refinement of the software mod- - els leads to a detailed design. The detailed - design is then either evolved through suc- - cessive iteration or transformed (using some - mechanism) into the implementation view - of the model, where the code and packag- - ing approach for eventual software product - release and deployment is expressed. - -``` -4.2. Formal Methods -[1*, c18] [3*, c27] [5*, p8–24] -``` -``` -Formal methods are software engineering meth- -ods used to specify, develop, and verify the soft- -ware through application of a rigorous mathemat- -ically based notation and language. Through use -of a specification language, the software model -can be checked for consistency (in other words, -lack of ambiguity), completeness, and correctness -in a systematic and automated or semi-automated -fashion. This topic is related to the Formal Analy- -sis section in the Software Requirements KA. -This section addresses specification languages, -program refinement and derivation, formal verifi- -cation, and logical inference. -``` -- _Specification Languages_ : Specification - languages provide the mathematical basis - for a formal method; specification lan- - guages are formal, higher level computer - languages (in other words, not a classic - 3rd Generation Language (3GL) program- - ming language) used during the software - specification, requirements analysis, and/ - or design stages to describe specific input/ - output behavior. Specification languages are - not directly executable languages; they are - - -**9-8** **_SWEBOK® Guide_** **V3.0** - -``` -typically comprised of a notation and syntax, -semantics for use of the notation, and a set of -allowed relations for objects. -``` -- _Program Refinement and Derivation_ : Pro- - gram refinement is the process of creating a - lower level (or more detailed) specification - using a series of transformations. It is through - successive transformations that the software - engineer derives an executable representation - of a program. Specifications may be refined, - adding details until the model can be formu- - lated in a 3GL programming language or in - an executable portion of the chosen specifica- - tion language. This specification refinement is - made possible by defining specifications with - precise semantic properties; the specifications - must set out not only the relationships between - entities but also the exact runtime meanings of - those relationships and operations. -- _Formal Verification_ : Model checking is - a formal verification method; it typically - involves performing a state-space explora- - tion or reachability analysis to demonstrate - that the represented software design has or - preserves certain model properties of inter- - est. An example of model checking is an - analysis that verifies correct program behav- - ior under all possible interleaving of event or - message arrivals. The use of formal verifi- - cation requires a rigorously specified model - of the software and its operational environ- - ment; this model often takes the form of a - finite state machine or other formally defined - automaton. -- _Logical Inference_ : Logical inference is a - method of designing software that involves - specifying preconditions and postconditions - around each significant block of the design, - and—using mathematical logic—developing - the proof that those preconditions and post- - conditions must hold under all inputs. This - provides a way for the software engineer to - predict software behavior without having - to execute the software. Some Integrated - Development Environments (IDEs) include - ways to represent these proofs along with the - design or code. - -``` -4.3. Prototyping Methods -[1*, c12s2] [3*, c2s3.1] [6*, c7s3p5] -``` -``` -Software prototyping is an activity that generally -creates incomplete or minimally functional ver- -sions of a software application, usually for try- -ing out specific new features, soliciting feedback -on software requirements or user interfaces, fur- -ther exploring software requirements, software -design, or implementation options, and/or gaining -some other useful insight into the software. The -software engineer selects a prototyping method to -understand the least understood aspects or com- -ponents of the software first; this approach is in -contrast with other software engineering methods -that usually begin development with the most -understood portions first. Typically, the proto- -typed product does not become the final software -product without extensive development rework -or refactoring. -This section discusses prototyping styles, tar- -gets, and evaluation techniques in brief. -``` -- _Prototyping Style_ : This addresses the various - approaches to developing prototypes. Proto- - types can be developed as throwaway code - or paper products, as an evolution of a work- - ing design, or as an executable specification. - Different prototyping life cycle processes are - typically used for each style. The style cho- - sen is based on the type of results the project - needs, the quality of the results needed, and - the urgency of the results. -- _Prototyping Target_ : The target of the pro- - totype activity is the specific product being - served by the prototyping effort. Examples - of prototyping targets include a requirements - specification, an architectural design element - or component, an algorithm, or a human- - machine user interface. -- _Prototyping Evaluation Techniques_ : A pro- - totype may be used or evaluated in a num- - ber of ways by the software engineer or - other project stakeholders, driven primarily - by the underlying reasons that led to pro- - totype development in the first place. Pro- - 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 -requirements prototype); the prototype may -also serve as a model for a future software -development effort (for example, as in a user -interface specification). -``` -_4.4. Agile Methods_ -[3*, c3] [6*, c7s3p7] [7*, c6, App. A] - -Agile methods were born in the 1990s from the -need to reduce the apparent large overhead associ- -ated with heavyweight, plan-based methods used -in large-scale software-development projects. -Agile methods are considered lightweight meth- -ods in that they are characterized by short, itera- -tive development cycles, self-organizing teams, -simpler designs, code refactoring, test-driven -development, frequent customer involvement, and -an emphasis on creating a demonstrable working -product with each development cycle. -Many agile methods are available in the lit- -erature; some of the more popular approaches, -which are discussed here in brief, include Rapid -Application Development (RAD), eXtreme Pro- -gramming (XP), Scrum, and Feature-Driven -Development (FDD). - -- _RAD:_ Rapid software development methods - are used primarily in data-intensive, business- - systems application development. The RAD - method is enabled with special-purpose data- - base development tools used by software - engineers to quickly develop, test, and deploy - new or modified business applications. -- _XP_ : This approach uses stories or scenarios - for requirements, develops tests first, has - direct customer involvement on the team - (typically defining acceptance tests), uses - pair programming, and provides for continu- - ous code refactoring and integration. Stories - are decomposed into tasks, prioritized, esti- - mated, developed, and tested. Each incre- - ment of software is tested with automated - and manual tests; an increment may be - released frequently, such as every couple of - weeks or so. - - _Scrum_ : This agile approach is more project - management-friendly than the others. The - scrum master manages the activities within - the project increment; each increment is - called a sprint and lasts no more than 30 - days. A Product Backlog Item (PBI) list is - developed from which tasks are identified, - defined, prioritized, and estimated. A work- - ing version of the software is tested and - released in each increment. Daily scrum - meetings ensure work is managed to plan. - - _FDD:_ This is a model-driven, short, itera- - tive software development approach using - a five-phase process: (1) develop a product - model to scope the breadth of the domain, (2) - create the list of needs or features, (3) build - the feature development plan, (4) develop - designs for iteration-specific features, and - (5) code, test, and then integrate the features. - FDD is similar to an incremental software - development approach; it is also similar to - XP, except that code ownership is assigned - to individuals rather than the team. FDD - emphasizes an overall architectural approach - to the software, which promotes building the - feature correctly the first time rather than - emphasizing continual refactoring. - -``` -There are many more variations of agile meth- -ods in the literature and in practice. Note that -there will always be a place for heavyweight, -plan-based software engineering methods as well -as places where agile methods shine. There are -new methods arising from combinations of agile -and plan-based methods where practitioners are -defining new methods that balance the features -needed in both heavyweight and lightweight -methods based primarily on prevailing organi- -zational business needs. These business needs, -as typically represented by some of the project -stakeholders, should and do drive the choice in -using one software engineering method over -another or in constructing a new method from the -best features of a combination of software engi- -neering methods. -``` - -**9-10** **_SWEBOK® Guide_** **V3.0** - -##### MATRIX OF TOPICS VS. REFERENCE MATERIAL - -``` -Budgen 2003 -``` -##### [1*] - -``` -Mellor and Balcer 2002 -``` -##### [2*] - -``` -Sommerville 2011 -``` -##### [3*] - -``` -Page-Jones 1999 -``` -##### [4*] - -``` -Wing 1990 -``` -##### [5*] - -``` -Brookshear 2008 -``` -##### [6*] - -``` -Boehm and Turner 2003 -``` -##### [7*] - -**1. Modeling** - -``` -1.1. Modeling -Principles -``` -``` -c2s2, -c5s1, -c5s2 -``` -``` -c2s2 c5s0 -``` -``` -1.2. Properties -and Expression of -Models -``` -``` -c5s2, -c5s3 -``` -``` -c4s1.1p7, -c4s6p3, -c5s0p3 -1.3. Syntax, -Semantics, and -Pragmatics -``` -``` -c2s2.2.2 -p6 -c5s0 -``` -``` -1.4. Preconditions, -Postconditions, and -Invariants -``` -``` -c4s4 -``` -``` -c10s4p2, -c10s5 -p2p4 -``` -**2. Types of Models** - 2.1. Information - Modeling - c7s2.2 c8s1 - -``` -2.2. Behavioral -Modeling -``` -``` -c7s2.1, -c7s2.3, -c7s2.4 -``` -``` -c9s2 c5s4 -``` -``` -2.3. Structure -Modeling -``` -``` -c7s2.5, -c7s3.1, -c7s3.2 -``` -``` -c5s3 c4 -``` -**3. Analysis of Models** - 3.1. Analyzing for - Completeness - -``` -c4s1.1p7, -c4s6 -pp8–11 -``` -``` -3.2. Analyzing for -Consistency -``` -``` -c4s1.1p7, -c4s6 -pp8–11 -``` -``` -3.3. Analyzing for -Correctness -pp8–11 -``` -``` -3.4. Traceability -c4s7.1, -c4s7.2 -3.5. Interaction -Analysis -c10, c11 -c29s1.1, -c29s5 -c5 -``` - -``` -Software Engineering Models and Methods 9-11 -``` -``` -Budgen 2003 -``` -##### [1*] - -``` -Mellor and Balcer 2002 -``` -##### [2*] - -``` -Sommerville 2011 -``` -##### [3*] - -``` -Page-Jones 1999 -``` -##### [4*] - -``` -Wing 1990 -``` -##### [5*] - -``` -Brookshear 2008 -``` -##### [6*] - -``` -Boehm and Turner 2003 -``` -##### [7*] - -**4. Software -Engineering Methods** - -``` -4.1. Heuristic -Methods -``` -``` -c13, c15, -c16 -``` -``` -c2s2.2, -c7s1, -c5s4.1 -4.2. Formal Methods c18 c27 pp8–24 -4.3. Prototyping -Methods -c12s2 c2s3.1 c7s3p5 -``` -``` -4.4. Agile Methods c3 c7s3p7 -c6, app. -A -``` - -**9-12** **_SWEBOK® Guide_** **V3.0** - -##### REFERENCES - -[1*] D. Budgen, _Software Design_ , 2nd ed., -Addison-Wesley, 2003. - -[2*] S.J. Mellor and M.J. Balcer, _Executable -UML: A Foundation for Model-Driven -Architecture_ , 1st ed., Addison-Wesley, -2002. - -[3*] I. Sommerville, _Software Engineering_ , 9th -ed., Addison-Wesley, 2011. - -[4*] M. Page-Jones, _Fundamentals of Object- -Oriented Design in UML_ , 1st ed., Addison- -Wesley, 1999. - -``` -[5*] J.M. Wing, “A Specifier’s Introduction to -Formal Methods,” Computer , vol. 23, no. 9, -1990, pp. 8, 10–23. -``` -``` -[6*] J.G. Brookshear, Computer Science: An -Overview , 10th ed., Addison-Wesley, 2008. -``` -``` -[7*] B. Boehm and R. Turner, Balancing Agility -and Discipline: A Guide for the Perplexed , -Addison-Wesley, 2003. -``` blob - 92172c58d8acd39218d376c6f1c290e962a9bfa9 (mode 644) blob + /dev/null --- Makefile +++ /dev/null @@ -1,35 +0,0 @@ -MAKRDOWN_FILES += 0_introduction.markdown -MAKRDOWN_FILES += 1_software_requirements.markdown -MAKRDOWN_FILES += 2_software_design.markdown -MAKRDOWN_FILES += 3_software_construction.markdown -MAKRDOWN_FILES += 4_software_testing.markdown -MAKRDOWN_FILES += 5_software_maintenance.markdown -MAKRDOWN_FILES += 6_software_configuration_management.markdown -MAKRDOWN_FILES += 7_software_engineering_management.markdown -MAKRDOWN_FILES += 8_software_engineering_process.markdown -MAKRDOWN_FILES += 9_software_engineering_models.markdown -MAKRDOWN_FILES += 10_software_quality.markdown -MAKRDOWN_FILES += 11_software_engineering.markdown -MAKRDOWN_FILES += 12_software_engineering_economics.markdown -MAKRDOWN_FILES += 13_computing_foundations.markdown -MAKRDOWN_FILES += 14_mathematical_foundations.markdown -MAKRDOWN_FILES += 15_engineering_foundations.markdown -MAKRDOWN_FILES += appendix.markdown - -PANDOC = pandoc -PANDOC_OPT = -s --toc-depth=2 --number-sections --toc -c epub.css title.txt $(MAKRDOWN_FILES) -NAME = swebook-v3 - -epub: $(MAKRDOWN_FILES) epub.css title.txt - $(PANDOC) $(PANDOC_OPT) --epub-cover-image=images/SWEBOK_logo_v2.jpg -o $(NAME).epub - -html: $(MAKRDOWN_FILES) epub.css - $(PANDOC) $(PANDOC_OPT) -o $(NAME).html - -release: $(NAME).epub $(NAME).html - zip swebook.zip $(NAME).epub $(NAME).html - -clean: - rm -f $(NAME).html $(NAME).epub $(NAME).zip - -.PHONY: clean blob - 59e92e76ab4ef868b32cdd332b7aa5cebe9f8a78 (mode 644) blob + /dev/null --- appendix.markdown +++ /dev/null @@ -1,4122 +0,0 @@ -``` -A-1 -``` -**APPENDIX A** - -**KNOWLEDGE AREA DESCRIPTION** - -**SPECIFICATIONS** - -##### INTRODUCTION - -This document presents the specifications pro- -vided to the Knowledge Area Editors (KA Edi- -tors) regarding the Knowledge Area Descriptions -(KA Descriptions) of the Version 3 (V3) edition -of the _Guide to the Software Engineering Body -of Knowledge (SWEBOK Guide)_. This document -will also enable readers, reviewers, and users to -clearly understand what specifications were used -when developing this version of the _SWEBOK -Guide_. -This document begins by situating the _SWE- -BOK Guide_ as a foundational document for the -IEEE Computer Society suite of software engi- -neering products and more widely within the -software engineering community at large. The -role of the baseline and the Change Control -Board is then described. Criteria and require- -ments are defined for the breakdowns of topics, -for the rationale underlying these breakdowns -and the succinct description of topics, and for ref- -erence materials. Important input documents are -also identified, and their role within the project is -explained. Noncontent issues such as submission -format and style guidelines are also discussed. - -**THE SWEBOK GUIDE IS A -FOUNDATIONAL DOCUMENT FOR THE -IEEE COMPUTER SOCIETY SUITE OF -SOFTWARE ENGINEERING PRODUCTS** - -The _SWEBOK Guide_ is an IEEE Computer Soci- -ety flagship and structural document for the IEEE -Computer Society suite of software engineer- -ing products. The _SWEBOK Guide_ is also more -widely recognized as a foundational document -within the software engineering community at - -``` -large notably through the official recognition of -the 2004 Version as ISO/IEC Technical Report -19759:2005. The list of knowledge areas (KAs) -and the breakdown of topics within each KA is -described and detailed in the introduction of this -SWEBOK Guide. -Consequently, the SWEBOK Guide is founda- -tional to other initiatives within the IEEE Com- -puter Society: -``` -``` -a) The list of KAs and the breakdown of topics -within each KA are also adopted by the soft- -ware engineering certification and associated -professional development products offered -by the IEEE Computer Society (see http://www. -computer.org/certification). -b) The list of KAs and the breakdown of top- -ics are also foundational to the software -engineering curricula guidelines developed -or endorsed by the IEEE Computer Society -(www.computer.org/portal/web/education/ -Curricula). -c) The Consolidated Reference List (see Appen- -dix C), meaning the list of recommended -reference materials (to the level of section -number) that accompanies the breakdown of -topics within each KA is also adopted by the -software engineering certification and asso- -ciated professional development products -offered by the IEEE Computer Society. -``` -``` -BASELINE AND CHANGE CONTROL -BOARD -``` -``` -Due to the structural nature of the SWEBOK -Guide and its adoption by other products, a base- -line was developed at the outset of the project -comprised of the list of KAs, the breakdown of -``` - -**A-2** **_SWEBOK® Guide_** **V3.0** - -topics within each KA, and the Consolidated Ref- -erence List. -A Change Control Board (CCB) has been in -place for the development of this version to han- -dle all change requests to this baseline coming -from the KA Editors, arising during the review -process, or otherwise. Change requests must be -approved both by the _SWEBOK Guide_ Editors -and by the CCB before being implemented. This -CCB is comprised of members of the initiatives -listed above and acting under the authority of the -Software and Systems Engineering Committee of -the IEEE Computer Society Professional Activi- -ties Board. - -**CRITERIA AND REQUIREMENTS FOR -THE BREAKDOWN OF TOPICS WITHIN -A KNOWLEDGE AREA** - -``` -a) KA Editors are instructed to adopt the base- -line breakdown of topics. -b) The breakdown of topics is expected to be -“reasonable,” not “perfect.” -c) The breakdown of topics within a KA must -decompose the subset of the Software Engi- -neering Body of Knowledge that is “gen- -erally recognized.” See below for a more -detailed discussion of this point. -d) The breakdown of topics within a KA must -not presume specific application domains, -business needs, sizes of organizations, organi- -zational structures, management philosophies, -software life cycle models, software technolo- -gies, or software development methods. -e) The breakdown of topics must, as much -as possible, be compatible with the vari- -ous schools of thought within software -engineering. -f) The breakdown of topics within a KA must -be compatible with the breakdown of soft- -ware engineering generally found in indus- -try and in the software engineering literature -and standards. -g) The breakdown of topics is expected to be as -inclusive as possible. -h) The SWEBOK Guide adopts the position -that even though the following “themes” are -common across all Knowledge Areas, they -are also an integral part of all Knowledge -``` -``` -Areas and therefore must be incorporated -into the proposed breakdown of topics of -each Knowledge Area. These common -themes are measurement, quality (in gen- -eral), and security. -i) The breakdown of topics should be at most -two or three levels deep. Even though no -upper or lower limit is imposed on the num- -ber of topics within each KA, a reasonable -and manageable number of topics is expected -to be included in each KA. Emphasis should -also be put on the selection of the topics -themselves rather than on their organization -in an appropriate hierarchy. -j) Topic names must be significant enough -to be meaningful even when cited outside the -SWEBOK Guide. -k) The description of a KA will include a chart -(in tree form) describing the knowledge -breakdown. -``` -``` -CRITERIA AND REQUIREMENTS FOR -DESCRIBING TOPICS -``` -``` -Topics need only be sufficiently described so the -reader can select the appropriate reference mate- -rial according to his/her needs. Topic descrip- -tions must not be prescriptive. -``` -``` -CRITERIA AND REQUIREMENTS FOR -REFERENCE MATERIAL -``` -``` -a) KA Editors are instructed to use the refer- -ences (to the level of section number) allo- -cated to their KA by the Consolidated Refer- -ence List as their Recommended References. -b) There are three categories of reference -material: -``` -``` -» Recommended References. The set of -Recommended References (to the level -of section number) is collectively known -as the Consolidated Reference List. -» Further Readings. -» Additional references cited in the KA -Description (for example, the source -of a quotation or reference material in -support of a rationale behind a particular -argument). -``` - -``` -Appendix A A-3 -``` -c) The _SWEBOK Guide_ is intended by defini- -tion to be selective in its choice of topics -and associated reference material. The list of -reference material should be clearly viewed -as an “informed and reasonable selection” -rather than as a definitive list. -d) Reference material can be book chapters, -refereed journal papers, refereed confer- -ence papers, refereed technical or industrial -reports, or any other type of recognized arti- -fact. References to another KA, subarea, or -topic are also permitted. -e) Reference material must be generally avail- -able and must not be confidential in nature. -f) Reference material must be in English. -g) Criteria and requirements for recommended -reference material or Consolidated Refer- -ence List: - -``` -» Collectively the list of Recommended -References should be -``` -``` -i. complete: covering the entire -scope of the SWEBOK Guide -ii. sufficient: providing enough -information to describe “gener- -ally accepted” knowledge -iii. consistent: not providing contra- -dictory knowledge nor conflict- -ing practices -iv. credible: recognized as providing -expert treatment -v. current: treating the subject in -a manner that is commensurate -with currently generally accepted -knowledge -vi. succinct: as short as possible -(both in number of reference -items and in total page count) -without failing other objectives. -``` -``` -» Recommended reference material must -be identified for each topic. Each recom- -mended reference item may of course -cover multiple topics. Exceptionally, a -topic may be self-descriptive and not cite -a reference material item (for example, a -topic that is a definition or a topic for -which the description itself without any -``` -``` -cited reference material is sufficient for -the objectives of the SWEBOK Guide ). -» Each reference to the recommended -reference material should be as precise -as possible by identifying what specific -chapter or section is relevant. -» A matrix of reference material (to the -level of section number) versus topics -must be provided. -» A reasonable amount of recommended -reference material must be identified -for each KA. The following guidelines -should be used in determining how -much is reasonable: -``` -``` -i. If the recommended reference -material were written in a coher- -ent manner that followed the pro- -posed breakdown of topics and in -a uniform style (for example, in a -new book based on the proposed -KA description), an average tar- -get across all KAs for the number -of pages would be 750. However, -this target may not be attainable -when selecting existing reference -material due to differences in -style and overlap and redundancy -between the selected reference -materials. -ii. In other words, the target for the -number of pages for the entire -collection of recommended refer- -ences of the SWEBOK Guide is -in the range of 10,000 to 15,000 -pages. -iii. Another way of viewing this is -that the amount of recommended -reference material would be -reasonable if it consisted of the -study material on this KA for a -software engineering licensing -exam that a graduate would pass -after completing four years of -work experience. -``` -``` -h) Additional reference material can be -included by the KA Editor in a “Further -Readings” list: -``` - -**A-4** **_SWEBOK® Guide_** **V3.0** - -``` -» These further readings must be related to -the topics in the breakdown rather than, -for example, to more advanced topics. -» The list must be annotated (within 1 -paragraph per reference) as to why this -reference material was included in the -list of further readings. Further readings -could include: new versions of an exist- -ing reference already included in the -recommended references, alternative -viewpoints on a KA, or a seminal treat- -ment of a KA. -» A general guideline to be followed is 10 -or fewer further readings per KA. -» There is no matrix of the reference -materials listed in further readings and -the breakdown of topics. -``` -``` -i) Criteria and requirements regarding addi- -tional references cited in the KA Description: -``` -``` -» The SWEBOK Guide is not a research -document and its readership will be var- -ied. Therefore, a delicate balance must -be maintained between ensuring a high -level of readability within the document -while maintaining its technical excel- -lence. Additional reference material -should therefore only be brought in by -the KA Editor if it is necessary to the -discussion. Examples are to identify the -source of a quotation or to cite reference -item in support of a rationale behind a -particular and important argument. -``` -**COMMON STRUCTURE** - -KA descriptions should use the following structure: - -- Acronyms -- Introduction -- Breakdown of Topics of the KA (including a - figure describing the breakdown) -- Matrix of Topics vs. Reference Material -- List of Further Readings -- References - -##### WHAT DO WE MEAN BY “GENERALLY - -##### RECOGNIZED KNOWLEDGE”? - -``` -The Software Engineering Body of Knowledge -is an all-inclusive term that describes the sum -of knowledge within the profession of software -engineering. However, the SWEBOK Guide seeks -to identify and describe that subset of the body -of knowledge that is generally recognized or, in -other words, the core body of knowledge. To bet- -ter illustrate what “generally recognized” knowl- -edge is relative to other types of knowledge, -Figure A.1 proposes a three-category schema for -classifying knowledge. -The Project Management Institute in its Guide -to the Project Management Body of Knowledge -defines “generally recognized” knowledge for -project management as being: -``` -``` -that subset of the project management -body of knowledge generally recognized -as good practice. “Generally recognized” -means the knowledge and practices -described are applicable to most projects -most of the time, and there is consensus -about their value and usefulness. “Good -practice” means there is general agreement -that the application of these skills, tools, -and techniques can enhance the chances -of success over a wide range of projects. -“Good practice” does not mean that the -knowledge described should always be -applied uniformly to all projects; the orga- -nization and/or project management team -is responsible for determining what is -appropriate for any given project. [1] -``` -``` -“Generally accepted” knowledge could also be -viewed as knowledge to be included in the study -material of a software engineering licensing exam -(in the USA) that a graduate would take after -completing four years of work experience. These -two definitions should be seen as complementary. -KA Editors are also expected to be somewhat -forward looking in their interpretation by tak- -ing into consideration not only what is “gener- -ally recognized” today and but what they expect -will be “generally recognized” in a 3- to 5-year -timeframe. -``` - -``` -Appendix A A-5 -``` -``` -Specialized -``` -``` -Practices Used Only for -Certain Types of Software -``` -``` -Generally Recognized -Established traditional prac- -tices recommended by many -organizations -Advanced and Research -Innovative practices tested -and used only by some orga- -nizations and concepts still -being developed and tested in -research organizations -``` -``` -Figure A.1. Categories of Knowledge -``` -##### LENGTH OF KA DESCRIPTION - -KA Descriptions are to be roughly 10 to 20 pages -using the formatting template for papers pub- -lished in conference proceedings of the IEEE -Computer Society. This includes text, references, -appendices, tables, etc. This, of course, does not -include the reference materials themselves. - -**IMPORTANT RELATED DOCUMENTS** - -1. _Graduate Software Engineering 2009_ - _(GSwE2009): Curriculum Guidelines for_ - _Graduate Degree Programs in Software_ - _Engineering_ , 2009; [http://www.gswe2009.org.](http://www.gswe2009.org.) [2] - -This document “provides guidelines and rec- -ommendations” for defining the curricula of a -professional master’s level program in software -engineering. The _SWEBOK Guide_ is identified -as a “primary reference” in developing the body -of knowledge underlying these guidelines. This -document has been officially endorsed by the -IEEE Computer Society and sponsored by the -Association for Computing Machinery. - -2. _IEEE Std. 12207-2008 (a.k.a. ISO/IEC_ - _12207:2008) Standard for Systems and_ - _Software Engineering—Software Life Cycle_ - _Processes_ , IEEE, 2008 [3]. - -This standard is considered the key standard -regarding the definition of life cycle processes and -has been adopted by the two main standardization -bodies in software engineering: ISO/IEC JTC1/ -SC7 and the IEEE Computer Society Software - -``` -and Systems Engineering Standards Committees. -It also has been designated as a pivotal standard -by the Software and System Engineering Stan- -dards Committee (S2ESC) of the IEEE. -Even though we do not intend that the Guide to -the Software Engineering Body of Knowledge be -fully 12207-conformant, this standard remains a -key input to the SWEBOK Guide , and special care -will be taken throughout the SWEBOK Guide -regarding the compatibility of the Guide with the -12207 standard. -``` -3. J.W. Moore, _The Road Map to Software_ - _Engineering: A Standards-Based Guide_ , - Wiley-IEEE Computer Society Press, 2006. - [4*] - -``` -This book describes the scope, roles, uses, and -development trends of the most widely used soft- -ware engineering standards. It concentrates on -important software engineering activities—qual- -ity and project management, system engineer- -ing, dependability, and safety. The analysis and -regrouping of the standard collections exposes -the reader to key relationships between standards. -Even though the SWEBOK Guide is not a soft- -ware engineering standard per se, special care -will be taken throughout the document regarding -the compatibility of the Guide with the current -IEEE and ISO/IEC Systems and Software Engi- -neering Standards Collection. -``` -4. _Software Engineering 2004: Curriculum_ - _Guidelines for Undergraduate Degree_ - _Programs in Software Engineering_ , IEEE - Computer Society and Association for - Computing Machinery, 2004; [http://sites.](http://sites.) - computer.org/ccse/SE2004Volume.pdf. [5] - -``` -This document describes curriculum guidelines -for an undergraduate degree in software engineer- -ing. The SWEBOK Guide is identified as being -“one of the primary sources” in developing the -body of knowledge underlying these guidelines. -``` -5. _ISO/IEC/IEEE 24765:2010 Systems and_ - _Software Engineering—Vocabulary_ , ISO/ - IEC/IEEE, 2010; [http://www.computer.org/](http://www.computer.org/) - sevocab. [6] - - -**A-6** **_SWEBOK® Guide_** **V3.0** - -The hierarchy of references for terminology is -_Merriam Webster’s Collegiate Dictionary_ (11th -ed.) [7], IEEE/ISO/IEC 24765 [6], and new pro- -posed definitions if required. - -6. “Certification and Training for Software - Professionals,” IEEE Computer Society, - 2013; [http://www.computer.org/certification.](http://www.computer.org/certification.) [8] - -Information on the certification and associated -professional development products developed -and offered by the IEEE Computer Society for -professionals in the field of software engineer- -ing can be found on this website. The _SWEBOK -Guide_ is foundational to these products. - -**STYLE AND TECHNICAL GUIDELINES** - -- KA Descriptions should conform to the - Word template available at [http://www.computer.](http://www.computer.) - org/portal/web/cscps/formatting. -- KA Descriptions are expected to follow the - IEEE Computer Society Style Guide (www. - computer.org/portal/web/publications/ - styleguide). -- Files are to be submitted in Microsoft Word - format. -- All citations of reference material are to be - produced using EndNote Web as indicated - in the instructions provided to KA Editors in - this regard. - -**OTHER DETAILED GUIDELINES** - -When referencing the _Guide to the Software -Engineering Body of Knowledge_ , use the title -“ _SWEBOK Guide._ ” -For the purpose of simplicity, avoid footnotes -and try to include their content in the main text. -Use explicit references to standards, as opposed -to simply inserting numbers referencing items in - -``` -the bibliography. We believe this approach allows -the reader to be better exposed to the source and -scope of a standard. -The text accompanying figures and tables -should be self-explanatory or have enough related -text. This would ensure that the reader knows -what the figures and tables mean. -To make sure that some information in the -SWEBOK Guide does not become rapidly obso- -lete and due to its generic nature, please avoid -directly naming tools and products. Instead, try -to name their functions. -``` -``` -EDITING -``` -``` -Editors of the SWEBOK Guide as well as profes- -sional copy editors will edit KA Descriptions. -Editing includes copy editing (grammar, punc- -tuation, and capitalization), style editing (confor- -mance to the Computer Society style guide), and -content editing (flow, meaning, clarity, direct- -ness, and organization). The final editing will -be a collaborative process in which the Editors -of the SWEBOK Guide and the KA Editors work -together to achieve a concise, well-worded, and -useful KA Description. -``` -``` -RELEASE OF COPYRIGHT -``` -``` -All intellectual property rights associated with -the SWEBOK Guide will remain with the IEEE. -KA Editors must sign a copyright release form. -It is also understood that the SWEBOK Guide -will continue to be available free of charge in the -public domain in at least one format, provided by -the IEEE Computer Society through web technol- -ogy or by other means. -For more information, see http://www.computer.org/ -copyright.htm. -``` - -``` -Appendix A A-7 -``` -##### REFERENCES - -[1] Project Management Institute, _A Guide to the -Project Management Body of Knowledge -(PMBOK(R) Guide)_ , 5th ed., Project -Management Institute, 2013. - -[2] Integrated Software and Systems -Engineering Curriculum (iSSEc) Project, -_Graduate Software Engineering 2009 -(GSwE2009): Curriculum Guidelines -for Graduate Degree Programs in -Software Engineering_ , Stevens Institute of -Technology, 2009; [http://www.gswe2009.org.](http://www.gswe2009.org.) - -[3] _IEEE Std. 12207-2008 (a.k.a. ISO/IEC -12207:2008) Standard for Systems and -Software Engineering—Software Life Cycle -Processes, IEEE, 2008._ - -[4*] J.W. Moore, _The Road Map to Software -Engineering: A Standards-Based Guide_ , -Wiley-IEEE Computer Society Press, 2006. - -``` -[5] Joint Task Force on Computing Curricula, -IEEE Computer Society and Association -for Computing Machinery, Software -Engineering 2004: Curriculum Guidelines -for Undergraduate Degree Programs in -Software Engineering , 2004; http://sites. -computer.org/ccse/SE2004Volume.pdf. -``` -``` -[6] ISO/IEC/IEEE 24765:2010 Systems and -Software Engineering—Vocabulary , ISO/ -IEC/IEEE, 2010. -``` -``` -[7] Merriam-Webster’s Collegiate Dictionary , -11th ed., 2003. -``` -``` -[8] IEEE Computer Society, “Certification and -Training for Software Professionals,” 2013; -http://www.computer.org/certification. -``` - -``` -B-1 -``` -**APPENDIX B** - -**IEEE AND ISO/IEC STANDARDS SUPPORTING** - -**THE SOFTWARE ENGINEERING BODY OF** - -**KNOWLEDGE (SWEBOK)** - -Some might say that the supply of software engi- -neering standards far exceeds the demand. One -seldom listens to a briefing on the subject without -suffering some apparently obligatory joke that -there are too many of them. However, the exis- -tence of standards takes a very large (possibly -infinite) trade space of alternatives and reduces -that space to a smaller set of choices—a huge -advantage for users. Nevertheless, it can still be -difficult to choose from dozens of alternatives, so -supplementary guidance, like this appendix, can -be helpful. A summary list of the standards men- -tioned in this appendix appears at the end. -To reduce tedium in reading, a few simplifica- -tions and abridgements are made in this appendix: - -- ISO/IEC JTC 1/SC 7 maintains nearly two - hundred standards on the subject. IEEE - maintains about fifty. The two organizations - are in the tenth year of a systematic program - to coordinate and integrate their collections. - In general, this article will focus on the stan- - dards that are recognized by both organiza- - tions, taking this condition as evidence that - wide agreement has been obtained. Other - standards will be mentioned briefly. -- Standards tend to have long, taxonomical - titles. If there were a single standard for - building an automobile, the one for your - Camry probably would be titled something - like, “Vehicle, internal combustion, four- - wheel, passenger, sedan.” Also, modern stan- - dards organizations provide their standards - from databases. Like any database, these - sometimes contain errors, particularly for the - titles. So this article will often paraphrase the - -``` -title of the standard or simply use its number. -In obtaining a standard of interest, the reader -should rely on the number, not the title, given -in this article. For reasons of consistency, the -article will use the IEEE’s convention for the -capitalization of titles—nouns, pronouns, -adjectives, verbs, adverbs, and first and last -words have an initial capital letter—despite -the fact that IEEE and ISO/IEC use differing -conventions. -``` -- Because these standards are being continu- - ally revised to take account of new technolo- - gies and usage patterns, this article will be - obsolescent before it is published. Therefore, - it will occasionally discuss standards that - have not yet been published, if they are likely - to assume significant importance. -- Explicit trademarks are omitted. Suffice it to - say that IEEE places a trademark on all of its - standards’ designations. - -``` -There are some other conventions of interest: -``` -- In both IEEE and ISO/IEC, standards for - _systems_ engineering are maintained by the - same committee as those for _software_ engi- - neering. Many of the standards apply to both. - So, instead of making fine distinctions, this - article will deal with both. -- On the other hand, both S2ESC and SC 7 - (see below for descriptions of these orga- - nizations) are responsible for standards - that don’t qualify as “engineering.” In the - US and many other countries, the services - of a licensed engineer are required when a - product might affect public safety, health, - - -**B-2** **_SWEBOK® Guide_** **V3.0** - -``` -and welfare as opposed to affecting merely -the pocketbook of the client. This appendix -will respect that distinction and ignore stan- -dards that appear to be merely economic in -consequence. -``` -- User documentation is assumed to be devel- - oped similarly to software. For example, - a standard concerning the design of user - documentation is described in the Software - Design KA. -- Some jointly developed standards are explic- - itly labeled as joint developments, e.g., ISO/ - IEC/IEEE 24765. In other cases, the stan- - dards have different designations in the two - organizations. Examples include - -``` -» IEEE Std. 12207:2008 (a.k.a. ISO/IEC -12207:2008), where “a.k.a.” (“also -known as”) is this appendix’s abbrevia- -tion to note the designation in the other -organization; -» IEEE Std. 15939:2008 Standard Adop- -tion of ISO/IEC 15939:2007, an adop- -tion by IEEE of a standard developed in -ISO/IEC; -» IEEE Std. 1220:2005 (a.k.a. ISO/IEC -26702:2007), a “fast-track” by ISO/IEC -of a standard developed in IEEE. -``` -``` -In each of these cases, the standards are -substantively identical in the two orga- -nizations, differing only in front matter -and, occasionally, added informational -material. -``` -A summary list of all of the mentioned stan- -dards is provided at the end of this appendix. - -**ISO/IEC JTC 1/SC 7, SOFTWARE AND -SYSTEMS ENGINEERING** - -ISO/IEC JTC 1/SC 7 is the major source of -international standards on software and systems -engineering. Its name is formed taxonomically. -Joint Technical Committee 1 (JTC 1) is a child -of the International Organization for Standardiza- -tion (ISO) and the International Electrotechnical -Commission (IEC); it has the scope of “informa- -tion technology” and subdivides its work among -a number of subcommittees; Subcommittee 7 (SC - -``` -7) is the one responsible for software and sys- -tems engineering. SC 7, and its working groups, -meets twice a year, attracting delegations repre- -senting the national standards bodies of partici- -pating nations. Each nation follows its own pro- -cedures for determining national positions and -each nation has the responsibility of determining -whether an ISO/IEC standard should be adopted -as a national standard. -SC 7 creates three types of documents: -``` -- International Standards: Documents contain- - ing requirements that must be satisfied in - order to claim conformance. -- Technical Specifications (formerly called - Technical Reports, type 1 and type 2): Docu- - ments published in a preliminary manner - while work continues. -- Technical Reports (formerly called Techni- - cal Reports, type 3): Documents inherently - unsuited to be standards, usually because - they are descriptive rather than prescriptive. - -``` -The key thing to remember is that only the -first category counts as a consensus standard. -The reader can easily recognize the others by the -suffix TS or TR prepended to the number of the -document. -``` -``` -IEEE SOFTWARE AND SYSTEMS -ENGINEERING STANDARDS -COMMITTEE (S2ESC) -``` -``` -IEEE is the world’s largest organization of tech- -nical professionals, with about 400,000 members -in more than 160 countries. The publication of -standards is performed by the IEEE Standards -Association (IEEE-SA), but the committees that -draft and sponsor the standards are in the various -IEEE societies; S2ESC is a part of the IEEE Com- -puter Society. IEEE is a global standards maker -because its standards are used in many differ- -ent countries. Despite its international member- -ship (about 50% non-US), though, the IEEE-SA -routinely submits its standards to the American -National Standards Institute (ANSI) for endorse- -ment as “American National Standards.” Some -S2ESC standards are developed within S2ESC, -some are developed jointly with SC 7, and some -are adopted after being developed by SC 7. -``` - -``` -Appendix B B-3 -``` -``` -IEEE-SA publishes three types of “standards”: -``` -- Standards, with a preponderance of the verb - “shall” -- Recommended Practices, with a preponder- - ance of the verb “should” -- Guides, with a preponderance of the verb - “may.” - -All three of these compare to ISO/IEC stan- -dards. IEEE-SA does have the concept of a “Trial- -Use” standard, which is roughly comparable to -an ISO/IEC Technical Specification. However, it -has nothing comparable to an ISO/IEC Techni- -cal Report; one would look elsewhere in IEEE for -documents of this ilk. - -**THE STANDARDS** - -The remainder of this article allocates the selected -standards to relevant knowledge areas (KAs) of -the _SWEBOK Guide_. There is a section for each -KA. Within each section, the relevant standards -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- -rent one. Following each standard is a brief sum- -mary. In most cases, the summary is a quotation -or paraphrase of the abstract or other introductory -material from the text of the standard. -Most of the standards easily fit into one KA. -Some fit into more than one; in such cases, -a cross-reference is provided. Two standards -apply to all KAs, so they are listed in a category -called “General.” All of the standards related to -computer-aided software engineering (CASE) -tools and environments are listed in the Software -Engineering Models and Methods KA section. - -**GENERAL** - -The first two standards are so central that they -could be slotted into all of the KAs. Two more are -described in the Software Engineering Process -KA, but are mentioned here because they provide -a helpful framework and because the descriptions -of several other standards refer to them. -ISO/IEC TR 19759 is the _SWEBOK Guide_ -itself. It’s not an IEEE standard because, lacking -prescriptive verbs, it doesn’t satisfy the criteria - -``` -for any of the IEEE categories. In ISO/IEC, it is a -“technical report”—defined as a document inher- -ently unsuited to be a standard. The 2004 IEEE -SWEBOK Guide was adopted by ISO/IEC with- -out change. Presumably, ISO/IEC will adopt Ver- -sion 3 of the SWEBOK Guide. -``` -``` -ISO/IEC TR 19759:2005 Software Engineering— -Guide to the Software Engineering Body of Knowledge -(SWEBOK) -Applies to all KAs -``` -``` -ISO/IEC 19759:2005, a Guide to the Software -Engineering Body of Knowledge (SWEBOK) , -identifies and describes that subset of the body -of knowledge that is generally accepted, even -though software engineers must be knowledge- -able not only in software engineering, but also, -of course, in other related disciplines. SWEBOK -is an all-inclusive term that describes the sum -of knowledge within the profession of software -engineering. -``` -``` -The text of the SWEBOK Guide is freely avail- -able at http://www.swebok.org/. The ISO/IEC adoption -of the Guide is freely available at http://standards. -iso.org/ittf/PubliclyAvailableStandards/index. -html. -ISO/IEC/IEEE 24765 provides a shared vocab- -ulary for the systems and software engineering -standards of both SC 7 and S2ESC. -``` -``` -ISO/IEC/IEEE 24765:2010 Systems and Software -Engineering—Vocabulary -Applies to all KAs -``` -``` -ISO/IEC/IEEE 24765:2010 provides a common -vocabulary applicable to all systems and software -engineering work. It was prepared to collect and -support the standardization of terminology. ISO/ -IEC/IEEE 24765:2010 is intended to serve as a -useful reference for those in the information tech- -nology field and to encourage the use of systems -and software engineering standards prepared by -ISO and liaison organizations IEEE Computer -Society and Project Management Institute. ISO/ -IEC/IEEE 24765:2010 includes references to the -``` - -**B-4** **_SWEBOK® Guide_** **V3.0** - -active source standards for each definition so that -the use of the term can be further explored. - -The vocabulary is descriptive, rather than pre- -scriptive; it gathers up all of the definitions from -all of the relevant standards, as well as a few -other sources, rather than choosing among com- -peting definitions. -The content of the 24765 standard is freely -accessible online at [http://www.computer.org/sevocab.](http://www.computer.org/sevocab.) -Two standards, 12207 and 15288, provide a -complete set of processes for the entire life cycle -of a system or a software product. The two stan- -dards are aligned for concurrent use on a single -project or in a single organization. They are -mentioned here because they are often used as a -framework for explaining or localizing the role of -other standards in the life cycle. - -**IEEE Std. 12207-2008 (a.k.a. ISO/IEC 12207:2008) -Standard for Systems and Software Engineering— -Software Life Cycle Processes** -See Software Engineering Process KA - -**IEEE Std. 15288-2008 (a.k.a. ISO/IEC 15288:2008) -Standard for Systems and** **_S_** **oftware Engineering— -System Life Cycle Processes** -See Software Engineering Process KA - -##### SOFTWARE REQUIREMENTS - -The primary standard for software and systems -requirements engineering is a new one that -replaced several existing IEEE standards. It pro- -vides a broad view of requirements engineering -across the entire life cycle. - -**ISO/IEC/IEEE 29148:2011 Systems and Software -Engineering—Life Cycle Processes—Requirements -Engineering** - -ISO/IEC/IEEE 29148:2011 contains provisions -for the processes and products related to the engi- -neering of requirements for systems and software -products and services throughout the life cycle. - -``` -It defines the construct of a good requirement, -provides attributes and characteristics of require- -ments, and discusses the iterative and recursive -application of requirements processes through- -out the life cycle. ISO/IEC/IEEE 29148:2011 -provides additional guidance in the application -of requirements engineering and management -processes for requirements-related activities in -ISO/IEC 12207:2008 and ISO/IEC 15288:2008. -Information items applicable to the engineering -of requirements and their content are defined. -The content of ISO/IEC/IEEE 29148:2011 can -be added to the existing set of requirements- -related life cycle processes defined by ISO/IEC -12207:2008 or ISO/IEC 15288:2008, or it can be -used independently. -``` -``` -A multipart ISO/IEC standard provides princi- -ples and methods for “sizing” software based on -its requirements. The functional size is often use- -ful in the denominator of measurements of qual- -ity and productivity in software development. It -may also play a role in contracting for service- -level agreements. -``` -``` -ISO/IEC 14143 [six parts] Information Technol- -ogy—Software Measurement—Functional Size -Measurement -``` -``` -ISO/IEC 14143 describes FSM (functional size -measurement). The concepts of functional size -measurement (FSM) are designed to overcome the -limitations of earlier methods of sizing software by -shifting the focus away from measuring how the -software is implemented to measuring size in terms -of the functions required by the user. -``` -``` -FSM is often known as “function point count- -ing.” The four standards listed below are alter- -native methods for function point counting—all -meet the requirements of ISO/IEC 14143. The -dominant method, in terms of market share, is -the IFPUG method, described in ISO/IEC 20926. -Other methods are variations intended to improve -the validity of the count in various circumstances. -For example, ISO/IEC 19761 — COSMIC is -``` - -``` -Appendix B B-5 -``` -notably intended to be used on software with a -real-time component. - -**ISO/IEC 19761:2011 Software Engineering—COS- -MIC: A Functional Size Measurement Method** - -**ISO/IEC 20926:2009 Software and Systems Engi- -neering—Software Measurement—IFPUG Func- -tional Size Measurement Method** - -**ISO/IEC 20968:2002 Software Engineering—Mk -II Function Point Analysis—Counting Practices -Manual** - -**ISO/IEC 24570:2005 Software Engineering— -NESMA Functional Size Measurement Method Ver- -sion 2.1—Definitions and Counting Guidelines for -the Application of Function Point Analysis** - -Sometimes requirements are described in natu- -ral language, but sometimes they are described -in formal or semiformal notations. The objective -of the Unified Modeling Language (UML) is to -provide system architects, software engineers, -and software developers with tools for analysis, -design, and implementation of software-based -systems as well as for modeling business and -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 -are mentioned here because they are often used to -model requirements. - -**ISO/IEC 19501:2005 Information Technology** **_—_** -**Open Distributed Processing** **_—_** **Unified Modeling -Language (UML) Version 1.4.2** -See Software Engineering Models and -Methods KA - -**ISO/IEC 19505:2012 [two parts] Information Tech- -nology** **_—_** **Object Management Group Unified Model- -ing Language (OMG UML)** -See Software Engineering Models and -Methods KA - -##### SOFTWARE DESIGN - -``` -The software design KA includes both software -architectural design (for determining the relation- -ships among the items of the software and detailed -design (for describing the individual items). ISO/ -IEC/IEEE 42010 concerns the description of -architecture for systems and software. -``` -``` -ISO/IEC/IEEE 42010:2011 Systems and Software -Engineering — Architecture Description -``` -``` -ISO/IEC/IEEE 42010:2011 addresses the cre- -ation, analysis, and sustainment of architec- -tures of systems through the use of architecture -descriptions. A conceptual model of architecture -description is established. The required contents -of an architecture description are specified. Archi- -tecture viewpoints, architecture frameworks and -architecture description languages are introduced -for codifying conventions and common practices -of architecture description. The required content -of architecture viewpoints, architecture frame- -works and architecture description languages -is specified. Annexes provide the motivation -and background for key concepts and terminol- -ogy and examples of applying ISO/IEC/IEEE -42010:2011. -``` -``` -Like ISO/IEC/IEEE 42010, the next stan- -dard treats software “design” as an abstraction, -independent of its representation in a document. -Accordingly, the standard places provisions on -the description of design, rather than on design -itself. -``` -``` -IEEE Std. 1016-2009 Standard for Information -Technology — Systems Design — Software Design -Descriptions -``` -``` -This standard describes software designs and -establishes the information content and organiza- -tion of a software design description (SDD). An -SDD is a representation of a software design to be -used for recording design information and com- -municating that design information to key design -``` - -**B-6** **_SWEBOK® Guide_** **V3.0** - -stakeholders. This standard is intended for use in -design situations in which an explicit software -design description is to be prepared. These situ- -ations include traditional software construction -activities (when design leads to code) and reverse -engineering situations (when a design description -is recovered from an existing implementation). -This standard can be applied to commercial, sci- -entific, or military software that runs on digital -computers. Applicability is not restricted by the -size, complexity, or criticality of the software. -This standard can be applied to the description -of high-level and detailed designs. This stan- -dard does not prescribe specific methodologies -for design, configuration management, or qual- -ity assurance. This standard does not require the -use of any particular design languages, but estab- -lishes requirements on the selection of design -languages for use in an SDD. This standard can -be applied to the preparation of SDDs captured as -paper documents, automated databases, software -development tools, or other media. - -By convention, this appendix treats user docu- -mentation as a part of a software system. There- -fore, the various aspects of user documentation— -its design, its testing, and so forth—are allocated -to different KAs. The next standard deals with the -design of user documentation. - -**IEEE Std. 26514-2010 Standard Adoption of ISO/ -IEC 26514:2008 Systems and Software Engineer- -ing** **_—_** **Requirements for Designers and Developers of -User Documentation** - -This standard provides requirements for the -design and development of software user docu- -mentation as part of the life cycle processes. It -defines the documentation process from the view- -point of the documentation developer and also -covers the documentation product. It specifies the -structure, content, and format for user documen- -tation and also provides informative guidance for -user documentation style. It is independent of the -software tools that may be used to produce docu- -mentation and applies to both printed documenta- -tion and onscreen documentation. Much of this - -``` -standard is also applicable to user documentation -for systems including hardware. -``` -##### SOFTWARE CONSTRUCTION - -``` -The term “software construction” refers to the -detailed creation of working, meaningful software -through a combination of coding, verification, -unit testing, integration testing, and debugging. -There are few standards on the details of soft- -ware coding. It has been found through (mostly -bad) experience that coding conventions are not -appropriate for standardization because, in most -cases, the real benefit comes from the consis- -tency of applying an arbitrary convention rather -than the convention itself. So, although coding -conventions are a good idea, it is generally left -to the organization or the project to develop such -a standard. -Nevertheless, the subject of secure coding has -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/ -SC 22 (programming languages) describes vul- -nerabilities in programming languages and how -they can be avoided. -``` -``` -ISO/IEC TR 24772:2013 Information Technology — -Programming Languages — Guidance to Avoiding -Vulnerabilities in Programming Languages through -Language Selection and Use -``` -``` -ISO/IEC TR 24772:2013 specifies software pro- -gramming language vulnerabilities to be avoided -in the development of systems where assured -behavior is required for security, safety, mis- -sion-critical, and business-critical software. In -general, this guidance is applicable to the soft- -ware developed, reviewed, or maintained for any -application. -Vulnerabilities are described in a generic man- -ner that is applicable to a broad range of pro- -gramming languages. Annexes relate the generic -guidance to a selection of specific programming -languages. -``` - -``` -Appendix B B-7 -``` -The Technical Report is freely available at [http://](http://) -standards.iso.org/ittf/PubliclyAvailableStandards/ -index.html. -Two standards are mentioned here because unit -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, -29119, that will provide a comprehensive treat- -ment of testing and supplant IEEE Std. 1008. - -**IEEE Std. 1008-1987 Standard for Software Unit -Testing** -See Software Testing KA - -**ISO/IEC/IEEE 29119 [four parts] (Draft) Software -and Systems Engineering** **_—_** **Software Testing** -See Software Testing KA - -The next standard provides for the development -of user documentation during an agile devel- -opment process. It is mentioned here because -agile development is sometimes regarded as -construction. - -**ISO/IEC/IEEE 26515:2012 Systems and Software -Engineering** **_—_** **Developing User Documentation in an -Agile Environment** -See Software Engineering Models and -Methods KA - -Coding is not the only way to create a software -product. Often code (as well as requirements and -design) is reused from previous projects or engi- -neered for reuse in future projects. IEEE Std. 1517 -is mentioned here because it provides a common -framework for extending the system and software -life cycle processes of IEEE Std. 12207:2008 to -include the systematic practice of reuse. - -**IEEE Std. 1517-2010 Standard for Information -Technology** **_—_** **System and Software Life Cycle Pro- -cesses** **_—_** **Reuse Processes** -See Software Engineering Process KA - -##### SOFTWARE TESTING - -``` -Oddly, there are few standards for testing. IEEE -Std. 829 is the most comprehensive. -``` -``` -IEEE Std. 829-2008 Standard for Software and Sys- -tem Test Documentation -``` -``` -Test processes determine whether the develop- -ment products of a given activity conform to the -requirements of that activity and whether the sys- -tem and/or software satisfies its intended use and -user needs. Testing process tasks are specified -for different integrity levels. These process tasks -determine the appropriate breadth and depth of -test documentation. The documentation elements -for each type of test documentation can then be -selected. The scope of testing encompasses soft- -ware-based systems, computer software, hard- -ware, and their interfaces. This standard applies -to software-based systems being developed, -maintained, or reused (legacy, commercial off- -the-shelf, nondevelopmental items). The term -“software” also includes firmware, microcode, -and documentation. Test processes can include -inspection, analysis, demonstration, verification, -and validation of software and software-based -system products. -``` -``` -IEEE Std. 1008 focuses on unit testing. -``` -``` -IEEE Std. 1008 - 1987 Standard for Software Unit -Testing -``` -``` -The primary objective is to specify a standard -approach to software unit testing that can be -used as a basis for sound software engineer- -ing practice. A second objective is to describe -the software engineering concepts and testing -assumptions on which the standard approach is -based. A third objective is to provide guidance -and resource information to assist with the imple- -mentation and usage of the standard unit testing -approach. -``` - -**B-8** **_SWEBOK® Guide_** **V3.0** - -IEEE and ISO/IEC JTC 1/SC 7 are cooperating -in a project to develop a single comprehensive -standard that covers all aspects of testing. One -can hope for publication of the four-part standard -by 2014. Portions of the content remain contro- -versial. One taxonomical issue is whether “static -methods”—such as inspection, review, and static -analysis—should fall within the scope of “test- -ing” or should be distinguished as “verification -and validation.” Although the resolution of the -issue is probably of little importance to users of -the standard, it assumes great importance to the -standards-writers who must manage an integrated -suite of interoperating standards. - -**ISO/IEC/IEEE 29119 [four parts] (Draft) Software -and Systems Engineering** **_—_** **Software Testing** - -The purpose of ISO/IEC 29119 Software Testing -is to define an internationally agreed standard for -software testing that can be used by any orga- -nization when performing any form of software -testing. - -Testing of user documentation is described in -the next standard, providing requirements for the -test and review of software user documentation -as part of the life cycle processes. It defines the -documentation process from the viewpoint of the -documentation tester and reviewer. It is relevant -to roles involved in testing and development of -software and user documentation, including proj- -ect managers, usability experts, and information -developers in addition to testers and reviewers. - -**IEEE Std. 26513-2010 Standard Adoption of ISO/ -IEC 26513:2009 Systems and Software Engineer- -ing** **_—_** **Requirements for Testers and Reviewers of -Documentation** - -ISO/IEC 26513 provides the minimum require- -ments for the testing and reviewing of user docu- -mentation, including both printed and onscreen -documents used in the work environment by the -users of systems software. It applies to printed -user manuals, online help, tutorials, and user ref- -erence documentation. - -``` -It specifies processes for use in testing and -reviewing of user documentation. It is not lim- -ited to the test and review phase of the life cycle, -but includes activities throughout the information -management and documentation management -processes. -``` -``` -Two standards are mentioned here because -some sources consider software verification and -validation to be taxonomically included in testing. -``` -``` -IEEE Std. 1012-2012 Standard for System and Soft- -ware Verification and Validation -See Software Quality KA -``` -``` -IEEE Std. 1044-2009 Standard for Classification for -Software Anomalies -See Software Quality KA -``` -##### SOFTWARE MAINTENANCE - -``` -This standard—the result of harmonizing distinct -IEEE and ISO/IEC standards on the subject— -describes a single comprehensive process for the -management and execution of software mainte- -nance. It expands on the provisions of the soft- -ware maintenance process provided in ISO/IEC/ -IEEE 12207. -``` -``` -IEEE Std. 14764-2006 (a.k.a. ISO/IEC 14764:2006) -Standard for Software Engineering—Software Life -Cycle Processes—Maintenance -``` -``` -ISO/IEC 14764:2006 describes in greater -detail management of the maintenance process -described in ISO/IEC 12207, including amend- -ments. It also establishes definitions for the vari- -ous types of maintenance. ISO/IEC 14764:2006 -provides guidance that applies to planning, exe- -cution and control, review and evaluation, and -closure of the maintenance process. The scope of -ISO/IEC 14764:2006 includes maintenance for -multiple software products with the same main- -tenance resources. “Maintenance” in ISO/IEC -14764:2006 means software maintenance unless -otherwise stated. -``` - -``` -Appendix B B-9 -``` -ISO/IEC 14764:2006 provides the framework -within which generic and specific software main- -tenance plans may be executed, evaluated, and -tailored to the maintenance scope and magni- -tude of given software products. It provides the -framework, precise terminology, and processes -to allow the consistent application of technol- -ogy (tools, techniques, and methods) to software -maintenance. -It does not address the operation of software -and the operational functions, e.g., backup, -recovery, and system administration, which are -normally performed by those who operate the -software. -ISO/IEC 14764:2006 is written primarily for -maintainers of software and additionally for those -responsible for development and quality assur- -ance. It may also be used by acquirers and users -of systems containing software, who may provide -inputs to the maintenance plan. - -##### SOFTWARE CONFIGURATION - -##### MANAGEMENT - -There is one standard for configuration -management. - -**IEEE Std. 828-2012 Standard for Configuration -Management in Systems and Software Engineering** - -This standard establishes the minimum require- -ments for processes for configuration management -(CM) in systems and software engineering. The -application of this standard applies to any form, -class, or type of software or system. This revision -of the standard expands the previous version to -explain CM, including identifying and acquiring -configuration items, controlling changes, report- -ing the status of configuration items, as well as -software builds and release engineering. Its pre- -decessor defined only the contents of a software -configuration management plan. This standard -addresses what CM activities are to be done, when -they are to happen in the life cycle, and what plan- -ning and resources are required. It also describes -the content areas for a CM plan. The standard sup- -ports ISO/IEC/IEEE 12207:2008 and ISO/IEC/ -IEEE 15288:2008 and adheres to the terminology - -``` -in ISO/IEC/IEEE Std. 24765 and the information -item requirements of IEEE Std. 15939. -``` -``` -ISO/IEC JTC 1/SC 7 has not yet determined -what action it should take regarding the new -IEEE Std. 828. There are issues concerning the -extent of compatibility with ISO/IEC/IEEE -12207 and other standards in the SC 7 suite. It -should be noted, though, that SC 7 does not have -a competing standard. -``` -``` -SOFTWARE ENGINEERING -MANAGEMENT -``` -``` -Most readers will interpret the phrase “software -engineering management” to mean the manage- -ment of a project that concerns software. There -are at least two possible extensions to this gen- -eralization, though. Some software activities are -managed according to a service-level agreement -(SLA). SLAs do not meet the criteria for “proj- -ect” according to some definitions. Also, it has -become generally agreed that some management -of software should occur in the organization at a -level above the project, so that all projects can -benefit from a common investment. A commonly -cited example is the provision of software pro- -cesses and tooling by the organization. -Software project management can be regarded -as a specialization of “project management”— -often regarded as a distinct discipline. The Proj- -ect Management Institute’s Guide to the Project -Management Body of Knowledge (PMBOK ® -Guide) is often regarded as the authoritative -source for this knowledge. From time to time, -IEEE adopts the most recent version of the -PMBOK ® Guide as an IEEE standard. -``` -``` -IEEE Std. 1490-2011 Guide—Adoption of the Proj- -ect Management Institute (PMI®) Standard, A -Guide to the Project Management Body of Knowl- -edge (PMBOK® Guide)—Fourth Edition -``` -``` -The PMBOK® Guide identifies that subset of -the project management body of knowledge gen- -erally recognized as good practice. “Generally -recognized” means the knowledge and practices -described are applicable to most projects most of -``` - -**B-10** **_SWEBOK® Guide_** **V3.0** - -the time and there is consensus about their value and -usefulness. “Good practice” means there is general -agreement that the application of these skills, tools, -and techniques can enhance the chances of success -over a wide range of projects. Good practice does -not mean the knowledge described should always -be applied uniformly to all projects; the organiza- -tion and/or project management team is respon- -sible for determining what is appropriate for any -given project. The _PMBOK® Guide_ also provides -and promotes a common vocabulary within the -project management profession for discussing, -writing, and applying project management con- -cepts. Such a standard vocabulary is an essential -element of a professional discipline. The Project -Management Institute (PMI) views this standard -as a foundational project management reference -for its professional development programs and -certifications. - -The 2008 revisions of ISO/IEC/IEEE 12207 -and 15288 provide project management pro- -cesses for software and systems and relate them -to organization-level processes as well as tech- -nical processes. The jointly developed 16326 -standard, replacing two older standards, expands -those provisions with guidance for application. - -**ISO/IEC/IEEE 16326:2009 Systems and Soft- -ware Engineering—Life Cycle Processes—Project -Management** - -ISO/IEC/IEEE 16326:2009 provides normative -content specifications for project management -plans covering software projects and software- -intensive system projects. It also provides detailed -discussion and advice on applying a set of proj- -ect processes that are common to both the soft- -ware and system life cycle as covered by ISO/IEC -12207:2008 (IEEE Std. 12207-2008) and ISO/IEC -15288:2008 (IEEE Std. 15288-2008), respectively. -The discussion and advice are intended to aid in -the preparation of the normative content of project -management plans. ISO/IEC/IEEE 16326:2009 -is the result of the harmonization of ISO/IEC TR -16326:1999 and IEEE Std. 1058-1998. - -``` -Particularly in high-technology applications -and high-consequence projects, the management -of risk is an important aspect of the overall proj- -ect management responsibilities. This standard -deals with that subject. -``` -``` -IEEE Std. 16085-2006 (a.k.a. ISO/IEC 16085:2006) -Standard for Systems and Software Engineering— -Software Life Cycle Processes—Risk Management -``` -``` -ISO/IEC 16085:2006 defines a process for the -management of risk in the life cycle. It can be -added to the existing set of system and software -life cycle processes defined by ISO/IEC 15288 and -ISO/IEC 12207, or it can be used independently. -ISO/IEC 16085:2006 can be applied equally to -systems and software. -The purpose of risk management is to iden- -tify potential managerial and technical problems -before they occur so that actions can be taken that -reduce or eliminate the probability and/or impact -of these problems should they occur. It is a criti- -cal tool for continuously determining the feasi- -bility of project plans, for improving the search -for and identification of potential problems that -can affect life cycle activities and the quality and -performance of products, and for improving the -active management of projects. -``` -``` -The analysis of risk and risk mitigation depends -crucially upon measurement. This international -standard provides an elaboration of the measure- -ment process from ISO/IEC/IEEE 15288:2008 -and ISO/IEC/IEEE 12207:2008. -``` -``` -IEEE Std. 15939-2008 Standard Adoption of ISO/ -IEC 15939:2007 Systems and Software Engineer- -ing—Measurement Process -``` -``` -ISO/IEC 15939 defines a measurement process -applicable to system and software engineer- -ing and management disciplines. The process is -described through a model that defines the activi- -ties of the measurement process that are required -to adequately specify what measurement infor- -mation is required, how the measures and analy- -sis results are to be applied, and how to determine -``` - -``` -Appendix B B-11 -``` -if the analysis results are valid. The measurement -process is flexible, tailorable, and adaptable to the -needs of different users. -ISO/IEC 15939:2007 identifies a process that -supports defining a suitable set of measures that -address specific information needs. It identifies the -activities and tasks that are necessary to success- -fully identify, define, select, apply, and improve -measurement within an overall project or organi- -zational measurement structure. It also provides -definitions for measurement terms commonly used -within the system and software industries. - -Software projects often require the develop- -ment of user documentation. Management of the -project, therefore, includes management of the -documentation effort. - -**ISO/IEC/IEEE 26511:2012 Systems and Software -Engineering—Requirements for Managers of User -Documentation** - -ISO/IEC/IEEE 26511:2012 specifies procedures -for managing user documentation throughout the -software life cycle. It applies to people or orga- -nizations producing suites of documentation, to -those undertaking a single documentation project, -and to documentation produced internally, as well -as to documentation contracted to outside service -organizations. It provides an overview of the soft- -ware documentation and information management -processes, and also presents aspects of portfolio -planning and content management that user docu- -mentation managers apply. It covers management -activities in starting a project, including setting -up procedures and specifications, establishing -infrastructure, and building a team. It includes -examples of roles needed on a user documentation -team. It addresses measurements and estimates -needed for management control, and the use of -supporting processes such as change management, -schedule and cost control, resource management, -and quality management and process improve- -ment. It includes requirements for key documents -produced for user documentation management, -including documentation plans and documentation -management plans. ISO/IEC/IEEE 26511:2012 is -independent of the software tools that may be used - -``` -to produce or manage documentation, and applies -to both printed documentation and onscreen docu- -mentation. Much of its guidance is applicable to -user documentation for systems including hard- -ware as well as software. -``` -``` -Sometimes software or system components are -acquired rather than developed. -``` -``` -IEEE Std. 1062-1998 Recommended Practice for -Software Acquisition -``` -``` -A set of useful quality practices that can be -selected and applied during one or more steps in -a software acquisition process is described. This -recommended practice can be applied to software -that runs on any computer system regardless of -the size, complexity, or criticality of the software, -but is more suited for use on modified-off-the- -shelf software and fully developed software. -``` -``` -Sometimes user documentation is acquired -regardless of whether the software it describes -was acquired. The following standard deals with -that subject. -``` -``` -ISO/IEC/IEEE 26512:2011 Systems and Software -Engineering—Requirements for Acquirers and Sup- -pliers of User Documentation -``` -``` -ISO/IEC/IEEE 26512:2011 was developed to -assist users of ISO/IEC/IEEE 15288:2008 or ISO/ -IEC/IEEE 12207:2008 to acquire or supply soft- -ware user documentation as part of the software -life cycle processes. It defines the documentation -process from the acquirer’s standpoint and the -supplier’s standpoint. ISO/IEC/IEEE 26512:2011 -covers the requirements for information items used -in the acquisition of user documentation products: -the acquisition plan, document specification, state- -ment of work, request for proposals, and proposal. -It provides an overview of the software user docu- -mentation and information management processes -which may require acquisition and supply of soft- -ware user documentation products and services. -It addresses the preparation of requirements for -``` - -**B-12** **_SWEBOK® Guide_** **V3.0** - -software user documentation. These requirements -are central to the user documentation specification -and statement of work. It includes requirements -for primary document outputs of the acquisition -and supply process: the request for proposal and -the proposal for user documentation products and -services. It also discusses the use of a documen- -tation management plan and a document plan as -they arise in the acquisition and supply processes. -ISO/IEC/IEEE 26512:2011 is independent of the -software tools that may be used to produce docu- -mentation and applies to both printed documen- -tation and onscreen documentation. Much of its -guidance is applicable to user documentation for -systems including hardware as well as software. - -The next two standards are mentioned here -because they supply information used in manage- -ment decision-making. - -**IEEE Std. 1028-2008 Standard for Software Reviews -and Audits** -See Software Quality KA - -**IEEE Std. 1061-1998 Standard for Software Quality -Metrics Methodology** -See Software Quality KA - -The next standard is mentioned because it -includes the manager’s role in developing user -documentation in an agile project. - -**ISO/IEC/IEEE 26515:2012 Systems and Software -Engineering—Developing User Documentation in an -Agile Environment** -See Software Engineering Models and -Methods KA - -##### SOFTWARE ENGINEERING PROCESS - -Software and systems engineering processes -are central to the standardization of those two -disciplines—not just because many are inter- -ested in process improvement, but also because -processes are effective for the description of - -``` -improved practices. For example, one might pro- -pose an improved practice for software require- -ments analysis. A naïve treatment might relate -the description to an early stage of the life cycle -model. A superior approach is to describe the -practice in the context of a process that can be -applied at any stage of the life cycle. The require- -ments analysis process, for example, is neces- -sary for the development stage, for maintenance, -and often for retirement, so an improved practice -described in terms of the requirements analysis -process can be applied to any of those stages. -The two key standards are ISO/IEC/IEEE -12207, Software Life Cycle Processes , and ISO/ -IEC/IEEE 15288, System Life Cycle Processes. -The two standards have distinct histories, but -they were both revised in 2008 to align their pro- -cesses, permitting their interoperable use across a -wide spectrum of projects ranging from a stand- -alone software component to a system with neg- -ligible software content. Both are being revised -again with the intent of containing an identical -list of processes, but with provisions specialized -for the respective disciplines. -``` -``` -IEEE Std. 12207-2008 (a.k.a. ISO/IEC 12207:2008) -Standard for Systems and Software Engineering— -Software Life Cycle Processes -``` -``` -ISO/IEC 12207:2008 establishes a common -framework for software life cycle processes, with -well-defined terminology that can be referenced -by the software industry. -ISO/IEC 12207:2008 applies to the acquisi- -tion of systems and software products and ser- -vices and to the supply, development, operation, -maintenance, and disposal of software products -and the software portion of a system, whether -performed internally or externally to an organiza- -tion. Those aspects of system definition needed -to provide the context for software products and -services are included. -ISO/IEC 12207:2008 also provides a process -that can be employed for defining, controlling, -and improving software life cycle processes. -The processes, activities and tasks of ISO/IEC -12207:2008—either alone or in conjunction with -ISO/IEC 15288—may also be applied during the -acquisition of a system that contains software. -``` - -``` -Appendix B B-13 -``` -**IEEE Std. 15288-2008 (a.k.a. ISO/IEC 15288:2008) -Standard for Systems and Software Engineering— -System Life Cycle Processes** - -ISO/IEC 15288:2008 establishes a common -framework for describing the life cycle of sys- -tems created by humans. It defines a set of -processes and associated terminology. These -processes can be applied at any level in the -hierarchy of a system’s structure. Selected sets -of these processes can be applied throughout -the life cycle for managing and performing the -stages of a system’s life cycle. This is accom- -plished through the involvement of all interested -parties, with the ultimate goal of achieving cus- -tomer satisfaction. -ISO/IEC 15288:2008 also provides processes -that support the definition, control, and improve- -ment of the life cycle processes used within an -organization or a project. Organizations and -projects can use these life cycle processes when -acquiring and supplying systems. -ISO/IEC 15288:2008 concerns those systems -that are man-made and may be configured with -one or more of the following: hardware, software, -data, humans, processes (e.g., processes for pro- -viding service to users), procedures (e.g., opera- -tor instructions), facilities, materials, and natu- -rally occurring entities. When a system element is -software, the software life cycle processes docu- -mented in ISO/IEC 12207:2008 may be used to -implement that system element. -ISO/IEC 15288:2008 and ISO/IEC 12207:2008 -are harmonized for concurrent use on a single -project or in a single organization. - -Those two standards specify that processes -may produce items of information but do not pre- -scribe their content or format. The next standard -provides help with that. - -**ISO/IEC/IEEE 15289:2011 Systems and Software -Engineering—Content of Life-Cycle Information -Products (Documentation)** - -ISO/IEC/IEEE 15289:2011 provides require- -ments for identifying and planning the specific - -``` -information items (information products, docu- -mentation) to be developed and revised during -systems and software life cycles and service -management processes. It specifies the purpose -and content of all identified systems and software -data records and life cycle information items, as -well as records and information items for infor- -mation technology service management. The -information item contents are defined according -to generic document types (description, plan, pol- -icy, procedure, report, request, and specification) -and the specific purpose of the document. For -simplicity of reference, each information item -is described as if it were published as a separate -document. However, information items may be -unpublished but available in a repository for ref- -erence, divided into separate documents or vol- -umes, or combined with other information items -into one document. ISO/IEC/IEEE 15289:2011 -is based on the life cycle processes specified in -ISO/IEC 12207:2008 (IEEE Std. 12207 - 2008) -and ISO/IEC 15288:2008 (IEEE Std. 15288- -2008), and the service management processes -specified in ISO/IEC 20000-1:2005 and ISO/IEC -20000-2:2005. -``` -``` -The next two guides provide supplementary -information helpful in applying 12207 and 15288. -``` -``` -IEEE Std. 24748.2-2012 Guide—Adoption of ISO/ -IEC TR 24748-2:2011 Systems and Software Engi- -neering—Life Cycle Management—Part 2: Guide to -the Application of ISO/IEC 15288 (System Life Cycle -Processes) -``` -``` -ISO/IEC TR 24748-2 is a guide for the applica- -tion of ISO/IEC 15288:2008. It addresses sys- -tem, life cycle, process, organizational, project, -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 15288:2008 from the aspects of strat- -egy, planning, application in organizations, and -application on projects. -``` -``` -IEEE Std. 24748.3-2012 Guide—Adoption of -ISO/IEC TR 24748-3:2011 Systems and Software -``` - -**B-14** **_SWEBOK® Guide_** **V3.0** - -**Engineering—Life Cycle Management—Part 3: -Guide to the Application of ISO/IEC 12207 (Soft- -ware Life Cycle Processes)** - -ISO/IEC TR 24748-3 is a guide for the applica- -tion of ISO/IEC 12207:2008. It addresses sys- -tem, life cycle, process, organizational, project, -and adaptation concepts, principally through -reference to ISO/IEC TR 24748-1 and ISO/IEC -12207:2008. It gives guidance on applying ISO/ -IEC 12207:2008 from the aspects of strategy, -planning, application in organizations, and appli- -cation on projects. - -The 12207 and 15288 standards provide pro- -cesses covering the life cycle, but they do not pro- -vide a standard life cycle model (waterfall, incre- -mental delivery, prototype-driven, etc). Selecting -an appropriate life cycle model for a project is a -major concern of ISO/IEC 24748-1. - -**IEEE Std. 24748.1-2011 Guide—Adoption of ISO/ -IEC TR 24748-1:2010 Systems and Software Engi- -neering—Life Cycle Management—Part 1: Guide -for Life Cycle Management** - -ISO/IEC TR 24748-1 provides information on -life cycle concepts and descriptions of the pur- -poses and outcomes of representative life cycle -stages. It also illustrates the use of a life cycle -model for systems in the context of ISO/IEC -15288 and provides a corresponding illustration -of the use of a life cycle model for software in the -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 -specific project and organizational environment. -It further provides guidance on life cycle model -use by domains, disciplines and specialties. ISO/ -IEC TR 24748-1 gives a detailed comparison -between prior and current versions of ISO/IEC -12207 and ISO/IEC 15288 as well as advice on -transitioning from prior to current versions and -on using their application guides. The discus- -sion and advice are intended to provide a refer- -ence model for life cycle models, facilitate use of -the updated ISO/IEC 15288 and ISO/IEC 12207, -and provide a framework for the development of - -``` -updated application guides for those International -Standards. ISO/IEC TR 24748-1 is a result of the -alignment stage of the harmonization of ISO/IEC -12207 and ISO/IEC 15288. -``` -``` -The next standard extends the provisions of -ISO/IEC/IEEE 12207 to deal with systematic -software reuse. -``` -``` -IEEE Std. 1517-2010 Standard for Information -Technology—System and Software Life Cycle Pro- -cesses—Reuse Processes -``` -``` -A common framework for extending the system -and software life cycle processes of IEEE Std. -12207:2008 to include the systematic practice -of reuse is provided. The processes, activities, -and tasks to be applied during each life cycle -process to enable a system and/or product to be -constructed from reusable assets are specified. -The processes, activities, and tasks to enable -the identification, construction, maintenance, -and management of assets supplied are also -specified. -``` -``` -IEEE Std. 1220 has been widely applied as a -systems engineering process and was adopted by -ISO/IEC with the number 26702. Unfortunately, -the standard is not completely compatible with -ISO/IEC/IEEE 15288 and is being revised to -solve that problem. The result will be published -as ISO/IEC/IEEE 24748-4. -``` -``` -IEEE Std. 1220-2005 (a.k.a. ISO/IEC 26702:2007) -Standard for Application and Management of the -Systems Engineering Process -``` -``` -ISO/IEC 26702 defines the interdisciplinary tasks -which are required throughout a system’s life -cycle to transform customer needs, requirements, -and constraints into a system solution. In addi- -tion, it specifies the requirements for the systems -engineering process and its application through- -out the product life cycle. ISO/IEC 26702:2007 -focuses on engineering activities necessary to -guide product development, while ensuring -``` - -``` -Appendix B B-15 -``` -that the product is properly designed to make it -affordable to produce, own, operate, maintain, -and eventually dispose of without undue risk to -health or the environment. - -Since SC 7 and IEEE have written so many -process standards, one may not be surprised to -learn that their model for process description is -recorded in a Technical Report. - -**IEEE Std. 24774-2012 Guide—Adoption of ISO/IEC -TR 24474:2010 Systems and Software Engineer- -ing—Life Cycle Management—Guidelines for Pro- -cess Description** - -An increasing number of international, national, -and industry standards describe process mod- -els. These models are developed for a range of -purposes including process implementation and -assessment. The terms and descriptions used in -such models vary in format, content, and level -of prescription. ISO/IEC TR 24774:2010 pres- -ents guidelines for the elements used most fre- -quently in describing a process: the title, pur- -pose, outcomes, activities, task, and information -item. Whilst the primary purpose of ISO/IEC TR -24774:2010 is to encourage consistency in stan- -dard process reference models, the guidelines it -provides can be applied to any process model -developed for any purpose. - -A very small entity (VSE) is an enterprise, an -organization, a department, or a project having -up to 25 people. The ISO/IEC 29110 series “pro- -files” large standards, such as ISO/IEC 12207 for -software and ISO/IEC 15288 for systems, into -smaller ones for VSEs. ISO 29110 is applicable to -VSEs that do not develop critical systems or criti- -cal software. Profiles provide a roadmap allowing -a start-up to grow a step at a time using the ISO -29110 management and engineering guides. -ISO/IEC 29110 set of standards and technical -reports are targeted by audience such as VSEs, -customers, or auditors. ISO/IEC 29110 is not -intended to preclude the use of different life -cycles approaches such as waterfall, iterative, -incremental, evolutionary, or agile. - -``` -A VSE could obtain an ISO/IEC 29110 Certi- -fication. The set of technical reports is available -at no cost on the ISO website. Many ISO 29110 -documents are available in English, Spanish, Por- -tuguese, Japanese, and French. -``` -``` -ISO/IEC TR 29110-5-1-2:2011 Software Engineer- -ing—Lifecycle Profiles for Very Small Entities -(VSEs)—Part 5-1-2: Management and Engineering -Guide: Generic Profile Group: Basic Profile -``` -``` -ISO/IEC TR 29110-5-1-2:2011 is applicable to -very small entities (VSEs). A VSE is defined as -an enterprise, organization, department, or proj- -ect having up to 25 people. A set of standards and -guides has been developed according to a set of -VSEs’ characteristics and needs. The guides are -based on subsets of appropriate standards ele- -ments, referred to as VSE profiles. The purpose -of a VSE profile is to define a subset of ISO/IEC -international standards relevant to the VSEs’ -context. -ISO/IEC TR 29110-5-1-2:2011 provides the -management and engineering guide to the basic -VSE profile applicable to VSEs that do not -develop critical software. The generic profile -group does not imply any specific application -domain. -``` -``` -The next standard may be viewed as an alterna- -tive to 12207 for individual projects. The 1074 -standard explains how to define processes for -use on a given project. The 12207 and 15288 -standards, however, focus on defining processes -for organizational adoption and repeated use on -many projects. The current 1074 is the update of -a standard that was a predecessor of 12207. -``` -``` -IEEE Std. 1074-2006 Standard for Developing a -Software Project Life Cycle Process -``` -``` -This standard provides a process for creating a -software project life cycle process (SPLCP). It is -primarily directed at the process architect for a -given software project. -``` - -**B-16** **_SWEBOK® Guide_** **V3.0** - -All of the standards described so far in this sec- -tion provide a basis for _defining_ processes. Some -users are interested in _assessing_ and improving -their processes after implementation. The 15504 -series provides for process assessment; it is cur- -rently being revised and renumbered 330xx. - -**ISO/IEC 15504 [ten parts] Information Technol- -ogy—Process Assessment** - -ISO/IEC 15504-2:2003 defines the requirements -for performing process assessment as a basis -for use in process improvement and capability -determination. -Process assessment is based on a two-dimen- -sional model containing a process dimension and -a capability dimension. The process dimension is -provided by an external process reference model -(such as 12207 or 15288), which defines a set of -processes characterized by statements of process -purpose and process outcomes. The capability -dimension consists of a measurement framework -comprising six process capability levels and their -associated process attributes. -The assessment output consists of a set of pro- -cess attribute ratings for each process assessed, -termed the process profile, and may also include -the capability level achieved by that process. -ISO/IEC 15504-2:2003 identifies the measure- -ment framework for process capability and the -requirements for - -- performing an assessment; -- process reference models; -- process assessment models; -- verifying conformity of process assessment. - -The requirements for process assessment -defined in ISO/IEC 15504-2:2003 form a struc- -ture that - -- facilitates self-assessment; -- provides a basis for use in process improve- - ment and capability determination; -- takes into account the context in which the - assessed process is implemented; -- produces a process rating; -- addresses the ability of the process to achieve - its purpose; - - is applicable across all application domains - and sizes of organization; and - - may provide an objective benchmark - between organizations. - -``` -The minimum set of requirements defined in -ISO/IEC 15504-2:2003 ensures that assessment -results are objective, impartial, consistent, repeat- -able, and representative of the assessed processes. -Results of conformant process assessments may -be compared when the scopes of the assessments -are considered to be similar; for guidance on this -matter, refer to ISO/IEC 15504-4. -``` -``` -Several other standards are mentioned here -because they are written as elaborations of the -processes of 12207 or 15288. They are allocated -to other KAs because each one deals with topics -described in those other KAs. -``` -``` -IEEE Std. 828-2012 Standard for Configuration -Management in Systems and Software Engineering -See Software Configuration Management KA -``` -``` -IEEE Std. 14764-2006 (a.k.a. ISO/IEC 14764:2006) -Standard for Software Engineering—Software Life -Cycle Processes—Maintenance -See Software Maintenance KA -``` -``` -ISO/IEC 15026-4:2012 Systems and Software Engi- -neering—Systems and Software Assurance—Part 4: -Assurance in the Life Cycle -See Software Quality KA -``` -``` -IEEE Std. 15939-2008 Standard Adoption of ISO/ -IEC 15939:2007 Systems and Software Engineer- -ing—Measurement Process -See Software Engineering Management KA -``` -``` -ISO/IEC 15940:2006 Information Technology— -Software Engineering Environment Services -See Software Engineering Models and -Methods KA -``` -``` -IEEE Std. 16085-2006 (a.k.a. ISO/IEC 16085:2006) -Standard for Systems and Software Engineering— -Software Life Cycle Processes—Risk Management -See Software Engineering Management KA -``` - -``` -Appendix B B-17 -``` -**ISO/IEC/IEEE 16326:2009 Systems and Soft- -ware Engineering—Life Cycle Processes—Project -Management** -See Software Engineering Management KA - -**ISO/IEC/IEEE 29148:2011 Systems and Software -Engineering—Life Cycle Processes—Requirements -Engineering** -See Software Requirements KA - -Some users desire process standards usable -for IT operations or IT service management. -The ISO/IEC 20000 series describe IT service -management. The processes are less rigorously -defined than those of the aforementioned engi- -neering standards, but may be preferable for situ- -ations where the risks of failure involve money -or customer satisfaction rather than public health, -safety, and welfare. The ISO/IEC 20000 series -now extend to many parts. The foundation of -the series, ISO/IEC 20000-1, is briefly described -below. - -**ISO/IEC 20000-1:2011 Information Technology— -Service Management—Part 1: Service Management -System Requirements** - -ISO/IEC 20000-1:2011 is a service management -system (SMS) standard. It specifies requirements -for the service provider to plan, establish, imple- -ment, operate, monitor, review, maintain, and -improve an SMS. The requirements include the -design, transition, delivery and improvement of -services to fulfill agreed service requirements. - -IEEE has adopted the first two parts of the ISO/ -IEC 20000 series. - -**SOFTWARE ENGINEERING MODELS -AND METHODS** - -Some approaches to software engineering use -methods that cut across large parts of the life -cycle, rather than focusing on specific processes. -“Chief Programmer” was one traditional exam- -ple. “Agile development” (actually an example -of traditional incremental delivery) is a current - -``` -example. Neither S2ESC nor SC 7 has a standard -for agile development, but there is a standard -for developing user documentation in an agile -project. -``` -``` -ISO/IEC/IEEE 26515:2012 Systems and Software -Engineering—Developing User Documentation in an -Agile Environment -``` -``` -ISO/IEC/IEEE 26515:2012 specifies the way in -which user documentation can be developed in -agile development projects. It is intended for use -in all organizations that are using agile develop- -ment or are considering implementing their proj- -ects using these techniques. It applies to people -or organizations producing suites of documen- -tation, to those undertaking a single documen- -tation project, and to documentation produced -internally, as well as to documentation contracted -to outside service organizations. ISO/IEC/IEEE -26515:2012 addresses the relationship between -the user documentation process and the life cycle -documentation process in agile development. It -describes how the information developer or proj- -ect manager may plan and manage the user docu- -mentation development in an agile environment. -It is intended neither to encourage nor to discour- -age the use of any particular agile development -tools or methods. -``` -``` -Many methodologies are based on semiformal -descriptions of the software to be constructed. -These range from simple descriptive notations -to models that can be manipulated and tested -and, in some cases, can generate code. Two rela- -tively old techniques start the list; the first has -been widely applied for modeling processes and -workflows. -``` -``` -IEEE Std. 1320.1-1998 Standard for Functional Mod- -eling Language—Syntax and Semantics for IDEF0 -``` -``` -IDEF0 function modeling is designed to repre- -sent the decisions, actions, and activities of an -existing or prospective organization or system. -IDEF0 graphics and accompanying texts are pre- -sented in an organized and systematic way to gain -``` - -**B-18** **_SWEBOK® Guide_** **V3.0** - -understanding, support analysis, provide logic for -potential changes, specify requirements, and sup- -port system-level design and integration activi- -ties. IDEF0 may be used to model a wide variety -of systems, composed of people, machines, mate- -rials, computers, and information of all varieties, -and structured by the relationships among them, -both automated and nonautomated. For new sys- -tems, IDEF0 may be used first to define require- -ments and to specify the functions to be carried -out by the future system. As the basis of this -architecture, IDEF0 may then be used to design -an implementation that meets these requirements -and performs these functions. For existing sys- -tems, IDEF0 can be used to analyze the functions -that the system performs and to record the means -by which these are done. - -**IEEE Std. 1320.2-1998 Standard for Conceptual -Modeling Language—Syntax and Semantics for -IDEF1X97 (IDEFobject)** - -IDEF1X 97 consists of two conceptual modeling -languages. The key-style language supports data/ -information modeling and is downward compat- -ible with the US government’s 1993 standard, -FIPS PUB 184. The identity-style language is -based on the object model with declarative rules -and constraints. IDEF1X 97 identity style includes -constructs for the distinct but related components -of object abstraction: interface, requests, and -realization; utilizes graphics to state the interface; -and defines a declarative, directly executable rule -and constraint language for requests and realiza- -tions. IDEF1X 97 conceptual modeling supports -implementation by relational databases, extended -relational databases, object databases, and object -programming languages. IDEF1X 97 is formally -defined in terms of first order logic. A procedure -is given whereby any valid IDEF1X 97 model -can be transformed into an equivalent theory in -first order logic. That procedure is then applied to -a metamodel of IDEF1X 97 to define the valid set -of IDEF1X 97 models. - -In recent years, the UML notation has become -popular for modeling software-intensive systems. - -``` -The next two standards provide two versions of -the UML language. -``` -``` -ISO/IEC 19501:2005 Information Technology— -Open Distributed Processing—Unified Modeling -Language (UML) Version 1.4.2 -``` -``` -ISO/IEC 19501 describes the Unified Model- -ing Language (UML), a graphical language for -visualizing, specifying, constructing, and docu- -menting the artifacts of a software-intensive sys- -tem. The UML offers a standard way to write a -system’s blueprints, including conceptual things -such as business processes and system functions -as well as concrete things such as programming -language statements, database schemas, and reus- -able software components. -``` -``` -ISO/IEC 19505:2012 [two parts] Information Tech- -nology—Object Management Group Unified Model- -ing Language (OMG UML) -``` -``` -ISO/IEC 19505 defines the Unified Modeling -Language (UML), revision 2. The objective of -UML is to provide system architects, software -engineers, and software developers with tools for -analysis, design, and implementation of software- -based systems as well as for modeling business -and similar processes. -``` -``` -Two more standards build on the base of UML -to provide additional modeling capabilities: -``` -``` -ISO/IEC 19506:2012 Information Technology— -Object Management Group Architecture-Driven -Modernization (ADM)—Knowledge Discovery -Meta-Model (KDM) -``` -``` -ISO/IEC 19506:2012 defines a metamodel for rep- -resenting existing software assets, their associa- -tions, and operational environments, referred to as -the knowledge discovery metamodel (KDM). This -is the first in the series of specifications related to -software assurance (SwA) and architecture-driven -modernization (ADM) activities. KDM facilitates -``` - -``` -Appendix B B-19 -``` -projects that involve existing software systems -by insuring interoperability and exchange of data -between tools provided by different vendors. - -**ISO/IEC 19507:2012 Information Technology— -Object Management Group Object Constraint Lan- -guage (OCL)** - -ISO/IEC 19507:2012 defines the Object Con- -straint Language (OCL), version 2.3.1. OCL ver- -sion 2.3.1 is the version of OCL that is aligned -with UML 2.3 and MOF 2.0. - -Some organizations invest in software engi- -neering environments (SEE) to assist in the -construction of software. An SEE, per se, is not -a replacement for sound processes. However, a -suitable SEE must support the processes that -have been chosen by the organization. - -**ISO/IEC 15940:2006 Information Technology— -Software Engineering Environment Services** - -ISO/IEC 15940:2006 defines software engineering -environment (SEE) services conceptually in a refer- -ence model that can be adapted to any SEEs to auto- -mate one or more software engineering activities. -It describes services that support the process defini- -tions as in ISO/IEC 12207 so that the set of SEE -services is compatible with ISO/IEC 12207. ISO/ -IEC 15940:2006 can be used either as a general ref- -erence or to define an automated software process. - -The selection of tooling for a software engineering -environment is itself a difficult task. Two standards -provide some assistance. ISO/IEC 14102:2008 -defines both a set of processes and a structured set of -computer-aided software engineering (CASE) tool -characteristics for use in the technical evaluation -and the ultimate selection of a CASE tool. - -**IEEE Std. 14102-2010 Standard Adoption of ISO/ -IEC 14102:2008 Information Technology—Guide- -line for the Evaluation and Selection of CASE Tools** - -``` -Within systems and software engineering, com- -puter-aided software engineering (CASE) tools -represent a major part of the supporting tech- -nologies used to develop and maintain informa- -tion technology systems. Their selection must be -carried out with careful consideration of both the -technical and management requirements. -ISO/IEC 14102:2008 defines both a set of pro- -cesses and a structured set of CASE tool char- -acteristics for use in the technical evaluation and -the ultimate selection of a CASE tool. It follows -the software product evaluation model defined in -ISO/IEC 14598-5:1998. -ISO/IEC 14102:2008 adopts the general model -of software product quality characteristics and -subcharacteristics defined in ISO/IEC 9126- -1:2001 and extends these when the software -product is a CASE tool; it provides product char- -acteristics unique to CASE tools. -``` -``` -The next document provides guidance on how -to adopt CASE tools, once selected. -``` -``` -IEEE Std. 14471-2010 Guide—Adoption of ISO/IEC -TR 14471:2007 Information Technology—Software -Engineering—Guidelines for the Adoption of CASE -Tools -``` -``` -The purpose of ISO/IEC TR 14471:2007 is to -provide a recommended practice for CASE adop- -tion. It provides guidance in establishing pro- -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 -to maximize the return and minimize the risk of -investing in CASE technology. However, ISO/ -IEC TR 14471:2007 does not establish compli- -ance criteria. -It is best used in conjunction with ISO/IEC -14102 for CASE tool evaluation and selection. It -neither dictates nor advocates particular develop- -ment standards, software processes, design meth- -ods, methodologies, techniques, programming -languages, or life cycle paradigms. -``` - -**B-20** **_SWEBOK® Guide_** **V3.0** - -Within a software engineering environment, it -is important for the various tools to interoperate. -The following standards provide a scheme for -interconnection. - -**IEEE Std. 1175.1-2002 Guide for CASE Tool Inter- -connections—Classification and Description** - -**IEEE Std. 1175.2-2006 Recommended Practice for -CASE Tool Interconnection—Characterization of -Interconnections** - -**IEEE Std. 1175.3-2004 Standard for CASE Tool -Interconnections—Reference Model for Specifying -Software Behavior** - -**IEEE Std. 1175.4-2008 Standard for CASE Tool -Interconnections—Reference Model for Specifying -System Behavior** - -The purpose of this family of standards is to spec- -ify a common set of modeling concepts based -on those found in commercial CASE tools for -describing the operational behavior of a software -system. These standards establish a uniform, -integrated model of software concepts related to -software functionality. They also provide a tex- -tual syntax for expressing the common properties -(attributes and relationships) of those concepts as -they have been used to model software behavior. - -##### SOFTWARE QUALITY - -One viewpoint of software quality starts with -ISO 9001, _Quality Management Requirements_ , -dealing with quality policy throughout an orga- -nization. The terminology of that standard may -be unfamiliar to software professionals, and -quality management auditors may be unfamiliar -with software jargon. The following standard -describes the relationship between ISO 9001 and -ISO/IEC 12207. Unfortunately, the current ver- -sion refers to obsolete editions of both; a replace- -ment is in progress: - -**IEEE Std. 90003-2008 Guide—Adoption of ISO/ -IEC 90003:2004 Software Engineering—Guidelines** - -``` -for the Application of ISO 9001:2000 to Computer -Software -``` -``` -ISO/IEC 90003 provides guidance for organiza- -tions in the application of ISO 9001:2000 to the -acquisition, supply, development, operation, and -maintenance of computer software and related -support services. ISO/IEC 90003:2004 does not -add to or otherwise change the requirements of -ISO 9001:2000. -The guidelines provided in ISO/IEC -90003:2004 are not intended to be used as assess- -ment criteria in quality management system -registration/certification. -The application of ISO/IEC 90003:2004 is -appropriate to software that is -``` -- part of a commercial contract with another - organization, -- a product available for a market sector, -- used to support the processes of an - organization, -- embedded in a hardware product, or -- related to software services. - -``` -Some organizations may be involved in all -the above activities; others may specialize in -one area. Whatever the situation, the organiza- -tion’s quality management system should cover -all aspects (software related and nonsoftware -related) of the business. -ISO/IEC 90003:2004 identifies the issues -which should be addressed and is independent -of the technology, life cycle models, develop- -ment processes, sequence of activities, and -organizational structure used by an organiza- -tion. Additional guidance and frequent ref- -erences to the ISO/IEC JTC 1/SC 7 software -engineering standards are provided to assist in -the application of ISO 9001:2000: in particu- -lar, ISO/IEC 12207, ISO/IEC TR 9126, ISO/ -IEC 14598, ISO/IEC 15939, and ISO/IEC TR -15504. -``` -``` -The ISO 9001 approach posits an organiza- -tion-level quality management process paired -with project-level quality assurance planning -to achieve the organizational goals. IEEE 730 -describes project-level quality planning. It is -``` - -``` -Appendix B B-21 -``` -currently aligned with an obsolete edition of -12207, but a revision is being prepared. - -**IEEE Std. 730-2002 Standard for Software Quality -Assurance Plans** - -The standard specifies the format and content of -software quality assurance plans. - -Another viewpoint of software quality begins -with enumerating the desired characteristics of a -software product and selecting measures or other -evaluations to determine if the desired level of -characteristics has been achieved. The so-called -SQuaRE (software product quality requirements -and evaluation) series of SC 7 standards covers -this approach in great detail. - -**ISO/IEC 25000 through 25099 Software Engineer- -ing—Software Product Quality Requirements and -Evaluation (SQuaRE)** - -A few of the SQuaRE standards are selected -below for particular attention. The first is the -overall guide to the series. - -**ISO/IEC 25000:2005 Software Engineering—Soft- -ware Product Quality Requirements and Evaluation -(SQuaRE)—Guide to SQuaRE** - -ISO/IEC 25000:2005 provides guidance for the -use of the new series of international standards -named Software product Quality Requirements -and Evaluation (SQuaRE). The purpose of this -guide is to provide a general overview of SQuaRE -contents, common reference models, and defini- -tions, as well as the relationship among the docu- -ments, allowing users of this guide a good under- -standing of those international standards. This -document contains an explanation of the transi- -tion process between the old ISO/IEC 9126 and -the 14598 series and SQuaRE, and also presents -information on how to use the ISO/IEC 9126 and -14598 series in their previous form. - -``` -SQuaRE provides -``` -- terms and definitions, -- reference models, -- guides -- standards for requirements specification, - planning and management, measurement, - and evaluation purposes. - -``` -The next SQuaRE standard provides a taxon- -omy of software quality characteristics that may -be useful in selecting characteristics relevant to a -specific project: -``` -``` -ISO/IEC 25010:2011 Systems and Software Engi- -neering—Systems and Software Quality Require- -ments and Evaluation (SQuaRE)—System and Soft- -ware Quality Models -``` -``` -ISO/IEC 25010:2011 defines the following: -``` -1. A quality in-use model composed of five - characteristics (some of which are further - subdivided into subcharacteristics) that - relate to the outcome of interaction when a - product is used in a particular context of use. - This system model is applicable to the com- - plete human-computer system, including - both computer systems in use and software - products in use. -2. A product quality model composed of eight - characteristics (which are further subdivided - into subcharacteristics) that relate to static - properties of software and dynamic proper- - ties of the computer system. The model is - applicable to both computer systems and - software products. - -``` -The characteristics defined by both models -are relevant to all software products and com- -puter systems. The characteristics and subchar- -acteristics provide consistent terminology for -specifying, measuring, and evaluating system -and software product quality. They also provide -a set of quality characteristics against which -stated quality requirements can be compared for -completeness. -``` - -**B-22** **_SWEBOK® Guide_** **V3.0** - -Although the scope of the product quality -model is intended to be software and computer -systems, many of the characteristics are also rel- -evant to wider systems and services. -ISO/IEC 25012 contains a model for data qual- -ity that is complementary to this model. -The scope of the models excludes purely func- -tional properties, but it does include functional -suitability. -The scope of application of the quality models -includes supporting specification and evaluation -of software and software-intensive computer sys- -tems from different perspectives by those who are -associated with their acquisition, requirements, -development, use, evaluation, support, mainte- -nance, quality assurance and control, and audit. -The models can, for example, be used by devel- -opers, acquirers, quality assurance and control -staff, and independent evaluators, particularly -those responsible for specifying and evaluating -software product quality. Activities during prod- -uct development that can benefit from the use of -the quality models include - -- identifying software and system requirements; -- validating the comprehensiveness of a - requirements definition; -- identifying software and system design - objectives; -- identifying software and system testing - objectives; -- identifying quality control criteria as part of - quality assurance; -- identifying acceptance criteria for a software - product and/or software-intensive computer - system; -- establishing measures of quality characteris- - tics in support of these activities. - -Some documents in the SQuaRE series deal spe- -cifically with the characteristic of usability. The -Common Industry Format (CIF) for usability report- -ing began at the US National Institute for Standards -and Technology (NIST) and was moved into ISO/ -IEC JTC 1/SC 7 for purposes of standardization. - -**ISO/IEC 25060 through 25064 Software Engineer- -ing—Software Product Quality Requirements and** - -``` -Evaluation (SQuaRE)—Common Industry Format -(CIF) for Usability -``` -``` -A family of international standards, named the -Common Industry Formats (CIF), documents -the specification and evaluation of the usability -of interactive systems. It provides a general over- -view of the CIF framework and contents, defini- -tions, and the relationship of the framework ele- -ments. The intended users of the framework are -identified, as well as the situations in which the -framework may be applied. The assumptions and -constraints of the framework are also enumerated. -The framework content includes the following: -``` -- consistent terminology and classification of - specification, evaluation, and reporting; -- a definition of the type and scope of formats - and the high-level structure to be used for - documenting required information and the - results of evaluation. - -``` -The CIF family of standards is applicable to -software and hardware products used for pre- -defined tasks. The information items are intended -to be used as part of system-level documentation -resulting from development processes such as -those in ISO 9241-210 and ISO/IEC JTC 1/SC 7 -process standards. -The CIF family focuses on documenting those -elements needed for design and development of -usable systems, rather than prescribing a specific -process. It is intended to be used in conjunction -with existing international standards, includ- -ing ISO 9241, ISO 20282, ISO/IEC 9126, and -the SQuaRE series (ISO/IEC 25000 to ISO/IEC -25099). -The CIF family of standards does not prescribe -any kind of method, life cycle or process. -``` -``` -Not everyone agrees with the taxonomy of -quality characteristics in ISO/IEC 25010. That -standard has a quality factor called “reliability” -that has subfactors of maturity, availability, fault -tolerance, and recoverability. IEC TC 65, which -has responsibility for standards on “dependabil- -ity,” defines that term as a nonquantitative com- -posite of reliability, maintainability, and mainte- -nance support. Others use the term “reliability” -``` - -``` -Appendix B B-23 -``` -to denote a measure defined by a mathematical -equation. The disagreement over the use of these -words means that the standards on the subject are -inherently unaligned. A few will be noted below, -but the words like those noted above may mean -different things in different standards. - -**IEEE Std. 982.1-2005 Standard for Dictionary of -Measures of the Software Aspects of Dependability** - -A standard dictionary of measures of the soft- -ware aspects of dependability for assessing and -predicting the reliability, maintainability, and -availability of any software system; in particular, -it applies to mission critical software systems. - -**IEEE Std. 1633-2008 Recommended Practice for -Software Reliability** - -The methods for assessing and predicting the reli- -ability of software, based on a life cycle approach -to software reliability engineering, are prescribed in -this recommended practice. It provides information -necessary for the application of software reliability -(SR) measurement to a project, lays a foundation -for building consistent methods, and establishes -the basic principle for collecting the data needed to -assess and predict the reliability of software. The -recommended practice prescribes how any user can -participate in SR assessments and predictions. - -IEEE has an overall standard for software -product quality that has a scope similar to the -ISO/IEC 250xx series described previously. Its -terminology differs from the ISO/IEC series, but -it is substantially more compact. - -**IEEE Std. 1061-1998 Standard for Software Quality -Metrics Methodology** - -A methodology for establishing quality require- -ments and identifying, implementing, analyzing, -and validating the process and product software -quality metrics is defined. The methodology -spans the entire software life cycle. - -``` -One approach to achieving software quality is -to perform an extensive program of verification -and validation. IEEE Std. 1012 is probably the -world’s most widely applied standard on this sub- -ject. A revision was recently published. -``` -``` -IEEE Std. 1012-2012 Standard for System and Soft- -ware Verification and Validation -``` -``` -Verification and validation (V&V) processes are -used to determine whether the development prod- -ucts of a given activity conform to the require- -ments of that activity and whether the product -satisfies its intended use and user needs. V&V life -cycle process requirements are specified for differ- -ent integrity levels. The scope of V&V processes -encompasses systems, software, and hardware, and -it includes their interfaces. This standard applies to -systems, software, and hardware being developed, -maintained, or reused [legacy, commercial off-the- -shelf (COTS), nondevelopmental items]. The term -software also includes firmware and microcode, -and each of the terms system, software, and hard- -ware includes documentation. V&V processes -include the analysis, evaluation, review, inspec- -tion, assessment, and testing of products. -``` -``` -There are other standards that support the veri- -fication and validation processes. One describes -techniques for performing reviews and audits -during a software project. -``` -``` -IEEE Std. 1028-2008 Standard for Software Reviews -and Audits -``` -``` -Five types of software reviews and audits, -together with procedures required for the execu- -tion of each type, are defined in this standard. -This standard is concerned only with the reviews -and audits; procedures for determining the neces- -sity of a review or audit are not defined, and the -disposition of the results of the review or audit -is not specified. Types included are management -reviews, technical reviews, inspections, walk- -throughs, and audits. -``` - -**B-24** **_SWEBOK® Guide_** **V3.0** - -In many cases, a database of software anoma- -lies is used to support verification and validation -activities. The following standard suggests how -anomalies should be classified. - -**IEEE Std. 1044-2009 Standard for Classification for -Software Anomalies** - -This standard provides a uniform approach to the -classification of software anomalies, regardless -of when they originate or when they are encoun- -tered within the project, product, or system life -cycle. Classification data can be used for a vari- -ety of purposes, including defect causal analy- -sis, project management, and software process -improvement (e.g., to reduce the likelihood of -defect insertion and/or increase the likelihood of -early defect detection). - -In some systems, one particular property of the -software is so important that it requires special -treatment beyond that provided by a conven- -tional verification and validation program. The -emerging term for this sort of treatment is “sys- -tems and software assurance.” Examples include -safety, privacy, high security, and ultrareliability. -The 15026 standard is under development to deal -with such situations. The first part of the four-part -standard provides terminology and concepts used -in the remaining parts. It was first written before -the other parts and is now being revised for com- -plete agreement with the others. - -**IEEE Std. 15026.1-2011 Trial-Use Standard Adop- -tion of ISO/IEC TR 15026-1:2010 Systems and Soft- -ware Engineering—Systems and Software Assur- -ance—Part 1: Concepts and Vocabulary** - -This trial-use standard adopts ISO/IEC TR -15026-1:2010, which defines terms and estab- -lishes an extensive and organized set of concepts -and their relationships for software and systems -assurance, thereby establishing a basis for shared -understanding of the concepts and principles cen- -tral to ISO/IEC 15026 across its user communi- -ties. It provides information to users of the sub- -sequent parts of ISO/IEC 15026, including the - -``` -use of each part and the combined use of multiple -parts. Coverage of assurance for a service being -operated and managed on an ongoing basis is not -covered in ISO/IEC 15026. -``` -``` -The second part of the standard describes the -structure of an “assurance case,” which is intended -as a structured argument that the critical property -has been achieved. It is a generalization of various -domain-specific constructs like “safety cases.” -``` -``` -IEEE Std. 15026.2-2011 Standard Adoption of ISO/ -IEC 15026-2:2011 Systems and Software Engineer- -ing—Systems and Software Assurance—Part 2: -Assurance Case -``` -``` -ISO/IEC 15026-2:2011 is adopted by this stan- -dard. ISO/IEC 15026-2:2011 specifies minimum -requirements for the structure and contents of an -assurance case to improve the consistency and -comparability of assurance cases and to facili- -tate stakeholder communications, engineering -decisions, and other uses of assurance cases. An -assurance case includes a top-level claim for a -property of a system or product (or set of claims), -systematic argumentation regarding this claim, -and the evidence and explicit assumptions that -underlie this argumentation. Arguing through -multiple levels of subordinate claims, this struc- -tured argumentation connects the top-level claim -to the evidence and assumptions. Assurance -cases are generally developed to support claims -in areas such as safety, reliability, maintain- -ability, human factors, operability, and security, -although these assurance cases are often called -by more specific names, e.g., safety case or reli- -ability and maintainability (R&M) case. ISO/IEC -15026-2:2011 does not place requirements on -the quality of the contents of an assurance case -and does not require the use of a particular termi- -nology or graphical representation. Likewise, it -places no requirements on the means of physical -implementation of the data, including no require- -ments for redundancy or colocation. -``` -``` -In many systems, some portions are critical to -achieving the desired property while others are only -``` - -``` -Appendix B B-25 -``` -incidental. For example, the flight control system of -an airliner is critical to safety, but the microwave -oven is not. Conventionally, the various portions -are assigned “criticality levels” to indicate their sig- -nificance to the overall achievement of the property. -The third part of ISO/IEC 15026 describes how that -is done. This part will be revised for better fit with -the remainder of the 15026 standard. - -**ISO/IEC 15026-3:2011 Systems and Software Engi- -neering—Systems and Software Assurance—Part 3: -System Integrity Levels** - -ISO/IEC 15026-3:2011 specifies the concept of -integrity levels with corresponding integrity level -requirements that are required to be met in order -to show the achievement of the integrity level. It -places requirements on and recommends meth- -ods for defining and using integrity levels and -their integrity level requirements, including the -assignment of integrity levels to systems, soft- -ware products, their elements, and relevant exter- -nal dependences. -ISO/IEC 15026-3:2011 is applicable to sys- -tems and software and is intended for use by: - -- definers of integrity levels such as industry - and professional organizations, standards - organizations, and government agencies; -- users of integrity levels such as developers - and maintainers, suppliers and acquirers, - users, and assessors of systems or software, - and for the administrative and technical sup- - port of systems and/or software products. - -One important use of integrity levels is by sup- -pliers and acquirers in agreements; for example, -to aid in assuring safety, economic, or security -characteristics of a delivered system or product. -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- -scribe the way in which integrity level use is inte- -grated with the overall system or software engi- -neering life cycle processes. -ISO/IEC 15026-3:2011 can be used alone or -with other parts of ISO/IEC 15026. It can be used -with a variety of technical and specialized risk -analysis and development approaches. ISO/IEC - -``` -TR 15026-1 provides additional information and -references to aid users of ISO/IEC 15026-3:2011. -ISO/IEC 15026-3:2011 does not require the -use of the assurance cases described by ISO/IEC -15026-2 but describes how integrity levels and -assurance cases can work together, especially in -the definition of specifications for integrity levels -or by using integrity levels within a portion of an -assurance case. -``` -``` -The final part of 15026 provides additional -guidance for executing the life cycle processes of -12207 and 15288 when a system or software is -required to achieve an important property. -``` -``` -ISO/IEC 15026-4:2012 Systems and Software Engi- -neering—Systems and Software Assurance—Part 4: -Assurance in the Life Cycle -``` -``` -This part of ISO/IEC 15026 gives guidance and -recommendations for conducting selected pro- -cesses, activities and tasks for systems and software -products requiring assurance claims for properties -selected for special attention, called critical proper- -ties. This part of ISO/IEC 15026 specifies a prop- -erty-independent list of processes, activities, and -tasks to achieve the claim and show the achieve- -ment of the claim. This part of ISO/IEC 15026 -establishes the processes, activities, tasks, guidance, -and recommendations in the context of a defined -life cycle model and set of life cycle processes for -system and/or software life cycle management. -``` -``` -The next standard deals with a property— -safety—that is often identified as critical. It was -originally developed in cooperation with the US -nuclear power industry. -``` -``` -IEEE Std. 1228-1994 Standard for Software Safety -Plans -``` -``` -The minimum acceptable requirements for the -content of a software safety plan are established. -This standard applies to the software safety plan -used for the development, procurement, mainte- -nance, and retirement of safety-critical software. -``` - -**B-26** **_SWEBOK® Guide_** **V3.0** - -This standard requires that the plan be prepared -within the context of the system safety pro- -gram. Only the safety aspects of the software are -included. This standard does not contain special -provisions required for software used in distrib- -uted systems or in parallel processors. - -Classical treatments suggest that “verification” -deals with static evaluation methods and that -“testing” deals with dynamic evaluation meth- -ods. Recent treatments, including ISO/IEC draft -29119, are blurring this distinction, though, so -testing standards are mentioned here. - -**IEEE Std. 829-2008 Standard for Software and Sys- -tem Test Documentation** -See Software Testing KA - -**IEEE Std. 1008-1987 Standard for Software Unit -Testing** -See Software Testing KA - -**IEEE Std. 26513-2010 Standard Adoption of ISO/ -IEC 26513:2009 Systems and Software Engineer- -ing—Requirements for Testers and Reviewers of -Documentation** -See Software Testing KA - -**ISO/IEC/IEEE 29119 [four parts] (Draft) Software -and Systems Engineering—Software Testing** -See Software Testing KA - -##### SOFTWARE ENGINEERING - -##### PROFESSIONAL PRACTICE - -IEEE is a provider of products related to the cer- -tification of professional practitioners of software -engineering. The first has already been described, -the _Guide to the Software Engineering Body of -Knowledge_. The _SWEBOK Guide_ has been adopted -by ISO/IEC as an outline of the knowledge that pro- -fessional software engineers should have. - -**ISO/IEC TR 19759:2005 Software Engineer- -ing—Guide to the Software Engineering Body of** - -``` -Knowledge (SWEBOK) -See General -``` -``` -An SC 7 standard provides a framework for -comparisons among certifications of software -engineering professionals. That standard states -that the areas considered in certification must be -mapped to the SWEBOK Guide. -``` -``` -ISO/IEC 24773:2008 Software Engineering—Certi- -fication of Software Engineering Professionals -``` -``` -ISO/IEC 24773:2008 establishes a framework for -comparison of schemes for certifying software -engineering professionals. A certification scheme -is a set of certification requirements for software -engineering professionals. ISO/IEC 24773:2008 -specifies the items that a scheme is required to -contain and indicates what should be defined for -each item. -ISO/IEC 24773:2008 will facilitate the porta- -bility of software engineering professional cer- -tifications between different countries or orga- -nizations. At present, different countries and -organizations have adopted different approaches -on the topic, which are implemented by means -of regulations and bylaws. The intention of ISO/ -IEC 24773:2008 is to be open to these individ- -ual approaches by providing a framework for -expressing them in a common scheme that can -lead to understanding. -``` -``` -SC 7 is currently drafting a guide that will sup- -plement 24773. -``` -``` -SOFTWARE ENGINEERING ECONOMICS -``` -``` -No standards are allocated to this KA. -``` -``` -COMPUTING FOUNDATIONS -``` -``` -No standards are allocated to this KA. -``` -``` -MATHEMATICAL FOUNDATIONS -``` -``` -No standards are allocated to this KA. -``` - -``` -Appendix B B-27 -``` -##### ENGINEERING FOUNDATIONS - -No standards are allocated to this KA. - -**STAYING CURRENT** - -This article was obsolescent the moment it was -drafted. Some readers will need to know how -to get current designations and descriptions of -standards. This section describes some helpful -resources. - -**WHERE TO FIND STANDARDS** - -The list of standards published for ISO/IEC JTC -1/SC 7 can be found at [http://www.iso.org/iso/iso_](http://www.iso.org/iso/iso_) -catalogue/catalogue_tc/catalogue_tc_browse. -htm?commid=45086. -Because the URL might change, readers might -have to navigate to the list. Begin at [http://www.iso.org/](http://www.iso.org/) -iso/store.htm, then click on “browse standards -catalogue,” then “browse by TC,” then “JTC 1,” -then “SC 7.” -Finding the current list of standards for S2ESC -is a bit more difficult. Begin at [http://standards.](http://standards.) -ieee.org/. In the search box under “Find Stan- -dards,” type “S2ESC.” This should produce a -list of published standards for which S2ESC is -responsible. -Keep in mind that the searchable databases -are compilations. Like any such database, they -can contain errors that lead to incomplete search -results. - -**WHERE TO OBTAIN THE STANDARDS** - -Some readers will want to obtain standards -described in this article. The first thing to -know is that some international standards are -available free for individual use. The current -list of ISO/IEC standards available under these -terms is located at [http://standards.iso.org/ittf/](http://standards.iso.org/ittf/) -PubliclyAvailableStandards/index.html. -One of the publicly available standards is the -ISO/IEC adoption of the _SWEBOK Guide_ , ISO/ -IEC 19759. - -``` -The definitions contained in ISO/IEC/IEEE -24765, System and Software Vocabulary , are -freely available at http://www.computer.org/sevocab. -However, the vast majority of standards are not -free. ISO/IEC standards are generally purchased -from the national standards organization of the -country in which one lives. For example, in the -US, international standards can be purchased -from the American National Standards Institute -at http://webstore.ansi.org/. Alternatively, stan- -dards can be purchased directly from ISO/IEC -at http://www.iso.org/iso/store.htm. It should be noted -that each individual nation is free to set its own -prices, so it may be helpful to check both sources. -IEEE standards may be available to you for -free if your employer or library has a subscription -to IEEE Xplore: http://ieeexplore.ieee.org/. Some -subscriptions to Xplore provide access only to -the abstracts of standards; the full text may then -be purchased via Xplore. Alternatively, standards -may be purchased via the IEEE standards store at -http://www.techstreet.com/ieeegate.html. It should be -noted that IEEE-SA sometimes bundles standards -into groups available at a substantial discount. -Finally, the reader should note that standards -that IEEE has adopted from ISO/IEC, standards -that ISO/IEC has “fast-tracked” from IEEE, and -standards that were jointly developed or revised -are available from both sources. For all standards -described in this article, the IEEE version and the -ISO/IEC version are substantively identical. The -respective versions may have different front and -back matter but the bodies are identical. -``` -``` -WHERE TO SEE THE SWEBOK GUIDE -``` -``` -The SWEBOK Guide is published under an IEEE -copyright. The current version of the SWEBOK -Guide is available free to the public at http://www. -swebok.org/. The ISO/IEC adoption of the -SWEBOK Guide , ISO/IEC TR 19759, is one of -the freely available standards. -``` - -**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 -Systems and Software Engineering -``` -``` -SW Configuration -Management -IEEE Std. 829-2008 Standard for Software and System Test -Documentation -S W Te s t i n g -``` -``` -IEEE Std. 982.1-2005 Standard for Dictionary of Measures of the -Software Aspects of Dependability -SW Quality -``` -``` -IEEE Std. 1008-1987 Standard for Software Unit Testing S W Te s t i n g -IEEE Std. 1012-2012 Standard for System and Software Verification and -Validation -SW Quality -``` -``` -IEEE Std. 1016-2009 Standard for Information Technology—Systems -Design—Software Design Descriptions -SW Design -``` -``` -IEEE Std. 1028-2008 Standard for Software Reviews and Audits SW Quality -IEEE Std. 1044-2009 Standard for Classification for Software -Anomalies -SW Quality -``` -``` -IEEE Std. 1061-1998 Standard for Software Quality Metrics -Methodology -SW Quality -``` -``` -IEEE Std. 1062-1998 Recommended Practice for Software Acquisition -SW Engineering -Management -IEEE Std. 1074-2006 Standard for Developing a Software Project Life -Cycle Process -``` -``` -SW Engineering -Process -IEEE Std. 1175.1-2002 Guide for CASE Tool Interconnections— -Classification and Description -``` -``` -SW Engineering -Models and Methods -IEEE Std. 1175.2-2006 Recommended Practice for CASE Tool -Interconnection—Characterization of Interconnections -``` -``` -SW Engineering -Models and Methods -IEEE Std. 1175.3-2004 Standard for CASE Tool Interconnections— -Reference Model for Specifying Software Behavior -``` -``` -SW Engineering -Models and Methods -IEEE Std. 1175.4-2008 Standard for CASE Tool Interconnections— -Reference Model for Specifying System Behavior -``` -``` -SW Engineering -Models and Methods -IEEE Std. 1220-2005 (a.k.a. ISO/IEC 26702:2007) Standard for -Application and Management of the Systems Engineering Process -``` -``` -SW Engineering -Process -IEEE Std. 1228-1994 Standard for Software Safety Plans SW Quality -IEEE Std. 1320.1-1998 Standard for Functional Modeling Language— -Syntax and Semantics for IDEF0 -``` -``` -SW Engineering -Models and Methods -IEEE Std. 1320.2-1998 Standard for Conceptual Modeling Language— -Syntax and Semantics for IDEF1X97 (IDEFobject) -``` -``` -SW Engineering -Models and Methods -IEEE Std. 1490-2011 Guide—Adoption of the Project Management -Institute (PMI®) Standard, A Guide to the Project Management Body -of Knowledge (PMBOK® Guide)—Fourth Edition -``` -``` -SW Engineering -Management -``` -``` -IEEE Std. 1517-2010 Standard for Information Technology—System -and Software Life Cycle Processes—Reuse Processes -``` -``` -SW Engineering -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 -Systems and Software Engineering—Software Life Cycle Processes - -``` -SW Engineering -Process -``` -IEEE Std. 14102-2010 Standard Adoption of ISO/IEC 14102:2008 -Information Technology—Guideline for the Evaluation and Selection of -CA SE To ol s - -``` -SW Engineering -Models and Methods -``` -ISO/IEC 14143 [six parts] Information Technology—Software -Measurement—Functional Size Measurement -SW Requirements - -IEEE Std. 14471-2010 Guide—Adoption of ISO/IEC TR 14471:2007 -Information Technology—Software Engineering—Guidelines for the -Adoption of CASE Tools - -``` -SW Engineering -Models and Methods -``` -IEEE Std. 14764-2006 (a.k.a. ISO/IEC 14764:2006) Standard for -Software Engineering—Software Life Cycle Processes—Maintenance -SW Maintenance - -IEEE Std. 15026.1-2011 Trial-Use Standard Adoption of ISO/IEC -TR 15026-1:2010 Systems and Software Engineering—Systems and -Software Assurance—Part 1: Concepts and Vocabulary - -``` -SW Quality -``` -IEEE Std. 15026.2-2011 Standard Adoption of ISO/IEC 15026- -2:2011 Systems and Software Engineering—Systems and Software -Assurance—Part 2: Assurance Case - -``` -SW Quality -``` -ISO/IEC 15026-3 Systems and Software Engineering—Systems and -Software Assurance—Part 3: System Integrity Levels -SW Quality - -ISO/IEC 15026-4:2012 Systems and Software Engineering—Systems -and Software Assurance—Part 4: Assurance in the Life Cycle -SW Quality - -IEEE Std. 15288-2008 (a.k.a. ISO/IEC 15288:2008) Standard for -Systems and Software Engineering—System Life Cycle Processes - -``` -SW Engineering -Process -``` -ISO/IEC/IEEE 15289:2011 Systems and Software Engineering— -Content of Life-Cycle Information Products (Documentation) - -``` -SW Engineering -Process -``` -ISO/IEC 15504 [ten parts] Information Technology—Process -Assessment - -``` -SW Engineering -Process -``` -IEEE Std. 15939-2008 Standard Adoption of ISO/IEC 15939:2007 -Systems and Software Engineering—Measurement Process - -``` -SW Engineering -Management -``` -ISO/IEC 15940:2006 Information Technology—Software Engineering -Environment Services - -``` -SW Engineering -Models and Methods -``` -IEEE Std. 16085-2006 (a.k.a. ISO/IEC 16085:2006) Standard for -Systems and Software Engineering—Software Life Cycle Processes— -Risk Management - -``` -SW Engineering -Management -``` -ISO/IEC/IEEE 16326:2009 Systems and Software Engineering—Life -Cycle Processes—Project Management - -``` -SW Engineering -Management -``` -ISO/IEC 19501:2005 Information Technology—Open Distributed -Processing—Unified Modeling Language (UML) Version 1.4.2 - -``` -SW Engineering -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 -Management Group Unified Modeling Language (OMG UML) -``` -``` -SW Engineering -Models and Methods -ISO/IEC 19506:2012 Information Technology—Object Management -Group Architecture-Driven Modernization (ADM)—Knowledge -Discovery Meta-Model (KDM) -``` -``` -SW Engineering -Models and Methods -``` -``` -ISO/IEC 19507:2012 Information Technology—Object Management -Group Object Constraint Language (OCL) -``` -``` -SW Engineering -Models and Methods -ISO/IEC TR 19759:2005 Software Engineering—Guide to the Software -Engineering Body of Knowledge (SWEBOK) -[General] -``` -``` -ISO/IEC 19761:2011 Software Engineering—COSMIC: A Functional -Size Measurement Method -SW Requirements -``` -``` -ISO/IEC 20000-1:2011 Information Technology—Service -Management—Part 1: Service management system requirements -``` -``` -SW Engineering -Process -ISO/IEC 20926:2009 Software and Systems Engineering—Software -Measurement—IFPUG Functional Size Measurement Method -SW Requirements -``` -``` -ISO/IEC 20968:2002 Software Engineering—Mk II Function Point -Analysis—Counting Practices Manual -SW Requirements -``` -``` -ISO/IEC 24570:2005 Software Engineering—NESMA Functional -Size Measurement Method Version 2.1—Definitions and Counting -Guidelines for the Application of Function Point Analysis -``` -``` -SW Requirements -``` -``` -IEEE Std. 24748.1-2011 Guide—Adoption of ISO/IEC TR 24748-1:2010 -Systems and Software Engineering—Life Cycle Management—Part 1: -Guide for Life Cycle Management -``` -``` -SW Engineering -Process -``` -``` -IEEE Std. 24748.2-2012 Guide—Adoption of ISO/IEC TR 24748-2:2011 -Systems and Software Engineering—Life Cycle Management—Part -2: Guide to the Application of ISO/IEC 15288 (System Life Cycle -Processes) -``` -``` -SW Engineering -Process -``` -``` -IEEE Std. 24748-3:2012 Guide—Adoption of ISO/IEC TR 24748-3:2011 -Systems and Software Engineering—Life Cycle Management—Part -3: Guide to the Application of ISO/IEC 12207 (Software Life Cycle -Processes) -``` -``` -SW Engineering -Process -``` -``` -ISO/IEC/IEEE 24765:2010 Systems and Software -Engineering—Vocabulary -[General] -``` -``` -ISO/IEC TR 24772:2013 Information technology—Programming -Languages — Guidance to Avoiding Vulnerabilities in Programming -Languages through Language Selection and Use -``` -``` -SW Construction -``` -``` -ISO/IEC 24773:2008 Software Engineering—Certification of Software -Engineering Professionals -``` -``` -SW Engineering -Professional Practice -IEEE Std. 24774:2012 Guide—Adoption of ISO/IEC TR 24474:2010 -Systems and Software Engineering—Life Cycle Management— -Guidelines for Process Description -``` -``` -SW Engineering -Process -``` -``` -ISO/IEC 25000:2005 Software Engineering—Software Product Quality -Requirements and Evaluation (SQuaRE)—Guide to SQuaRE -SW Quality -``` - -``` -Appendix B B-31 -``` -**Number and Title (listed in order of number) Most Relevant KA** - -ISO/IEC 25000 through 25099 Software Engineering—Software -Product Quality Requirements and Evaluation (SQuaRE) -SW Quality - -ISO/IEC 25010:2011 Systems and Software Engineering—Systems and -Software Quality Requirements and Evaluation (SQuaRE)—System -and Software Quality Models - -``` -SW Quality -``` -ISO/IEC 25060 through 25064 Software Engineering—Software -Product Quality Requirements and Evaluation (SQuaRE)—Common -Industry Format (CIF) for Usability - -``` -SW Quality -``` -ISO/IEC/IEEE 26511:2012 Systems and Software Engineering— -Requirements for Managers of User Documentation - -``` -SW Engineering -Management -``` -ISO/IEC/IEEE 26512:2011 Systems and Software Engineering— -Requirements for Acquirers and Suppliers of User Documentation - -``` -SW Engineering -Management -``` -IEEE Std. 26513-2010 Standard Adoption of ISO/IEC 26513:2009 -Systems and Software Engineering—Requirements for Testers and -Reviewers of Documentation - -``` -S W Te s t i n g -``` -IEEE Std. 26514-2010 Standard Adoption of ISO/IEC 26514:2008 -Systems and Software Engineering—Requirements for Designers and -Developers of User Documentation - -``` -SW Design -``` -ISO/IEC/IEEE 26515:2012 Systems and Software Engineering— -Developing User Documentation in an Agile Environment - -``` -SW Engineering -Models and Methods -``` -ISO/IEC 29110 [several parts] Software Engineering—Lifecycle -Profiles for Very Small Entities (VSE) - -``` -SW Engineering -Process -``` -ISO/IEC/IEEE 29119 [four parts] (Draft) Software and Systems -Engineering—Software Testing -S W Te s t i n g - -ISO/IEC/IEEE 29148:2011 Systems and Software Engineering—Life -Cycle Processes—Requirements Engineering -SW Requirements - -ISO/IEC/IEEE 42010:2011 Systems and Software Engineering— -Architecture Description -SW Design - -IEEE Std. 90003:2008 Guide—Adoption of ISO/IEC 90003:2004 -Software Engineering—Guidelines for the Application of ISO -9001:2000 to Computer Software - -``` -SW Quality -``` - -``` -C-1 -``` -**APPENDIX C** - -**CONSOLIDATED REFERENCE LIST** - -The Consolidated Reference List identifies all -recommended reference materials (to the level of -section number) that accompany the breakdown -of topics within each knowledge area (KA). This -Consolidated Reference List is adopted by the -software engineering certification and associated -professional development products offered by the -IEEE Computer Society. KA Editors used the ref- -erences allocated to their KA by the Consolidated -Reference List as their Recommended References. -Collectively this Consolidated Reference List is - -- Complete: Covering the entire scope of the - _SWEBOK Guide_. -- Sufficient: Providing enough information to - describe “generally accepted” knowledge. -- Consistent: Not providing contradictory - knowledge nor conflicting practices. -- Credible: Recognized as providing expert - treatment. -- Current: Treating the subject in a manner that - is commensurate with currently generally - accepted knowledge. -- Succinct: As short as possible (both in num- - ber of reference items and in total page - count) without failing other objectives. - -[1*] J.H. Allen et al., _Software Security -Engineering: A Guide for Project -Managers_ , Addison-Wesley, 2008. - -[2*] M. Bishop, _Computer Security: Art and -Science_ , Addison-Wesley, 2002. - -[3*] B. Boehm and R. Turner, _Balancing Agility -and Discipline: A Guide for the Perplexed_ , -Addison-Wesley, 2003. - -``` -[4*] F. Bott et al., Professional Issues in -Software Engineering , 3rd ed., Taylor & -Francis, 2000. -``` -``` -[5*] J.G. Brookshear, Computer Science: An -Overview , 10th ed., Addison-Wesley, 2008. -``` -``` -[6*] D. Budgen, Software Design , 2nd ed., -Addison-Wesley, 2003. -``` -``` -[7*] E.W. Cheney and D.R. Kincaid, Numerical -Mathematics and Computing , 6th ed., -Brooks/Cole, 2007. -``` -``` -[8*] P. Clements et al., Documenting Software -Architectures: Views and Beyond , 2nd ed., -Pearson Education, 2010. -``` -``` -[9*] R.E. Fairley, Managing and Leading -Software Projects , Wiley-IEEE Computer -Society Press, 2009. -``` -``` -[10*] D. Galin, Software Quality Assurance: -From Theory to Implementation , Pearson -Education Limited, 2004. -``` -``` -[11*] E. Gamma et al., Design Patterns: -Elements of Reusable Object-Oriented -Software , 1st ed., Addison-Wesley -Professional, 1994. -``` -``` -[12*] P. Grubb and A.A. Takang, Software -Maintenance: Concepts and Practice , 2nd -ed., World Scientific Publishing, 2003. -``` -``` -[13*] A.M.J. Hass, Configuration Management -Principles and Practices , 1st ed., Addison- -Wesley, 2003. -``` - -**C-2** **_SWEBOK® Guide_** **V3.0** - -[14*] E. Horowitz et al., _Computer Algorithms_ , -2nd ed., Silicon Press, 2007. - -[15*] 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; -[http://www.acm.org/serving/se/code.htm.](http://www.acm.org/serving/se/code.htm.) - -[16*] _IEEE Std. 828-2012, Standard for -Configuration Management in Systems and -Software Engineering_ , IEEE, 2012. - -[17*] _IEEE Std. 1028-2008, Software Reviews -and Audits_ , IEEE, 2008. - -[18*] _ISO/IEC 14764 IEEE Std. 14764-2006, -Software Engineering—Software Life Cycle -Processes—Maintenance_ , IEEE, 2006. - -[19*] S.H. Kan, _Metrics and Models in Software -Quality Engineering_ , 2nd ed., Addison- -Wesley, 2002. - -[20*] S. McConnell, _Code Complete_ , 2nd ed., -Microsoft Press, 2004. - -[21*] J. McGarry et al., _Practical Software -Measurement: Objective Information -for Decision Makers_ , Addison-Wesley -Professional, 2001. - -[22*] S.J. Mellor and M.J. Balcer, _Executable -UML: A Foundation for Model-Driven -Architecture_ , 1st ed., Addison-Wesley, -2002. - -[23*] D.C. Montgomery and G.C. Runger, -_Applied Statistics and Probability for -Engineers_ , 4th ed., Wiley, 2007. - -[24*] J.W. Moore, _The Road Map to Software -Engineering: A Standards-Based Guide_ , 1st -ed., Wiley-IEEE Computer Society Press, -2006. - -``` -[25*] S. Naik and P. Tripathy, Software Testing -and Quality Assurance: Theory and -Practice , Wiley-Spektrum, 2008. -``` -``` -[26*] J. Nielsen, Usability Engineering, 1st ed., -Morgan Kaufmann, 1993. -``` -``` -[27*] L. Null and J. Lobur, The Essentials of -Computer Organization and Architecture , -2nd ed., Jones and Bartlett Publishers, -2006. -``` -``` -[28*] M. Page-Jones, Fundamentals of Object- -Oriented Design in UML , 1st ed., Addison- -Wesley, 1999. -``` -``` -[29*] K. Rosen, Discrete Mathematics and Its -Applications, 7th ed., McGraw-Hill, 2011. -``` -``` -[30*] A. Silberschatz, P.B. Galvin, and G. -Gagne, Operating System Concepts , 8th -ed., Wiley, 2008. -``` -``` -[31*] H.M. Sneed, “Offering Software -Maintenance as an Offshore Service,” Proc. -IEEE Int’l Conf. Software Maintenance -(ICSM 08), IEEE, 2008, pp. 1–5. -``` -``` -[32*] I. Sommerville, Software Engineering , 9th -ed., Addison-Wesley, 2011. -``` -``` -[33*] S. Tockey, Return on Software: -Maximizing the Return on Your Software -Investment , 1st ed., Addison-Wesley, 2004. -``` -``` -[34*] G. Voland, Engineering by Design , 2nd -ed., Prentice Hall, 2003. -``` -``` -[35*] K.E. Wiegers, Software Requirements , 2nd -ed., Microsoft Press, 2003. -``` -``` -[36*] J.M. Wing, “A Specifier’s Introduction to -Formal Methods,” Computer , vol. 23, no. 9, -1990, pp. 8, 10–23. -``` blob - 5d4f062b2e8021db1f6eb48c86a94fcc094c26a9 (mode 644) blob + /dev/null --- epub.css +++ /dev/null @@ -1,74 +0,0 @@ -body { - margin: auto; - padding-right: 1em; - padding-left: 1em; - max-width: 80%; - border-left: 1px solid black; - border-right: 1px solid black; - color: black; - font-family: Verdana, sans-serif; - font-size: 100%; - line-height: 140%; - color: #333; -} -pre { - border: 1px dotted gray; - background-color: #ececec; - color: #1111111; - padding: 0.5em; -} -code { - font-family: monospace; -} -h1 a, h2 a, h3 a, h4 a, h5 a { - text-decoration: none; - color: #7a5ada; -} -h1, h2, h3, h4, h5 { font-family: verdana; - font-weight: bold; - border-bottom: 1px dotted black; - color: #7a5ada; } -h1 { - font-size: 130%; -} - -h2 { - font-size: 110%; -} - -h3 { - font-size: 95%; -} - -h4 { - font-size: 90%; - font-style: italic; -} - -h5 { - font-size: 90%; - font-style: italic; -} - -h1.title { - font-size: 200%; - font-weight: bold; - padding-top: 0.2em; - padding-bottom: 0.2em; - text-align: left; - border: none; -} - -dt code { - font-weight: bold; -} -dd p { - margin-top: 0; -} - -#footer { - padding-top: 1em; - font-size: 70%; - color: gray; - text-align: center; - } blob - 3f28571536133655c9bc6db32dadf68f5e6e00f6 (mode 644) blob + /dev/null Binary files images/SWEBOK_logo_v2.jpg and /dev/null differ blob - 2c3d865680ab9d542f0a570550d93ae096be3ee3 (mode 644) blob + /dev/null --- title.txt +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: Guide to the Software Engineering Body of Knowledge Version 3. -rights: Copyright 2014 IEEE. All rights reserved. -language: en-US