SWEBOKv 3

Appendix B
B-1
Guide to the Software Engineering
Body of Knowledge
Version 3.0
SWEBOK
A Project of the IEEE Computer Society

Guide to the Software Engineering
Body of Knowledge
Version 3.0
Editors
Pierre Bourque, cole de technologie suprieure (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-1
Paperback ISBN-13: 978-0-7695-5166-1
Digital copies of SWEBOK Guide V3.0 may be downloaded free of charge for personal and academic use via
www.swebok.org.
IEEE Computer Society Staff for This Publication

Angela Burgess, Executive Director
Anne Marie Kelly, Associate Executive Director, Director of Governance
Evan M. Butterfield, Director of Products and Services
John Keppler, Senior Manager, Professional Education
Kate Guillemette, Product Development Editor
Dorian McClenahan, Education Program Product Developer
Michelle Phon, Professional Education & Certification Program Coordinator
Jennie Zhu-Mai, Editorial Designer
IEEE Computer Society Products and Services. The world-renowned IEEE Computer Society publishes, promotes, and
distributes a wide variety of authoritative computer science and engineering journals, magazines, conference proceedings, and
professional education products. Visit the Computer Society at www.computer.or g for more information.
TABLE OF CONTENTS
Foreword xvii
Foreword to the 2004 Edition xix
Editors xxi
Coeditors xxi
Contributing Editors xxi
Change Control Board xxi

Knowledge Area Editors xxiii
Knowledge Area Editors of Previous SWEBOK Versions xxv
Review Team xxvii
Acknowledgements xxix
Professional Activities Board, 2013 Membership xxix
Motions Regarding the Approval of SWEBOK Guide V3.0 xxx
Motions Regarding the Approval of SWEBOK Guide 2004 Version xxx
Introduction to the Guide xxxi
Chapter 1: Software Requirements 1-1
1.Software Requirements Fundamentals 1-1
1.1. DefinitionofaSoftwareRequirement 1-1
1.2. ProductandProcessRequirements 1-2
1.3. FunctionalandNonfunctionalRequirements 1-3
1.4. EmergentProperties 1-3
1.5. QuantifiableRequirements 1-3
1.6. SystemRequirementsandSoftwareRequirements 1-3
2.Requirements Process 1-3
2.1. ProcessModels 1-4
2.2. ProcessActors 1-4
2.3. ProcessSupportandManagement 1-4
2.4. ProcessQualityandImprovement 1-4
3.Requirements Elicitation 1-5
3.1. RequirementsSources 1-5
3.2. ElicitationTechniques 1-6
4.Requirements Analysis 1-7
4.1. RequirementsClassification 1-7
4.2. ConceptualModeling 1-8
4.3. ArchitecturalDesignandRequirementsAllocation 1-9
4.4. RequirementsNegotiation 1-9

4.5. FormalAnalysis 1-10
5.Requirements Specification 1-10
5.1. SystemDefinitionDocument 1-10
5.2. SystemRequirementsSpecification 1-10
5.3. SoftwareRequirementsSpecification 1-11
6.Requirements Validation 1-11
6.1. RequirementsReviews 1-11
6.2. Prototyping 1-12

v
6
SWEBOK Guide V3.0
6.3.ModelValidation 1-
12
6.4.AcceptanceTests 1-
12
7. Practical Considerations 1-12
7.1.IterativeNatureoftheRequirementsProcess 1-
13
7.2.ChangeManagement 1-
13
7.3.RequirementsAttributes 1-
13
7.4.RequirementsTracing 1-
14
7.5.MeasuringRequirements 1-
14
8. Software Requirements Tools 1-14
Matrix of Topics vs. Reference Material 1-15
2-
Chapter 2: Software Design 1
1. Software Design Fundamentals 2-2
1.1.GeneralDesignConcepts 2-
2
1.2.ContextofSoftwareDesign 2-
2
1.3.SoftwareDesignProcess 2-
2
1.4.SoftwareDesignPrinciples 2-
3
2. Key Issues in Software Design 2-3
2.1.Concurrency 2-
4
2.2.ControlandHandlingofEvents 2-
4
2.3.DataPersistence 2-
4
2.4.DistributionofComponents 2-
4
2.5.ErrorandExceptionHandlingandFaultTolerance 2-
4
2.6.InteractionandPresentation 2-
4
2.7.Security 2-
4
3. Software Structure and Architecture 2-4
3.1.ArchitecturalStructuresandViewpoints 2-
5
3.2.ArchitecturalStyles 2-
Table of Contents 7
5
3.3.DesignPatterns 2-
5
3.4.ArchitectureDesignDecisions 2-
5
3.5.FamiliesofProgramsandFrameworks 2-
5
4. User Interface Design 2-5
4.1.GeneralUserInterfaceDesignPrinciples 2-
6
4.2.UserInterfaceDesignIssues 2-
6
4.3.TheDesignofUserInteractionModalities 2-
6
4.4.TheDesignofInformationPresentation 2-
6
4.5.UserInterfaceDesignProcess 2-
7
4.6.LocalizationandInternationalization 2-
7
4.7.MetaphorsandConceptualModels 2-
7
5. Software Design Quality Analysis and Evaluation 2-7
5.1.QualityAttributes 2-
7
5.2.QualityAnalysisandEvaluationTechniques 2-
8
5.3.Measures 2-
8
6. Software Design Notations 2-8
6.1.StructuralDescriptions(StaticView) 2-
8
6.2.BehavioralDescriptions(DynamicView) 2-
9
7. Software Design Strategies and Methods 2-10
7.1.GeneralStrategies 2-
10
7.2.Function-Oriented(Structured)Design 2-
10
7.3.Object-OrientedDesign 2-
10
7.4.DataStructure-CenteredDesign 2-
10
7.5.Component-BasedDesign(CBD) 2-
10
7.6.OtherMethods 2-
10
8. Software Design Tools 2-11
8

3-
Chapter 3: Software Construction 1
1. Software Construction Fundamentals 3-1
1.1.MinimizingComplexity 3-
3
1.2.AnticipatingChange 3-
3
1.3.ConstructingforVerification 3-
3
1.4.Reuse 3-
3
1.5.StandardsinConstruction 3-
3
2. Managing Construction 3-4
2.1.ConstructioninLifeCycleModels 3-
4
2.2.ConstructionPlanning 3-
4
2.3.ConstructionMeasurement 3-
4
3.1.ConstructionDesign 3-
5
3.2.ConstructionLanguages 3-
5
3.3.Coding 3-
6
3.4.ConstructionTesting 3-
6
3.5.ConstructionforReuse 3-
6
3.6.ConstructionwithReuse 3-
7
3.7.ConstructionQuality 3-
7
3.8.Integration 3-
7
4. Construction Technologies 3-8
4.1.APIDesignandUse 3-
8
4.2.Object-OrientedRuntimeIssues 3-
8
4.3.ParameterizationandGenerics 3-
8
4.4.Assertions,DesignbyContract,andDefensiveProgramming 3-
8
4.5.ErrorHandling,ExceptionHandling,andFaultTolerance 3-
9
Table of Contents 9
4.6.ExecutableModels 3-
9
4.7.State-BasedandTable-DrivenConstructionTechniques 3-
9
4.8.RuntimeConfigurationandInternationalization 3-
10
4.9.Grammar-BasedInputProcessing 3-
10
4.10.ConcurrencyPrimitives 3-
10
4.11.Middleware 3-
10
4.12.ConstructionMethodsforDistributedSoftware 3-
11
4.13.ConstructingHeterogeneousSystems 3-
11
4.14.PerformanceAnalysisandTuning 3-
11
4.15.PlatformStandards 3-
11
4.16.Test-FirstProgramming 3-
11
5. Software Construction Tools 3-12
5.1.DevelopmentEnvironments 3-
12
5.2.GUIBuilders 3-
12
5.3.UnitTestingTools 3-
12
5.4.Profiling,PerformanceAnalysis,andSlicingTools 3-
12
SWEBOK Guide V3.0
Chapter 4: Software Testing 4-

1
1. Software Testing Fundamentals 4-3
1.1.Testing-RelatedTerminology 4-
3
1.2.KeyIssues 4-
3
1.3.RelationshipofTestingtoOtherActivities 4-
4
2. Test Levels 4-5
2.1.TheTargetoftheTest 4-
5
2.2.ObjectivesofTesting 4-
5
3. Test Techniques 4-7
10
3.1.BasedontheSoftwareEngineersIntuitionandExperience 4-
8
3.2.InputDomain-BasedTechniques 4-
8
3.3.Code-BasedTechniques 4-
8
3.4.Fault-BasedTechniques 4-
9
3.5.Usage-BasedTechniques 4-
9
3.6.Model-BasedTestingTechniques 4-
10
3.7.TechniquesBasedontheNatureoftheApplication 4-
10
3.8.SelectingandCombiningTechniques 4-
11
4. Test-Related Measures 4-11
4.1.EvaluationoftheProgramUnderTest 4-
11
4.2.EvaluationoftheTestsPerformed 4-
12
5. Test Process 4-12
5.1.PracticalConsiderations 4-
13
5.2.TestActivities 4-
14
6. Software Testing Tools 4-15
6.1.TestingToolSupport 4-
15
6.2.CategoriesofTools 4-
15
5-
Chapter 5: Software Maintenance 1
1. Software Maintenance Fundamentals 5-1
1.1.DefinitionsandTerminology 5-
1
1.2.NatureofMaintenance 5-
2
1.3.NeedforMaintenance 5-
3
1.4.MajorityofMaintenanceCosts 5-
3
1.5.EvolutionofSoftware 5-
3
1.6.CategoriesofMaintenance 5-
3
2. Key Issues in Software Maintenance 5-4
2.1.TechnicalIssues 5-
Table of Contents 11
4
2.2.ManagementIssues 5-
5
2.3.MaintenanceCostEstimation 5-
6
2.4.SoftwareMaintenanceMeasurement 5-
7
3. Maintenance Process 5-7
3.1.MaintenanceProcesses 5-
7
3.2.MaintenanceActivities 5-
8
4. Techniques for Maintenance 5-10
4.1.ProgramComprehension 5-
10
4.2.Reengineering 5-
10
4.3.ReverseEngineering 5-
10
4.4.Migration 5-
10
4.5.Retirement 5-
11
5. Software Maintenance Tools 5-11

6-
Chapter 6: Software Configuration Management 1
1. Management of the SCM Process 6-2
1.1.OrganizationalContextforSCM 6-
2
1.2.ConstraintsandGuidancefortheSCMProcess 6-
3
1.3.PlanningforSCM 6-
3
1.4.SCMPlan 6-
5
1.5.SurveillanceofSoftwareConfigurationManagement 6-
5
2. Software Configuration Identification 6-6
2.1.IdentifyingItemstoBeControlled 6-
6
2.2.SoftwareLibrary 6-
8
3. Software Configuration Control 6-8
3.1.Requesting,Evaluating,andApprovingSoftwareChanges 6-
8
3.2.ImplementingSoftwareChanges 6-
9
12
3.3.DeviationsandWaivers 6-
10
4. Software Configuration Status Accounting 6-10
4.1.SoftwareConfigurationStatusInformation 6-
10
4.2.SoftwareConfigurationStatusReporting 6-
10
5. Software Configuration Auditing 6-10
5.1.SoftwareFunctionalConfigurationAudit 6-
11
5.2.SoftwarePhysicalConfigurationAudit 6-
11
5.3.In-ProcessAuditsofaSoftwareBaseline 6-
11
6. Software Release Management and Delivery 6-11
6.1.SoftwareBuilding 6-
11
6.2.SoftwareReleaseManagement 6-
12
7. Software Configuration Management Tools 6-12
7-
Chapter 7: Software Engineering Management 1
1. Initiation and Scope Definition 7-4
1.1.DeterminationandNegotiationofRequirements 7-
4
1.2.FeasibilityAnalysis 7-
4
1.3.ProcessfortheReviewandRevisionofRequirements 7-
5
2. Software Project Planning 7-5
2.1.ProcessPlanning 7-
5
2.2.DetermineDeliverables 7-
5
2.3.Effort,Schedule,andCostEstimation 7-
6
2.4.ResourceAllocation 7-
6
2.5.RiskManagement 7-
6
2.6.QualityManagement 7-
6
2.7.PlanManagement 7-
7
3. Software Project Enactment 7-7
3.1.ImplementationofPlans 7-
7
3.2.SoftwareAcquisitionandSupplierContractManagement 7-
7
3.3.ImplementationofMeasurementProcess 7-
7
3.4.MonitorProcess 7-
7
3.5.ControlProcess 7-
8
3.6.Reporting 7-
8
SWEBOK Guide V3.0
4. Review and Evaluation 7-8

4.1.DeterminingSatisfactionofRequirements 7-
8
4.2.ReviewingandEvaluatingPerformance 7-
9
5. Closure 7-9
5.1.DeterminingClosure 7-
9
5.2.ClosureActivities 7-
9
6. Software Engineering Measurement 7-9
6.1.EstablishandSustainMeasurementCommitment 7-
9
6.2.PlantheMeasurementProcess 7-
10
6.3.PerformtheMeasurementProcess 7-
11
6.4.EvaluateMeasurement 7-
11
7. Software Engineering Management Tools 7-11
8-
Chapter 8: Software Engineering Process 1
1. Software Process Definition 8-2
1.1.SoftwareProcessManagement 8-
3
1.2.SoftwareProcessInfrastructure 8-
4
2. Software Life Cycles 8-4
2.1.CategoriesofSoftwareProcesses 8-
5
2.2.SoftwareLifeCycleModels 8-
5
2.3.SoftwareProcessAdaptation 8-
6
2.4.PracticalConsiderations 8-
6
3. Software Process Assessment and Improvement 8-6
14
3.1.SoftwareProcessAssessmentModels 8-
7
3.2.SoftwareProcessAssessmentMethods 8-
7
3.3.SoftwareProcessImprovementModels 8-
7
3.4.ContinuousandStagedSoftwareProcessRatings 8-
8
4. Software Measurement 8-8
4.1.SoftwareProcessandProductMeasurement 8-
9
4.2.QualityofMeasurementResults 8-
10
4.3.SoftwareInformationModels 8-
10
4.4.SoftwareProcessMeasurementTechniques 8-
11
5. Software Engineering Process Tools 8-12
9-
Chapter 9: Software Engineering Models and Methods 1
1. Modeling 9-1
1.1.ModelingPrinciples 9-
2
1.2.PropertiesandExpressionofModels 9-
3
1.3.Syntax,Semantics,andPragmatics 9-
3
1.4.Preconditions,Postconditions,andInvariants 9-
4
2. Types of Models 9-4
2.1.InformationModeling 9-
5
2.2.BehavioralModeling 9-
5
2.3.StructureModeling 9-
5
3. Analysis of Models 9-5
3.1.AnalyzingforCompleteness 9-
5
3.2.AnalyzingforConsistency 9-
6
3.3.AnalyzingforCorrectness 9-6
3.4.Traceability 9-6
3.5.InteractionAnalysis 9-6
4. Software Engineering Methods 9-7
4.1.HeuristicMethods 9-7
4.2.FormalMethods 9-7
4.3.PrototypingMethods 9-8
4.4.AgileMethods 9-9
10-
Chapter 10: Software Quality 1
1. Software Quality Fundamentals 10-2
1.1.SoftwareEngineeringCultureandEthics 10-
2
1.2.ValueandCostsofQuality 10-
3
1.3.ModelsandQualityCharacteristics 10-
3
1.4.SoftwareQualityImprovement 10-
4
1.5.SoftwareSafety 10-
4
2. Software Quality Management Processes 10-5
2.1.SoftwareQualityAssurance 10-
5
2.2.Verification&Validation 10-
6
2.3.ReviewsandAudits 10-
6
3.1.SoftwareQualityRequirements 10-
9
3.2.DefectCharacterization 10-
10
3.3.SoftwareQualityManagementTechniques 10-
11
3.4.SoftwareQualityMeasurement 10-
12
4. Software Quality Tools 10-12
11-
Chapter 11: Software Engineering Professional Practice 1
1. Professionalism 11-2
1.1.Accreditation,Certification,andLicensing 11-
3
1.2.CodesofEthicsandProfessionalConduct 11-
4
1.3.NatureandRoleofProfessionalSocieties 11-
4
1.4.NatureandRoleofSoftwareEngineeringStandards 11-
4
1.5.EconomicImpactofSoftware 11-
5
1.6.EmploymentContracts 11-
5
16
1.7.LegalIssues 11-
5
1.8.Documentation 11-
7
1.9.TradeoffAnalysis 11-
8
2. Group Dynamics and Psychology 11-9
2.1.DynamicsofWorkinginTeams/Groups 11-
9
2.2.IndividualCognition 11-
9
2.3.DealingwithProblemComplexity 11-
10
2.4.InteractingwithStakeholders 11-
10
2.5.DealingwithUncertaintyandAmbiguity 11-
10
2.6.DealingwithMulticulturalEnvironments 11-
10
3. Communication Skills 11-11
3.1.Reading,Understanding,andSummarizing 11-
11
3.2.Writing 11-
11
3.3.TeamandGroupCommunication 11-
11
3.4.PresentationSkills 11-
12
12-
Chapter 12: Software Engineering Economics 1
1. Software Engineering Economics Fundamentals 12-3
1.1.Finance 12-
3
1.2.Accounting 12-
3
1.3.Controlling 12-
3
1.4.CashFlow 12-
3
1.5.Decision-MakingProcess 12-
4
1.6.Valuation 12-
5
1.7.Inflation 12-
6
1.8.Depreciation 12-
6
1.9.Taxation 12-
6
1.10.Time-ValueofMoney 12-
6
1.11.Efficiency 12-
6
1.12.Effectiveness 12-
6
1.13.Productivity 12-
6
2. Life Cycle Economics 12-7
2.1.Product 12-
7
2.2.Project 12-
7
2.3.Program 12-
7
2.4.Portfolio 12-
7
2.5.ProductLifeCycle 12-
7
2.6.ProjectLifeCycle 12-
18 SWEBOK Guide V3.0
7
2.7.Proposals 12-
8
2.8.InvestmentDecisions 12-
8
2.9.PlanningHorizon 12-
8
2.10.PriceandPricing 12-
8
2.11.CostandCosting 12-
9
2.12.PerformanceMeasurement 12-
9
2.13.EarnedValueManagement 12-
9
2.14.TerminationDecisions 12-
9
2.15.ReplacementandRetirementDecisions 12-
10
3. Risk and Uncertainty 12-10
3.1.Goals,Estimates,andPlans 12-
10
3.2.EstimationTechniques 12-
11
3.3.AddressingUncertainty 12-
11
3.4.Prioritization 12-
11
3.5.DecisionsunderRisk 12-
11
3.6.DecisionsunderUncertainty 12-
12
4. Economic Analysis Methods 12-12
4.1.For-ProfitDecisionAnalysis 12-
12
4.2.MinimumAcceptableRateofReturn 12-
13
4.3.ReturnonInvestment 12-
13
4.4.ReturnonCapitalEmployed 12-
13
4.5.Cost-BenefitAnalysis 12-
13
4.6.Cost-EffectivenessAnalysis 12-
13
4.7.Break-EvenAnalysis 12-
13
4.8.BusinessCase 12-
13
4.9.MultipleAttributeEvaluation 12-
14
4.10.OptimizationAnalysis 12-
14
5.1.TheGoodEnoughPrinciple 12-
14
5.2.Friction-FreeEconomy 12-
15
5.3.Ecosystems 12-
15
5.4.OffshoringandOutsourcing 12-
15
13-
Chapter 13: Computing Foundations 1
1. Problem Solving Techniques 13-3
1.1.DefinitionofProblemSolving 13-
3
1.2.FormulatingtheRealProblem 13-
3
1.3.AnalyzetheProblem 13-
3
1.4.DesignaSolutionSearchStrategy 13-
3
1.5.ProblemSolvingUsingPrograms 13-
3
2. Abstraction 13-4
2.1.LevelsofAbstraction 13-
4
2.2.Encapsulation 13-
4
2.3.Hierarchy 13-
4
2.4.AlternateAbstractions 13-
5
3. Programming Fundamentals 13-5
3.1.TheProgrammingProcess 13-
5
3.2.ProgrammingParadigms 13-
5
4. Programming Language Basics 13-6
4.1.ProgrammingLanguageOverview 13-
6
4.2.SyntaxandSemanticsofProgrammingLanguages 13-
6
4.3.Low-LevelProgrammingLanguages 13-
7
4.4.High-LevelProgrammingLanguages 13-
7
4.5.Declarativevs.ImperativeProgrammingLanguages 13-
7
5. Debugging Tools and Techniques 13-8
5.1.TypesofErrors 13-
8
5.2.DebuggingTechniques 13-
8
5.3.DebuggingTools 13-
8
6. Data Structure and Representation 13-9
6.1.DataStructureOverview 13-
9
6.2.TypesofDataStructure 13-
9
6.3.OperationsonDataStructures 13-
9
7. Algorithms and Complexity 13-10
7.1.OverviewofAlgorithms 13-
10
7.2.AttributesofAlgorithms 13-
10
7.3.AlgorithmicAnalysis 13-
10
7.4.AlgorithmicDesignStrategies 13-
11
7.5.AlgorithmicAnalysisStrategies 13-
11
8. Basic Concept of a System 13-11
8.1.EmergentSystemProperties 13-
11
8.2.SystemsEngineering 13-
12
8.3.OverviewofaComputerSystem 13-
12
9. Computer Organization 13-13
9.1.ComputerOrganizationOverview 13-
13
9.2.DigitalSystems 13-
13
9.3.DigitalLogic 13-
13
9.4.ComputerExpressionofData 13-
13
9.5.TheCentralProcessingUnit(CPU) 13-
14
9.6.MemorySystemOrganization 13-
14
9.7.InputandOutput(I/O) 13-
14
10. Compiler Basics 13-15
10.1.Compiler/InterpreterOverview 13-
15
10.2.InterpretationandCompilation 13-
15
10.3.TheCompilationProcess 13-
15
11. Operating Systems Basics 13-16
11.1.OperatingSystemsOverview 13-
16
11.2.TasksofanOperatingSystem 13-
16
11.3.OperatingSystemAbstractions 13-
17
11.4.OperatingSystemsClassification 13-
17
12. Database Basics and Data Management 13-17
12.1.EntityandSchema 13-
18
12.2.DatabaseManagementSystems(DBMS) 13-
18
12.3.DatabaseQueryLanguage 13-
18
12.4.TasksofDBMSPackages 13-
18
12.5.DataManagement 13-
19
12.6.DataMining 13-
19
13. Network Communication Basics 13-19
13.1.TypesofNetwork 13-
19
13.2.BasicNetworkComponents 13-
19
13.3.NetworkingProtocolsandStandards 13-
20
13.4.TheInternet 13-
20
13.5.InternetofThings 13-
20
13.6.VirtualPrivateNetwork(VPN) 13-
21
14. Parallel and Distributed Computing 13-21
14.1.ParallelandDistributedComputingOverview 13-
21
14.2.DifferencebetweenParallelandDistributedComputing 13-
21
14.3.ParallelandDistributedComputingModels 13-
21
14.4.MainIssuesinDistributedComputing 13-
22
15. Basic User Human Factors 13-22
15.1.InputandOutput 13-
22
15.2.ErrorMessages 13-
23
15.3.SoftwareRobustness 13-
23
16. Basic Developer Human Factors 13-23
16.1.Structure 13-
24
16.2.Comments 13-
24
17. Secure Software Development and Maintenance 13-24
17.1.SoftwareRequirementsSecurity 13-
24
17.2.SoftwareDesignSecurity 13-
25
17.3.SoftwareConstructionSecurity 13-
25
17.4.SoftwareTestingSecurity 13-
25
17.5.BuildSecurityintoSoftwareEngineeringProcess 13-
25
17.6.SoftwareSecurityGuidelines 13-
25
14-
Chapter 14: Mathematical Foundations 1
1. Set, Relations, Functions 14-1
1.1.SetOperations 14-
2
1.2.PropertiesofSet 14-
3
1.3.RelationandFunction 14-
4
2. Basic Logic 14-5
2.1.PropositionalLogic 14-
5
2.2.PredicateLogic 14-
5
3. Proof Techniques 14-6
3.1.MethodsofProvingTheorems 14-
6
4. Basics of Counting 14-7
5. Graphs and Trees 14-8
5.1.Graphs 14-
8
5.2.Trees 14-
10
6. Discrete Probability 14-13
7. Finite State Machines 14-14
8. Grammars 14-15
8.1.LanguageRecognition 14-
16
9. Numerical Precision, Accuracy, and Errors 14-17
10. Number Theory 14-18
10.1.Divisibility 14-
18
10.2.PrimeNumber,GCD 14-
19
11. Algebraic Structures 14-19
11.1.Group 14-
19
11.2.Rings 14-
20
15-
Chapter 15: Engineering Foundations 1
1. Empirical Methods and Experimental Techniques 15-1
1.1.DesignedExperiment 15-
1
1.2.ObservationalStudy 15-
2
1.3.RetrospectiveStudy 15-
2
2. Statistical Analysis 15-2
2.1.UnitofAnalysis(SamplingUnits),Population,andSample 15-
2
2.2.ConceptsofCorrelationandRegression 15-
5
3. Measurement 15-5
3.1.Levels(Scales)ofMeasurement 15-
6
3.2.DirectandDerivedMeasures 15-
7
3.3.ReliabilityandValidity 15-
8
3.4.AssessingReliability 15-
8
4. Engineering Design 15-8
4.1.EngineeringDesigninEngineeringEducation 15-
8
4.2.DesignasaProblemSolvingActivity 15-
9
4.3.StepsInvolvedinEngineeringDesign 15-
9
5. Modeling, Simulation, and Prototyping 15-10
5.1.Modeling 15-
10
5.2.Simulation 15-
11
5.3.Prototyping 15-
11
6. Standards 15-12
7. Root Cause Analysis 15-12
7.1.TechniquesforConductingRootCauseAnalysis 15-
13
A-
Appendix A: Knowledge Area Description Specifications
1
Appendix B: IEEE and ISO/IEC Standards Supporting the Software Engineering
Body of Knowledge (SWEBOK) B-
1
C-
Appendix C: Consolidated Reference List 1
FOREWOR
D
Every purposes
profession as
is based on developme
a body of nt and
knowledge accreditati
, although on of
that academic
knowledge and
is not training
always programs,
defined in certificatio
a concise n of
manner. In specialists,
cases or
where no professiona
formality l licensing.
exists, the Generally,
body of a
knowledge professiona
is l society or
generally similar
recognized body
by maintains
practitioner stewardshi
s and may p of the
be codified formal
in a variety definition
of ways for of a body
a variety of of
different knowledge
uses. But .
in many During
cases, a the past
guide to a forty-five
body of years,
knowledge software
is formally engineerin
documente g has
d, usually evolved
in a form from a
that conference
permits it catchphras
to be used e into an
for such engineerin
g , the IEEE
profession, Computer
characteriz Society
ed by 1) a presents a
professiona revised and
l society, 2) updated
standards version of
that specify the body of
generally knowledge
accepted formerly
professiona documente
l practices, d as
3) a code SWEBOK
of ethics, 2004; this
4) revised and
conference updated
proceeding version is
s, 5) denoted
textbooks, SWEBOK
6) V3. This
curriculum work is in
guidelines partial
and fulfillment
curricula, of the
7) Societys
accreditatio responsibil
n criteria ity to
and promote
accredited the
degree advanceme
programs, nt of both
8) theory and
certificatio practice for
n and
the
licensing,
profession
and 9) this
of software
Guide to
engineerin
the Body
g.
of
It should
Knowledge
be noted
.
that this
In this
Guideto Guide does
the not present
Software the entire
Engineerin the body of
gBodyof knowledge
Knowledge for
software conference
engineerin held in
g but rather Germany
serves as a in 1968.
guide to The IEEE
the body of Computer
knowledge Society
that has first
been published
developed its
over more Transactio
than four nson
decades. Software
The Engineerin
software g in 1972,
engineerin and a
g body of committee
knowledge for
is developing
constantly software
engineerin
evolving.
g standards
Neverthele
was
ss, this
established
Guide
within the
constitutes
IEEE
a valuable
Computer
characteriz
Society in
ation of the
1976.
software
In 1990,
engineerin
planning
g was begun
profession. for an
In 1958, internation
John al standard
Tukey, the to provide
world- an overall
renowned view of
statistician, software
coined the engineerin
term g. The
software. standard
The term was
software completed
engineerin in 1995
g was used with
in the title designation
of a NATO ISO/IEC
12207 and mechanism
given the for
title of acquiring
Standard the
for knowledge
Software you need
LifeCycle in your
Processes. lifelong
The IEEE career
version of developme
12207 was nt as a
published software
in 1996 engineerin
and g
provided a professiona
major l.
foundation
for the
body of Dick
knowledge Fairley,
captured in Chair
SWEBOK Software
2004. The and
current Systems
version of Engineerin
12207 is g
designated
Committee
as ISO/IEC
IEEE
12207:200
Computer
8 and IEEE
Society
12207-
2008; it
provides
Don
the basis
Shafer,
for this
Vice
SWEBOK
President
V3.
Pr
This
of
Guideto
es
the
si
Software
o
Engineerin
n
gBodyof
al
Knowledge

is
A
presented
ct
to you, the
iv
reader, as a
iti o
es m
p
B ut
o er
ar
d S
IE oc
E ie
E ty
C
xvii
FOREWOR
D TO THE
2004
EDITION
In ge
this for
Gui the
de, field
the of
IEE soft
E ware
Com engi
pute neer
r ing,
Soci and
ety the
esta wor
blish k
es parti
for ally
the fulfi
first lls
time the
a Soci
base etys
line resp
for onsi
the bilit
bod y to
y of pro
kno mot
wled e the
adva or
nce their
men solut
t of ions.
both It
theo shou
ry ld be
and note
prac d
tice that
in the
this Gui
field de
. In does
so not
doin purp
g, ort
the to
Soci defi
ety ne
has the
been bod
guid y of
ed kno
by
wled
the
ge
expe
but
rien
rathe
ce
r to
of
serv
disci
e as
plin
a
es
with com
long pend
er ium
histo and
ries guid
but e to
was the
not bod
bou y of
nd kno
eithe wled
r by ge
their that
prob has
lems been
deve neve
lopi rthel
ng ess
and cons
evol titut
ving es a
over valu
the able
past elem
four ent
deca of
des. the
Furt soft
her ware
mor engi
e, neeri
this ng
bod infra
y of struc
kno ture.
wled In
ge is 1958
not ,
stati John
c. Tuke
The y,
Gui the
de worl
must d-
, reno
nece wne
ssari d
ly, stati
deve stici
lop an,
and coin
evol ed
ve the
as term
soft soft
ware war
e.
engi
The
neeri
term
ng
soft
matu
war
res.
e
It
engi
neer ee
ing esta
was blish
used ed
in with
the in
title the
of a IEE
NAT E
O Com
conf pute
eren r
ce Soci
held ety
in for
Ger deve
man lopi
y in ng
1968 soft
. ware
The engi
IEE neeri
E ng
Com stan
pute dard
r s
Soci was
ety foun
first ded
publ in
ishe 1976
d its .
Tran Th
sacti e
ons first
on holis
Soft tic
war view
e of
Engi soft
neer ware
ing engi
in neeri
1972 ng
. to
The emer
com ge
mitt from
the E
IEE Std.
E 730
Com was
pute to
r prov
Soci ide
ety unif
resul orm,
ted mini
from mu
an m
effor acce
t led ptabl
by e
Fletc requ
her irem
Buc ents
kley for
to prep
deve arati
lop on
IEE and
E cont
stan ent
dard of
730 soft
for ware
soft quali
ware ty
quali assu
ty ranc
assu e
ranc plan
e, s.
whic This
h stan
was dard
com was
plete influ
d in entia
1979 l in
. com
The pleti
purp ng
ose the
of deve
IEE lopi
ng IEE
stan E
dard Com
s in pute
the r
follo Soci
wing ety
topic held
s: a
conf serie
igur s of
ation wor
man ksho
age ps
ment conc
, erni
soft ng
ware the
testi appli
ng, catio
soft n of
ware
soft
requ
ware
irem
engi
ents,
neeri
soft
ng
ware
stan
desi
dard
gn,
s.
and
soft Thes
ware e
verif wor
icati ksho
on ps
and invo
valid lved
ation pract
. ition
D ers
urin shari
g the ng
peri their
od expe
1981 rienc
es
1985 with
, the exist
ing ning
stan also
dard resul
s. ted
The in
wor IEE
ksho E
ps Std.
also 1002
held ,
sessi Tax
ons ono
on my
plan of
ning Soft
for war
futur e
e Engi
stan neer
dard ing
s, Stan
inclu dard
ding s
one (198
invo 6),
lvin whic
g h
mea prov
sure ided
s a
and new,
metr holis
ics tic
for view
soft of
ware soft
engi ware
neeri engi
ng neeri
prod ng.
ucts The
and stan
proc dard
esse desc
s. ribes
The the
plan form
and parti
cont cipat
ent ing
of a in
soft the
ware soft
engi ware
neeri life
ng cycl
stan e.
dard In 1990,
s planning
taxo for an
nom internation
y. It al standard
expl with an
ains overall
the view was
vari begun. The
ous planning
type focused on
s of reconciling
soft the
ware software
engi process
neeri views from
ng IEEE Std.
stan 1074 and
dard the revised
s, US DoD
their standard
2167A.
func
The
tiona
revision
l and
was
exter
eventually
nal
published
relat
as DoD
ions
Std. 498.
hips,
The
and
internation
the al standard
role was
of completed
vari in 1995
ous with
func designation
tions , ISO/IEC
12207, and two
given the motions
title of led to a
Standard joint
for committee
Software under the
LifeCycle leadership
Processes. of Mario
Std. ISO/ Barbacci
IEC 12207 and Stuart
provided a Zweben
major point who served
of as
departure cochairs.
for the The
body of mission
knowledge statement
captured in of the joint
this book. committee
It was was To
the IEEE establish
Computer the
Society appropriate
Board of sets(s) of
Governors criteria and
approval of norms for
the motion professiona
put l practice
forward in of software
May 1993 engineerin
by Fletcher g upon
Buckley which
which industrial
resulted in decisions,
the writing professiona
of this l
book. The certificatio
Associatio n, and
n for educational
Computing curricula
Machinery can be
(ACM) based.
Council The
approved a steering
related committee
motion in organized
August task forces
1993. The in the
following knowledge
areas: and
recommen
1. Define d practices.
xi
x
Required The code
Body of of ethics
Knowled and
ge and professiona
Recomm l practice
ended for
Practices software
. engineerin
xx
g was
SWEBOK
Guide V3.0 completed
in 1998
and
approved
2. Define by both the
Ethics ACM
and
Council
Profes
and the
sional
IEEE
Standa
Computer
rds.
Society
3. Define
Board of
Educat
Governors.
ional
It has been
Curric
adopted by
ula for
numerous
underg
raduat corporation
e, s and other
gradua organizatio
te, and ns and is
contin included in
uing several
educati recent
on. textbooks.
The
This educational
book curriculum
supplies for
the first undergradu
component ates is
: required being
body of completed
by a joint and
effort of training
the IEEE programs,
Computer certificatio
Society n of
and the specialists,
ACM and or
is expected professiona
to be l licensing.
completed Generally,
in 2004. a
Every professiona
profession l society or
is based on related
a body of body
knowledge maintains
and custody of
recommen such a
ded formal
practices, definition.
although In cases
they are where no
not always such
defined in formality
a precise exists, the
manner. In body of
many knowledge
cases, and
these are recommen
formally ded
documente practices
d, usually are
in a form generally
that recognized
permits by
them to be practitioner
used for s and may
such be codified
purposes in a variety
as of ways for
accreditati different
on of uses.
academic It
programs, is
developme hope
nt of d
education that
read Fletc
ers her
will Buck
find ley
this in
book reco
usef gniti
ul in on of
guidi his
ng com
them mitm
towa ent
rd to
the prom
kno oting
wled soft
ge ware
and engi
reso neeri
urces ng as
they a
need profe
in ssion
their al
lifelo disci
ng pline
caree and
r his
deve excel
lopm lence
ent as a
as soft
soft ware
ware engi
engi neeri
neeri ng
ng pract
profe ition
ssion er in
als. radar
Th appli
e catio
book ns.
is
dedi
cated Leon
to ard
L. ACM
Trip
p, Steer
IEE ing
E Com
Fello mitte
w efor
2003 the
Chair, Esta
Professio blish
nal ment
Practices of
Software
Committe Engineeri
e,IEEE ngasa
Com Professio
puter n(1998
1999)
Soci
ety Chair,
(200 Software
1 Engineerin
2003 g
) Standards
Committee,
Chai
r, IEEE
Joint
Com
IEE puter
E
Com Soci
puter ety
(199
Soci 2
ety 1998
and )
EDITORS
Pierre Bourque, Department of Software and IT Engineering, cole de technologie suprieure
(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 suprieure (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
xxi
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 suprieure (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 suprieure (TS), Canada, roger.champagne@etsmtl.ca
Alain April, cole de technologie suprieure (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
23
24
SWEBOK Guide V3.0
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.
Peter Sawyer, Computing Department, Lancaster University, UK
Gerald Kotonya, Computing Department, Lancaster University, UK
Software Design
Guy Tremblay, Dpartement dinformatique, UQAM, Canada
Steve McConnell, Construx Software, USA
Terry Bollinger, the MITRE Corporation, USA
Philippe Gabrini, Dpartement dinformatique, UQAM, Canada
Louis Martin, Dpartement dinformatique, UQAM, Canada
Software Testing
Antonia Bertolino, ISTI-CNR, Italy
Eda Marchetti, ISTI-CNR, Italy
Thomas M. Pigoski, Techsoft Inc., USA
Alain April, cole de technologie suprieure, Canada

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

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

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
SWEBOK Guide V3.0
25
26
Software Quality
Alain April, cole de technologie suprieure, Canada
Dolores Wallace, retired from the National Institute of Standards and Technology, USA
Larry Reeker, NIST, USA
References Editor
Marc Bouisset, Dpartement dinformatique, 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. Ann M. Eblen, Australia

David M. Endres, USA
Marilyn Escue, USA
Varuna Eswer, India
Carlos C. Amaro, USA Istvan Fay, Hungary
Mark Ardis, USA Jose L. Fernandez-Sanchez, Spain
Mora-Soto Arturo, Spain Dennis J. Frailey, USA
Ohad Barzilay, Israel Tihana Galinac Grbac, Croatia
Gianni Basaglia, Italy Colin Garlick, New Zealand
Denis J. Bergquist, USA Garth J.G. Glynn, UK
Alexander Bogush, UK Jill Gostin, USA
Christopher Bohn, USA Christiane Gresse von Wangenheim, Brazil
Steve Bollweg, USA Thomas Gust, USA
Reto Bonderer, Switzerland H.N. Mok, Singapore
Alexei Botchkarev, Canada Jon D. Hagar, USA
Pieter Botman, Canada Anees Ahmed Haidary, India
Robert Bragner, USA Duncan Hall, New Zealand
Kevin Brune, USA James Hart, USA
Ogihara Bryan, USA Jens H.J. Heidrich, Germany
Luigi Buglione, Italy Rich Hilliard, USA
Rick Cagle, USA Bob Hillier, Canada
Barbara Canody, USA Norman M. Hines, USA
Rogerio A. Carvalho, Brazil Dave Hirst, USA
Daniel Cerys, USA Theresa L. Hunt, USA
Philippe Cohard, France Kenneth Ingham, USA
Ricardo Colomo-Palacios, Masahiko Ishikawa, Japan
Spain Michael A. Jablonski, USA
Mauricio Coria, Argentina G. Jagadeesh, India
Marek Cruz, UK Sebastian Justicia, Spain
Stephen Danckert, USA Umut Kahramankaptan, Belgium
Bipul K. Das, Canada Pankaj Kamthan, Canada
James D. Davidson, USA Perry Kapadia, USA
Jon Dehn, USA Tarig A. Khalid, Sudan
Lincoln P. Djang, USA Michael K.A. Klaes, Germany
Andreas Doblander, Austria Maged Koshty, Egypt
Yi-Ben Doo, USA Claude C. Laporte, Canada
Scott J. Dougherty, UK Dong Li, China
Regina DuBord, USA Ben Linders, Netherlands
Fedor Dzerzhinskiy, Russia Claire Lohr, USA
27
28
Vladimir Mandic, Serbia Vineet Sawant, USA
Matt Mansell, New Zealand R. Schaaf, USA
John Marien, USA James C. Schatzman, USA
SWEBOK Guide V3.0 Oscar A. Schivo, Argentina
Florian Schneider, Germany
Thom Schoeffling, USA
Stephen P. Masticola, USA Reinhard Schrage, Germany
Nancy Mead, USA Neetu Sethia, India
Fuensanta Medina-Dominguez, Cindy C. Shelton, USA
Spain Alan Shepherd, Germany
Silvia Judith Meles, Argentina Katsutoshi Shintani, Japan
Oscar A. Mondragon, Mexico Erik Shreve, USA
David W. Mutschler, USA Jaguaraci Silva, Brazil
Maria Nelson, Brazil M. Somasundaram, India
John Noblin, USA Peraphon Sophatsathit, Thailand
Bryan G. Ogihara, USA John Standen, UK
Takehisa Okazaki, Japan Joyce Statz, USA
Hanna Oktaba, Mexico Perdita P. Stevens, UK
Chin Hwee Ong, Hong Kong David Struble, USA
Venkateswar Oruganti, India Ohno Susumu, Japan
Birgit Penzenstadler, Germany Urcun Tanik, USA
Larry Peters, USA Talin Tasciyan, USA
S.K. Pillai, India J. Barrie Thompson, UK
Vaclav Rajlich, USA Steve Tockey, USA
Kiron Rao, India Miguel Eduardo Torres Moreno, Colombia
Luis Reyes, USA Dawid Trawczynski, USA
Hassan Reza, USA Adam Trendowicz, Germany
Steve Roach, USA Norio Ueno, Japan
Teresa L. Roberts, USA Cenk Uyan, Turkey
Dennis Robi, USA Chandra Sekar Veerappan, Singapore
Warren E. Robinson, USA Oruganti Venkateswar, India
Jorge L. Rodriguez, USA Jochen Vogt, Germany
Alberto C. Sampaio, Portugal Hironori Washizaki, Japan
Ed Samuels, USA Ulf Westermann, Germany
Maria-Isabel Sanchez-Segura, Don Wilson, USA
Spain Aharon Yadin, Israel
Hong Zhou, UK
ACKNOWLEDGEMENTS
Funding for the development of SWEBOK various ways: Pieter Botman, Evan Butterfield,
Guide V3 has been provided by the IEEE Carine Chauny, Pierce Gibbs, Diane Girard,
Computer Society. The editors and coeditors John Keppler, Dorian McClenahan, Kenza
appreciate the important work performed by the Meridji, Samuel Redwine, Annette Reilly, and
KA editors and the contributing editors as well Pam Thompson.
as by the the members of the Change Control Finally, there are surely other people who
Board. The editorial team must also have contributed to this Guide, either directly or
acknowledge the indispensable contribution of indirectly, whose names we have inadvertently
reviewers. omitted. To those people, we offer our tacit
The editorial team also wishes to thank the appreciation and apologize for having omitted
following people who contributed to the project in 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
SWEBOK Guide V3.0
29
30
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
Computer Society in December 2013:
TheProfessionalActivitiesBoardoftheIEEEComputerSocietyfindsthattheGuide to the
Software Engineering Body of KnowledgeVersion3.0hasbeensuccessfullycompleted;and
endorsestheGuide to the Software Engineering Body of Knowledge Version3.0andcommends
ittotheIEEEComputerSocietyBoardofGovernorsfortheirapproval.
The following motion was adopted by the IEEE Computer Society Board of Governors in December 2013:
MOVED,thattheBoardofGovernorsoftheIEEEComputerSocietyapprovesVersion3.0ofthe
Guide to the Software Engineering Body of Knowledge andauthorizestheChairofthe
ProfessionalActivitiesBoardtoproceedwithprinting.
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:
TheIndustrialAdvisoryBoardfindsthattheSoftwareEngineeringBodyofKnowledgeproject
initiatedin1998hasbeensuccessfullycompleted;andendorsesthe2004VersionoftheGuide to
the SWEBOKandcommendsittotheIEEEComputerSocietyBoardofGovernorsfortheir
approval.
The following motion was adopted by the IEEE Computer Society Board of Governors in February 2004:
MOVED,thattheBoardofGovernorsoftheIEEEComputerSocietyapprovesthe2004Edition
oftheGuide to the Software Engineering Body of Knowledge andauthorizestheChairofthe
ProfessionalPracticesCommitteetoproceedwithprinting.
Please also note that the 2004 edition of the GuidetotheSoftwareEngineeringBodyofKnowledge

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
Software Engineering Body of
SWEBOK
Knowledge
Publication of the 2004 version of this Guidetothe
SoftwareEngineeringBodyofKnowledge (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
Professional 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 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 GuidetotheSoftwareEngineeringBodyofKnowledge (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
1See www.computer.org/sevocab.
31
32
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.
SWEBOK Guide V3.0
Table I.1. The 15 SWEBOK KAs

Software Design
Software Testing
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 projects objectivesa
characterization of the contents of software engineering. The detailed specifications provided
by the projects 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 topics 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 knowledgethe fourth of the projects objectivesthe 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 objectiveproviding a foundation for curriculum development,
33
certification, and licensing, the criterion of Introduction xxxiii
generallyaccepted knowledge has been applied,
to be distinguished from advanced and research
knowledge (on the grounds of maturity) and The breakdown of topics in each KA
from specialized knowledge (on the grounds of constitutes the core the KA description,
generality of application). describing the decomposition of the KA into
The equivalent term generally recognized subareas, topics, and sub-topics. For each topic
comes from the Project Management Institute: or subtopic, a short description is given, along
Generally recognized means the knowledge with one or more references.
and practices described are applicable to most The reference material was chosen because it
projects most of the time, and there is consensus is considered to constitute the best presentation
about their value and usefulness.2 of the knowledge relative to the topic. A matrix
However, the terms generally accepted or links the topics to the reference material.
generally recognized do not imply that the The last part of each KA description is the list
designated knowledge should be uniformly of recommended references and (optionally)
applied to all software engineering endeavors further readings. Relevant standards for each
each projects needs determine thatbut it does KA are presented in Appendix B of the Guide.
imply that competent, capable software
engineers should be equipped with this APPENDIX A. KA DESCRIPTION
knowledge for potential application. More SPECIFICATIONS
precisely, generally accepted knowledge should
be included in the study material for the Appendix A describes the specifications
software engineering licensing examination that provided by the editorial team to the associate
graduates would take after gaining four years of editors for the content, recommended
work experience. Although this criterion is references, format, and style of the KA
specific to the US style of education and does descriptions.
not necessarily apply to other countries, we
deem it useful. APPENDIX B. ALLOCATION OF STAN-
DARDS TO KAS
STRUCTURE OF THE KA DESCRIPTIONS
Appendix B is an annotated list of the relevant
The KA descriptions are structured as follows. standards, mostly from the IEEE and the ISO,
In the introduction, a brief definition of the for each of the KAs of the SWEBOK Guide.
KA and an overview of its scope and of its
relationship with other KAs are presented. APPENDIX C. CONSOLIDATED
REFERENCE LIST
2 AGuidetotheProjectManagementBodyof
Knowledge, 5th ed., Project Management
Appendix C contains the consolidated list of
Institute, 2013; www.pmi.org.
recommended references cited in the KAs (these
references are marked with an asterisk (*) in the used in this KA other than for software
text). engineering per se.
For the same reason, requirements engineer,
CHAPTER 1 SOFTWARE a term which appears in some of the literature,
REQUIREMENTS will not be used either. Instead, the term
software engineer or, in some specific cases,
requirements specialist will be used, the latter
ACRONYMS where the role in question is usually performed
by an individual other than a software engineer.
Confidentiality, Integrity, and
CIA This does not imply, however, that a software
Availability
engineer could not perform the function.
DAG Directed Acyclic Graph A risk inherent in the proposed breakdown is
FSM Functional Size Measurement that a waterfall-like process may be inferred. To
guard against this, topic 2, Requirements
International Council on Systems
INCOSE Process, is designed to provide a high-level
Engineering
overview of the requirements process by setting
UML Unified Modeling Language out the resources and constraints under which
SysML Systems Modeling Language the process operates and which act to configure
INTRODUCTION it.
An alternate decomposition could use a
The Software Requirements knowledge area product-based structure (system requirements,
(KA) is concerned with the elicitation, analysis, software requirements, prototypes, use cases,
specification, and validation of software and so on). The process-based breakdown
requirements as well as the management of reflects the fact that the requirements process, if
requirements during the whole life cycle of the it is to be successful, must be considered as a
software product. It is widely acknowledged process involving complex, tightly coupled
amongst researchers and industry practitioners activities (both sequential and concurrent),
that software projects are critically vulnerable rather than as a discrete, one-off activity
when the requirementsrelated activities are performed at the outset of a software
poorly performed. development project.
Software requirements express the needs and The Software Requirements KA is related
constraints placed on a software product that closely to the Software Design, Software
contribute to the solution of some real-world Testing, Software Maintenance, Software
problem. Configuration Management, Software
The term requirements engineering is Engineering Management, Software
widely used in the field to denote the systematic Engineering Process, Software Engineering
handling of requirements. For reasons of Models and Methods, and Software Quality
consistency, the term engineering will not be KAs.
BREAKDOWN OF TOPICS FOR [1*, c4, c4s1, c10s1, c10s4] [2*, c1, c6,
SOFTWARE REQUIREMENTS
c12] 1.1. DefinitionofaSoftwareRequirement
The breakdown of topics for the Software
Requirements KA is shown in Figure 1.1. At its most basic, a software requirement is a
property that must be exhibited by something in
1. Software Requirements Fundamentals
1-1
Figure 1.1. Breakdown of Topics for the Software Requirements KA

order to solve some problem in the real world. It typically complex. By extension, therefore, the
may aim to automate part of a task for someone requirements on particular software are
to support the business processes of an typically a complex combination from various
organization, to correct shortcomings of existing people at different levels of an organization, and
software, or to control a deviceto name just a who are in one way or another involved or
few of the many problems for which software connected with this feature from the
solutions are possible. The ways in which users, environment in which the software will operate.
business processes, and devices function are
An essential property of all software identified so that they can be subjected to
requirements is that they be verifiable as an software configuration management over the
individual feature as a functional requirement or entire life cycle of the feature and of the
at the system level as a nonfunctional software.
requirement. It may be difficult or costly to
verify certain software requirements. For 1.2. ProductandProcessRequirements
example, verification of the throughput
requirement on a call center may necessitate the A product requirement is a need or constraint on
development of simulation software. Software the software to be developed (for example, The
requirements, software testing, and quality software shall verify that a student meets all
personnel must ensure that the requirements can prerequisites before he or she registers for a
be verified within available resource constraints. course).
Requirements have other attributes in addition A process requirement is essentially a
to behavioral properties. Common examples constraint on the development of the software
include a priority rating to enable tradeoffs in (for example, The software shall be developed
the face of finite resources and a status value to using a RUP process).
enable project progress to be monitored. Some software requirements generate implicit
Typically, software requirements are uniquely process requirements. The choice of verification
1-38 SWEBOK Guide V3.0
technique is one example. Another might be the Software requirements should be stated as
use of particularly rigorous analysis techniques clearly and as unambiguously as possible, and,
(such as formal specification methods) to reduce where appropriate, quantitatively. It is important
faults that can lead to inadequate reliability. to avoid vague and unverifiable requirements
Process requirements may also be imposed that depend for their interpretation on subjective
directly by the development organization, their judgment (the software shall be reliable; the
customer, or a third party such as a safety software shall be user-friendly). This is
regulator. particularly important for nonfunctional
requirements. Two examples of quantified
1.3. FunctionalandNonfunctional requirements are the following: a call centers
Requirements software must increase the centers throughput
by 20%; and a system shall have a probability
Functional requirements describe the functions of generating a fatal error during any hour of
that the software is to execute; for example, operation of less than 1 * 108. The throughput
formatting some text or modulating a signal. requirement is at a very high level and will need
They are sometimes known as capabilities or to be used to derive a number of detailed
features. A functional requirement can also be requirements. The reliability requirement will
described as one for which a finite set of test tightly constrain the system architecture.
steps can be written to validate its behavior.
Nonfunctional requirements are the ones that 1.6. SystemRequirementsandSoftware
act to constrain the solution. Nonfunctional Requirements
requirements are sometimes known as
constraints or quality requirements. They can be In this topic, system means
further classified according to whether they are
performance requirements, maintainability an interacting combination of elements to
requirements, safety requirements, reliability accomplish a defined objective. These
requirements, security requirements, include hardware, software, firmware,
interoperability requirements or one of many people, information, techniques,
other types of software requirements (see facilities, services, and other support
Models and Quality Characteristics in the elements,
Software Quality KA).
as defined by the International Council on
1.4. EmergentProperties Software and Systems Engineering (INCOSE)
[3].
Some requirements represent emergent System requirements are the requirements for
properties of softwarethat is, requirements the system as a whole. In a system containing
that cannot be addressed by a single component software components, software requirements are
but that depend on how all the software derived from system requirements.
components interoperate. The throughput This KA defines user requirements in a
requirement for a call center would, for restricted way, as the requirements of the
example, depend on how the telephone system, systems customers or end users. System
information system, and the operators all requirements, by contrast, encompass user
interacted under actual operating conditions. requirements, requirements of other
Emergent properties are crucially dependent on stakeholders (such as regulatory authorities),
the system architecture. and requirements without an identifiable human
source.
1.5. QuantifiableRequirements
2.Requirements Process
Software Requirements 1-39
[1*, c4s4] [2*, c14, c6, c22, c23] Users: This group comprises those who will
operate the software. It is often a
This section introduces the software heterogeneous group involving people with
requirements process, orienting the remaining different roles and requirements.
five topics and showing how the requirements Customers: This group comprises those who
process dovetails with the overall software have commissioned the software or who
engineering process. represent the softwares target market.
2.1. ProcessModels Market analysts: A mass-market product
will not have a commissioning customer, so
The objective of this topic is to provide an marketing people are often needed to
understanding that the requirements process establish what the market needs and to act
as proxy customers.
is not a discrete front-end activity of the Regulators: Many application domains,
software life cycle, but rather a process such as banking and public transport, are
initiated at the beginning of a project that regulated. Software in these domains must
continues to be refined throughout the life comply with the requirements of the
cycle; regulatory authorities.
identifies software requirements as Software engineers: These individuals have
configuration items and manages them a legitimate interest in profiting from
using the same software configuration developing the software by, for example,
management practices as other products of reusing components in or from other
the software life cycle processes; products. If, in this scenario, a customer of a
needs to be adapted to the organization and particular product has specific requirements
project context. that compromise the potential for
component reuse, the software engineers
In particular, the topic is concerned with how must carefully weigh their own stake
the activities of elicitation, analysis, against those of the customer. Specific
specification, and validation are configured for requirements, particularly constraints, may
different types of projects and constraints. The have major impact on project cost or
topic also includes activities that provide input delivery because they either fit well or
into the requirements process, such as marketing poorly with the skill set of the engineers.
and feasibility studies. Important tradeoffs among such
requirements should be identified.
2.2. ProcessActors
It will not be possible to perfectly satisfy the
This topic introduces the roles of the people requirements of every stakeholder, and it is the
who participate in the requirements process. software engineers job to negotiate tradeoffs
This process is fundamentally interdisciplinary, that are both acceptable to the principal
and the requirements specialist needs to mediate stakeholders and within budgetary, technical,
between the domain of the stakeholder and that regulatory, and other constraints. A prerequisite
of software engineering. There are often many for this is that all the stakeholders be identified,
people involved besides the requirements the nature of their stake analyzed, and their
specialist, each of whom has a stake in the requirements elicited. 2.3. ProcessSupportand
software. The stakeholders will vary across Management
projects, but will always include users/operators
and customers (who need not be the same). This section introduces the project management
Typical examples of software stakeholders resources required and consumed by the
include (but are not restricted to) the following: requirements process. It establishes the context
for the first topic (Initiation and Scope effective communication between the various
Definition) of the Software Engineering stakeholders. This communication continues
Management KA. Its principal purpose is to through the entire Software Development Life
make the link between the process activities Cycle (SDLC) process with different
identified in 2.1 and the issues of cost, human stakeholders at different points in time. Before
resources, training, and tools. 2.4. Process development begins, requirements specialists
QualityandImprovement may form the conduit for this communication.
They must mediate between the domain of the
This topic is concerned with the assessment of software users (and other stakeholders) and the
the quality and improvement of the technical world of the software engineer. A set
requirements process. Its purpose is to of internally consistent models at different
emphasize the key role the requirements process levels of abstraction facilitate communications
plays in terms of the cost and timeliness of a between software users/stakeholders and
software product and of the customers software engineers.
satisfaction with it. It will help to orient the A critical element of requirements elicitation
requirements process with quality standards and is informing the project scope. This involves
process improvement models for software and providing a description of the software being
systems. Process quality and improvement is specified and its purpose and prioritizing the
closely related to both the Software Quality KA deliverables to ensure the customers most
and Software Engineering Process KA, important business needs are satisfied first. This
comprising minimizes the risk of requirements specialists
spending time eliciting requirements that are of
requirements process coverage by process low importance, or those that turn out to be no
improvement standards and models; longer relevant when the software is delivered.
requirements process measures On the other hand, the description must be
and benchmarking; scalable and extensible to accept further
improvement planning and implementation; requirements not expressed in the first formal
security/CIA lists and compatible with the previous ones as
improvement/planning and contemplated in recursive methods. 3.1.
implementation. RequirementsSources
3. Requirements Elicitation Requirements have many sources in typical

[1*, c4s5] [2*, c5, c6, c9] software, and it is essential that all potential
sources be identified and evaluated. This topic
Requirements elicitation is concerned with the is designed to promote awareness of the various
origins of software requirements and how the sources of software requirements and of the
software engineer can collect them. It is the first frameworks for managing them. The main
stage in building an understanding of the points covered are as follows:
problem the software is required to solve. It is
fundamentally a human activity and is where the Goals. The term goal (sometimes called
stakeholders are identified and relationships business concern or critical success
established between the development team and factor) refers to the overall, high-level
the customer. It is variously termed objectives of the software. Goals provide
requirements capture, requirements the motivation for the software but are often
discovery, and requirements vaguely formulated. Software engineers
acquisition. need to pay particular attention to assessing
One of the fundamental principles of a good the value (relative to priority) and cost of
requirements elicitation process is that of
goals. A feasibility study is a relatively low- these since, in general, new software should
cost way of doing this. not force unplanned change on the business
Domain knowledge. The software engineer process.
needs to acquire or have available
knowledge about the application domain. 3.2. ElicitationTechniques
Domain knowledge provides the
background against which all elicited Once the requirements sources have been
requirements knowledge must be set in identified, the software engineer can start
order to understand it. Its a good practice to eliciting requirements information from them.
emulate an ontological approach in the Note that requirements are seldom elicited
knowledge domain. Relations between ready-made. Rather, the software engineer
relevant concepts within the application elicits information from which he or she
domain should be identified. formulates requirements. This topic
Stakeholders (see section 2.2, Process concentrates on techniques for getting human
Actors). Much software has proved stakeholders to articulate requirementsrelevant
unsatisfactory because it has stressed the information. It is a very difficult task and the
requirements of one group of stakeholders software engineer needs to be sensitized to the
at the expense of others. Hence, the fact that (for example) users may have difficulty
delivered software is difficult to use, or describing their tasks, may leave important
subverts the cultural or political structures information unstated, or may be unwilling or
of the customer organization. The software unable to cooperate. It is particularly important
engineer needs to identify, represent, and to understand that elicitation is not a passive
manage the viewpoints of many different activity and that, even if cooperative and
types of stakeholders. articulate stakeholders are available, the
Business rules. These are statements that software engineer has to work hard to elicit the
define or constrain some aspect of the right information. Many business or technical
structure or the behavior of the business requirements are tacit or in feedback that has yet
itself. A student cannot register in next to be obtained from end users. The importance
semesters courses if there remain some of planning, verification, and validation in
unpaid tuition fees would be an example of requirements elicitation cannot be overstated. A
a business rule that would be a requirement number of techniques exist for requirements
source for a universitys course-registration elicitation; the principal ones are these:
software.
The operational environment. Requirements Interviews. Interviewing stakeholders is a
will be derived from the environment in traditional means of eliciting
which the software will be executed. These requirements. It is important to understand
may be, for example, timing constraints in the advantages and limitations of interviews
real-time software or performance and how they should be conducted.
constraints in a business environment. Scenarios. Scenarios provide a valuable
These must be sought out actively because means for providing context to the
they can greatly affect software feasibility elicitation of user requirements. They allow
and cost as well as restrict design choices. the software engineer to provide a
The organizational environment. Software framework for questions about user tasks by
is often required to support a business permitting what if and how is this done
process, the selection of which may be questions to be asked. The most common
conditioned by the structure, culture, and type of scenario is the use case description.
internal politics of the organization. The There is a link here to topic 4.2 (Conceptual
software engineer needs to be sensitive to Modeling) because scenario notations such
as use case diagrams are common in by immersing themselves in the

modeling software. environment and observing how users
Prototypes. This technique is a valuable tool perform their tasks by interacting with each
for clarifying ambiguous requirements. other and with software tools and other
They can act in a similar way to scenarios resources. These techniques are relatively
by providing users with a context within expensive but also instructive because they
which they can better understand what illustrate that many user tasks and business
information they need to provide. There is a processes are too subtle and complex for
wide range of prototyping techniques their actors to describe easily.
from paper mockups of screen designs to User stories. This technique is commonly
beta-test versions of software products used in adaptive methods (see Agile
and a strong overlap of their separate uses Methods in the Software Engineering
for requirements elicitation and for Models and Methods KA) and refers to
requirements validation (see section 6.2, short, highlevel descriptions of required
Prototyping). Low fidelity prototypes are functionality expressed in customer terms.
often preferred to avoid stakeholder A typical user story has the form: As a
anchoring on minor, incidental <role>, I want<goal/desire> so that
characteristics of a higher quality prototype <benefit>. A user story is intended to
that can limit design flexibility in contain just enough information so that the
unintended ways. developers can produce a reasonable
Facilitated meetings. The purpose of these estimate of the effort to implement it. The
meetings is to try to achieve a summative aim is to avoid some of the waste that often
effect, whereby a group of people can bring happens in projects where detailed
more insight into their software requirements are gathered early but become
requirements than by working individually. invalid before the work begins. Before a
They can brainstorm and refine ideas that user story is implemented, an appropriate
may be difficult to bring to the surface using acceptance procedure must be written by the
interviews. Another advantage is that customer to determine whether the goals of
conflicting requirements surface early on in the user story have been fulfilled.
a way that lets the stakeholders recognize Other techniques. A range of other
where these occur. When it works well, this techniques for supporting the elicitation of
technique may result in a richer and more requirements information exist and range
consistent set of requirements than might from analyzing competitors products to
otherwise be achievable. However, applying data mining techniques to using
meetings need to be handled carefully sources of domain knowledge or customer
(hence the need for a facilitator) to prevent a request databases.
situation in which the critical abilities of the 4. Requirements Analysis
team are eroded by group loyalty, or in [1*, c4s1, c4s5, c10s4, c12s5]
which requirements reflecting the concerns [2*, c7, c11, c12, c17]
of a few outspoken (and perhaps senior)
people that are favored to the detriment of This topic is concerned with the process of
others. analyzing requirements to
Observation. The importance of software
context within the organizational detect and resolve conflicts
environment has led to the adaptation of between requirements;
observational techniques such as discover the bounds of the software and
ethnography for requirements elicitation. how it must interact with its organizational
Software engineers learn about user tasks and operational environment;
elaborate system requirements to derive The scope of the requirement. Scope refers
software requirements. to the extent to which a requirement affects
the software and software components.
The traditional view of requirements analysis Some requirements, particularly certain
has been that it be reduced to conceptual nonfunctional ones, have a global scope in
modeling using one of a number of analysis that their satisfaction cannot be allocated to
methods, such as the structured analysis method. a discrete component. Hence, a requirement
While conceptual modeling is important, we with global scope may strongly affect the
include the classification of requirements to help software architecture and the design of
inform tradeoffs between requirements many components, whereas one with a
(requirements classification) and the process of narrow scope may offer a number of design
establishing these tradeoffs (requirements choices and have little impact on the
negotiation). satisfaction of other requirements.
Care must be taken to describe requirements Volatility/stability. Some requirements will
precisely enough to enable the requirements to change during the life cycle of the software
be validated, their implementation to be and even during the development process
verified, and their costs to be estimated. itself. It is useful if some estimate of the
likelihood that a requirement will change
4.1. RequirementsClassification can be made. For example, in a banking
application, requirements for functions to
Requirements can be classified on a number of calculate and credit interest to customers
dimensions. Examples include the following: accounts are likely to be more stable than a
requirement to support a particular kind of
Whether the requirement is functional or tax-free account. The former reflects a
nonfunctional (see section 1.3, Functional fundamental feature of the banking domain
and Nonfunctional Requirements). (that accounts can earn interest), while the
Whether the requirement is derived from latter may be rendered obsolete by a change
one or more high-level requirements or an to government legislation. Flagging
emergent property (see section 1.4, potentially volatile requirements can help
Emergent Properties), or is being imposed the software engineer establish a design that
directly on the software by a stakeholder or is more tolerant of change.
some other source.
Whether the requirement is on the product Other classifications may be appropriate,
or the process (see section 1.2, Product and depending upon the organizations normal
Process Requirements). Requirements on practice and the application itself.
the process can constrain the choice of There is a strong overlap between
contractor, the software engineering process requirements classification and requirements
to be adopted, or the standards to be attributes (see section 7.3, Requirements
adhered to. Attributes).
The requirement priority. The higher the 4.2. ConceptualModeling
priority, the more essential the requirement
is for meeting the overall goals of the The development of models of a real-world
software. Often classified on a fixed-point problem is key to software requirements
scale such as mandatory, highly desirable, analysis. Their purpose is to aid in
desirable, or optional, the priority often has understanding the situation in which the
to be balanced against the cost of problem occurs, as well as depicting a solution.
development and implementation. Hence, conceptual models comprise models of
entities from the problem domain, configured to
reflect their real-world relationships and provides guidance on the purpose and intent of
dependencies. This topic is closely related to the modeling.
Software Engineering Models and Methods KA.
Several kinds of models can be developed. 4.3. ArchitecturalDesignand
These include use case diagrams, data flow RequirementsAllocation
models, state models, goal-based models, user
interactions, object models, data models, and At some point, the solution architecture must be
many others. Many of these modeling notations derived. Architectural design is the point at
are part of theUnifiedModelingLanguage which the requirements process overlaps with
(UML).Use case diagrams, for example, are software or systems design and illustrates how
routinely used to depict scenarios where the impossible it is to cleanly decouple the two
boundary separates the actors (users or systems tasks. This topic is closely related to Software
in the external environment) from the internal Structure and Architecture in the Software
behavior where each use case depicts a Design KA. In many cases, the software
functionality of the system. engineer acts as software architect because the
The factors that influence the choice of process of analyzing and elaborating the
modeling notation include these: requirements demands that the
architecture/design components that will be
The nature of the problem. Some types of responsible for satisfying the requirements be
software demand that certain aspects be identified. This is requirements allocationthe
analyzed particularly rigorously. For assignment to architecture components
example, state and parametric models, responsible for satisfying the requirements.
which are part of SysML [4], are likely to Allocation is important to permit detailed
be more important for real-time software analysis of requirements. Hence, for example,
than for information systems, while it would once a set of requirements has been allocated to
usually be the opposite for object and a component, the individual requirements can be
activity models. further analyzed to discover further
The expertise of the software engineer. It is requirements on how the component needs to
often more productive to adopt a modeling interact with other components in order to
notation or method with which the software satisfy the allocated requirements. In large
engineer has experience. projects, allocation stimulates a new round of
The process requirements of the customer analysis for each subsystem. As an example,
(see section 1.2, Product and Process requirements for a particular braking
Requirements). Customers may impose performance for a car (braking distance, safety
their favored notation or method or prohibit in poor driving conditions, smoothness of
any with which they are unfamiliar. This application, pedal pressure required, and so on)
factor can conflict with the previous factor. may be allocated to the braking hardware
(mechanical and hydraulic assemblies) and an
Note that, in almost all cases, it is useful to antilock braking system (ABS). Only when a
start by building a model of the software requirement for an antilock braking system has
context. The software context provides a been identified, and the requirements allocated
connection between the intended software and to it, can the capabilities of the ABS, the braking
its external environment. hardware, and emergent properties (such as car
This is crucial to understanding the softwares weight) be used to identify the detailed ABS
context in its operational environment and to software requirements.
identifying its interfaces with the environment. Architectural design is closely identified with
This subtopic does not seek to teach a conceptual modeling (see section 4.2,
particular modeling style or notation but rather Conceptual Modeling).
4.4. RequirementsNegotiation determine which of the two is of higher priority,

and to what extent.
Another term commonly used for this subtopic 4.5. FormalAnalysis
is conflict resolution. This concerns resolving
problems with requirements where conflicts Formal analysis concerns not only topic 4, but
occur between two stakeholders requiring also sections 5.3 and 6.3. This topic is also
mutually incompatible features, between related to Formal Methods in the Software
requirements and resources, or between Engineering Models and Methods Knowledge
functional and nonfunctional requirements, for Area.
example. In most cases, it is unwise for the Formal analysis has made an impact on some
software engineer to make a unilateral decision, application domains, particularly those of
so it becomes necessary to consult with the highintegrity systems. The formal expression of
stakeholder(s) to reach a consensus on an requirements requires a language with formally
appropriate tradeoff. It is often important, for defined semantics. The use of a formal analysis
contractual reasons, that such decisions be for requirements expression has two benefits.
traceable back to the customer. We have First, it enables requirements expressed in the
classified this as a software requirements language to be specified precisely and
analysis topic because problems emerge as the unambiguously, thus (in principle) avoiding the
result of analysis. However, a strong case can potential for misinterpretation. Secondly,
also be made for considering it a requirements requirements can be reasoned over, permitting
validation topic (see topic 6, Requirements desired properties of the specified software to be
Validation). proven. Formal reasoning requires tool support
Requirements prioritization is necessary, not to be practicable for anything other than trivial
only as a means to filter important requirements, systems, and tools generally fall into two types:
but also in order to resolve conflicts and plan for theorem provers or model checkers. In neither
staged deliveries, which means making complex case can proof be fully automated, and the level
decisions that require detailed domain of competence in formal reasoning needed in
knowledge and good estimation skills. However, order to use the tools restricts the wider
it is often difficult to get real information that application of formal analysis.
can act as a basis for such decisions. In addition, Most formal analysis is focused on relatively
requirements often depend on each other, and late stages of requirements analysis. It is
priorities are relative. In practice, software generally counterproductive to apply
engineers perform requirements prioritization formalization until the business goals and user
frequently without knowing about all the requirements have come into sharp focus
requirements. Requirements prioritization may through means such as those described
follow a costvalue approach that involves an elsewhere in section 4. However, once the
analysis from the stakeholders defining in a requirements have stabilized and have been
scale the benefits or the aggregated value that elaborated to specify concrete properties of the
the implementation of the requirement brings software, it may be beneficial to formalize at
them, versus the penalties of not having least the critical requirements. This permits
implemented a particular requirement. It also static validation that the software specified by
involves an analysis from the software engineers the requirements does indeed have the
estimating in a scale the cost of implementing properties (for example, absence of deadlock)
each requirement, relative to other requirements. that the customer, users, and software engineer
Another requirements prioritization approach expect it to have.
called the analytic hierarchy process involves
comparing all unique pairs of requirements to 5. Requirements Specification
[1*, c4s2, c4s3, c12s25] [2*, c10]
For most engineering professions, the term description of software requirements. In this
specification refers to the assignment of view, system requirements are specified, the
numerical values or limits to a products design software requirements are derived from the
goals. In software engineering, software system requirements, and then the requirements
requirements specification typically refers to for the software components are specified.
the production of a document that can be Strictly speaking, system requirements
systematically reviewed, evaluated, and specification is a systems engineering activity
approved. For complex systems, particularly and falls outside the scope of this Guide.
those involving substantial nonsoftware 5.3. SoftwareRequirementsSpecification
components, as many as three different types of
documents are produced: system definition, Software requirements specification establishes
system requirements, and software the basis for agreement between customers and
requirements. For simple software products, contractors or suppliers (in market-driven
only the third of these is required. All three projects, these roles may be played by the
documents are described here, with the marketing and development divisions) on what
understanding that they may be combined as the software product is to do as well as what it
appropriate. A description of systems is not expected to do.
engineering can be found in the Related Software requirements specification permits a
Disciplines of Software Engineering chapter of rigorous assessment of requirements before
this Guide. design can begin and reduces later redesign. It
should also provide a realistic basis for
5.1. SystemDefinitionDocument estimating product costs, risks, and schedules.
Organizations can also use a software
This document (sometimes known as the user requirements specification document as the
requirements document or concept of operations basis for developing effective verification and
document) records the system requirements. It validation plans.
defines the high-level system requirements from Software requirements specification provides
the domain perspective. Its readership includes an informed basis for transferring a software
representatives of the system users/customers product to new users or software platforms.
(marketing may play these roles for Finally, it can provide a basis for software
marketdriven software), so its content must be enhancement.
couched in terms of the domain. The document Software requirements are often written in
lists the system requirements along with natural language, but, in software requirements
background information about the overall specification, this may be supplemented by
objectives for the system, its target formal or semiformal descriptions. Selection of
environment, and a statement of the constraints, appropriate notations permits particular
assumptions, and nonfunctional requirements. It requirements and aspects of the software
may include conceptual models designed to architecture to be described more precisely and
illustrate the system context, usage scenarios, concisely than natural language. The general
and the principal domain entities, as well as rule is that notations should be used that allow
workflows. the requirements to be described as precisely as
possible. This is particularly crucial for safety-
5.2. SystemRequirementsSpecification critical, regulatory, and certain other types of
dependable software. However, the choice of
Developers of systems with substantial software notation is often constrained by the training,
and nonsoftware componentsa modern skills, and preferences of the documents
airliner, for exampleoften separate the authors and readers.
description of system requirements from the
A number of quality indicators have been that it defines the right software (that is, the
developed that can be used to relate the quality software that the users expect).
of software requirements specification to other
project variables such as cost, acceptance, 6.1. RequirementsReviews
performance, schedule, and reproducibility.
Quality indicators for individual software Perhaps the most common means of validation
requirements specification statements include is by inspection or reviews of the requirements
imperatives, directives, weak phrases, options, document(s). A group of reviewers is assigned a
and continuances. Indicators for the entire brief to look for errors, mistaken assumptions,
software requirements specification document lack of clarity, and deviation from standard
include size, readability, specification, depth, practice. The composition of the group that
and text structure. conducts the review is important (at least one
6. Requirements Validation representative of the customer should be
[1*, c4s6] [2*, c13, c15] included for a customer-driven project, for
example), and it may help to provide guidance
The requirements documents may be subject to on what to look for in the form of checklists.
validation and verification procedures. The Reviews may be constituted on completion of
requirements may be validated to ensure that the the system definition document, the system
software engineer has understood the specification document, the software
requirements; it is also important to verify that a requirements specification document, the
requirements document conforms to company baseline specification for a new release, or at
standards and that it is understandable, any other step in the process.
consistent, and complete. In cases where
documented company standards or terminology 6.2. Prototyping
are inconsistent with widely accepted standards,
a mapping between the two should be agreed on Prototyping is commonly a means for validating
and appended to the document. the software engineers interpretation of the
Formal notations offer the important software requirements, as well as for eliciting
advantage of permitting the last two properties new requirements. As with elicitation, there is a
to be proven (in a restricted sense, at least). range of prototyping techniques and a number
Different stakeholders, including representatives of points in the process where prototype
of the customer and developer, should review validation may be appropriate. The advantage of
the document(s). Requirements documents are prototypes is that they can make it easier to
subject to the same configuration management interpret the software engineers assumptions
practices as the other deliverables of the and, where needed, give useful feedback on
software life cycle processes. When practical, why they are wrong. For example, the dynamic
the individual requirements are also subject to behavior of a user interface can be better
configuration management, generally using a understood through an animated prototype than
requirements management tool (see topic 8, through textual description or graphical models.
Software Requirements Tools). The volatility of a requirement that is defined
It is normal to explicitly schedule one or more after prototyping has been done is extremely
points in the requirements process where the low because there is agreement between the
requirements are validated. The aim is to pick stakeholder and the software engineer
up any problems before resources are committed therefore, for safety-critical and crucial features
to addressing the requirements. Requirements prototyping would really help. There are also
validation is concerned with the process of disadvantages, however. These include the
examining the requirements document to ensure danger of users attention being distracted from
the core underlying functionality by cosmetic
issues or quality problems with the prototype. The first level of topic decomposition presented
For this reason, some advocate prototypes that in this KA may seem to describe a linear
avoid software, such as flip-chart-based sequence of activities. This is a simplified view
mockups. Prototypes may be costly to develop. of the process.
However, if they avoid the wastage of resources The requirements process spans the whole
caused by trying to satisfy erroneous software life cycle. Change management and the
requirements, their cost can be more easily maintenance of the requirements in a state that
justified. Early prototypes may contain aspects accurately mirrors the software to be built, or
of the final solution. Prototypes may be that has been built, are key to the success of the
evolutionary as opposed to throwaway. software engineering process.
Not every organization has a culture of
6.3. ModelValidation documenting and managing requirements. It is
common in dynamic start-up companies, driven
It is typically necessary to validate the quality of by a strong product vision and limited
the models developed during analysis. For resources, to view requirements documentation
example, in object models, it is useful to as unnecessary overhead. Most often, however,
perform a static analysis to verify that as these companies expand, as their customer
communication paths exist between objects that, base grows, and as their product starts to evolve,
in the stakeholders domain, exchange data. If they discover that they need to recover the
formal analysis notations are used, it is possible requirements that motivated product features in
to use formal reasoning to prove specification order to assess the impact of proposed changes.
properties. This topic is closely related to the Hence, requirements documentation and change
Software Engineering Models and Methods KA. management are key to the success of any
requirements process.
6.4. AcceptanceTests
7.1.IterativeNatureoftheRequirements
An essential property of a software requirement Process
is that it should be possible to validate that the
finished product satisfies it. Requirements that There is general pressure in the software
cannot be validated are really just wishes. An industry for ever shorter development cycles,
important task is therefore planning how to and this is particularly pronounced in highly
verify each requirement. In most cases, competitive, market-driven sectors. Moreover,
designing acceptance tests does this for how most projects are constrained in some way by
end-users typically conduct business using the their environment, and many are upgrades to, or
system. revisions of, existing software where the
Identifying and designing acceptance tests architecture is a given. In practice, therefore, it
may be difficult for nonfunctional requirements is almost always impractical to implement the
(see section 1.3, Functional and Nonfunctional requirements process as a linear, deterministic
Requirements). To be validated, they must first process in which software requirements are
be analyzed and decomposed to the point where elicited from the stakeholders, baselined,
they can be expressed quantitatively. allocated, and handed over to the software
Additional information can be found in development team. It is certainly a myth that the
Acceptance/Qualification/Conformance Testing requirements for large software projects are ever
in the Software Testing KA. perfectly understood or perfectly specified.
Instead, requirements typically iterate towards
7. Practical Considerations
a level of quality and detail that is sufficient to
[1*, c4s1, c4s4, c4s6, c4s7]
permit design and procurement decisions to be
[2*, c3, c12, c14, c16, c1821]
made. In some projects, this may result in the
requirements being baselined before all their combination of topdown analysis and design
properties are fully understood. This risks methods and bottomup implementation and
expensive rework if problems emerge late in the refactoring methods that meet in the middle
software engineering process. However, could provide the best of both worlds. However,
software engineers are necessarily constrained this is difficult to achieve in practice, as it
by project management plans and must therefore depends heavily upon the maturity and expertise
take steps to ensure that the quality of the of the software engineers.
requirements is as high as possible given the
available resources. They should, for example, 7.2.ChangeManagement
make explicit any assumptions that underpin the
requirements as well as any known problems. Change management is central to the
For software products that are developed management of requirements. This topic
iteratively, a project team may baseline only describes the role of change management, the
those requirements needed for the current procedures that need to be in place, and the
iteration. The requirements specialist can analysis that should be applied to proposed
continue to develop requirements for future changes. It has strong links to the Software
iterations, while developers proceed with design Configuration Management KA.
and construction of the current iteration. This
approach provides customers with business 7.3.RequirementsAttributes
value quickly, while minimizing the cost of
rework. Requirements should consist not only of a
In almost all cases, requirements specification of what is required, but also of
understanding continues to evolve as design and ancillary information, which helps manage and
interpret the requirements. Requirements
development proceeds. This often leads to the
attributes must be defined, recorded, and
revision of requirements late in the life cycle.
updated as the software under development or
Perhaps the most crucial point in understanding
maintenance evolves. This should include the
software requirements is that a significant
various classification dimensions of the
proportion of the requirements will change. This
requirement (see section 4.1, Requirements
is sometimes due to errors in the analysis, but it
Classification) and the verification method or
is frequently an inevitable consequence of
relevant acceptance test plan section. It may
change in the environmentfor example, the
also include additional information, such as a
customers operating or business environment,
summary rationale for each requirement, the
regulatory processes imposed by the authorities, source of each requirement, and a change
or the market into which software must sell. history. The most important requirements
Whatever the cause, it is important to recognize attribute, however, is an identifier that allows
the inevitability of change and take steps to the requirements to be uniquely and
mitigate its effects. Change has to be managed unambiguously identified. 7.4.Requirements
by ensuring that proposed changes go through a Tracing
defined review and approval process and by
applying careful requirements tracing, impact Requirements tracing is concerned with
analysis, and software configuration recovering the source of requirements and
management (see the Software Configuration predicting the effects of requirements. Tracing is
Management KA). Hence, the requirements fundamental to performing impact analysis
process is not merely a front-end task in when requirements change. A requirement
software development, but spans the whole should be traceable backward to the
software life cycle. In a typical project, the requirements and stakeholders that motivated it
software requirements activities evolve over (from a software requirement back to the system
time from elicitation to change management. A
requirement(s) that it helps satisfy, for a change in requirements, in estimating the cost
example). Conversely, a requirement should be of a development or maintenance task, or
traceable forward into the requirements and simply for use as the denominator in other
design entities that satisfy it (for example, from measurements. Functional size measurement
a system requirement into the software (FSM) is a technique for evaluating the size of a
requirements that have been elaborated from it, body of functional requirements.
and on into the code modules that implement it, Additional information on size measurement
or the test cases related to that code and even a and standards will be found in the Software
given section on the user manual which Engineering Process KA.
describes the actual functionality) and into the
test case that verifies it. 8. Software Requirements Tools
The requirements tracing for a typical project
will form a complex directed acyclic graph Tools for dealing with software requirements
(DAG) (see Graphs in the Computing fall broadly into two categories: tools for
Foundations KA) of requirements. Maintaining modeling and tools for managing requirements.
an up-todate graph or traceability matrix is an Requirements management tools typically
activity that must be considered during the support a range of activitiesincluding
whole life cycle of a product. If the traceabilitydocumentation, tracing, and change
information is not updated as changes in the managementand have had a significant
requirements continue to happen, the impact on practice. Indeed, tracing and change
traceability information becomes unreliable for management are really only practicable if
impact analysis. supported by a tool. Since requirements
7.5.MeasuringRequirements management is fundamental to good
requirements practice, many organizations have
As a practical matter, it is typically useful to invested in requirements management tools,
have some concept of the volume of the although many more manage their requirements
requirements for a particular software product. in more ad hoc and generally less satisfactory
This number is useful in evaluating the size of ways (e.g., using spreadsheets).
MATRIX OF TOPICS VS. REFERENCE MATERIAL
Wiegers 2003
[2*]
Sommerville 2011
[1*]
1. Software Requirements Fundamentals

1.1. Definition of a Software Requirement c4 c1
1.2. Product and Process Requirements c4s1 c1, c6
1.3. Functional and Nonfunctional Requirements c4s1 c12
1.4. Emergent Properties c10s1
1.5. Quantifiable Requirements c1
1.6. System Requirements and Software Requirements c10s4 c1

2. Requirements Process
2.1. Process Models c4s4 c3
2.2. Process Actors c1, c2, c4, c6
2.3. Process Support and Management c3
2.4. Process Quality and Improvement c22, c23
3. Requirements Elicitation
3.1. Requirements Sources c4s5 c5, c6,c9
3.2. Elicitation Techniques c4s5 c6
4. Requirements Analysis
4.1. Requirements Classification c4s1 c12
4.2. Conceptual Modeling c4s5 c11
4.3. Architectural Design and Requirements Allocation c10s4 c17
4.4. Requirements Negotiation c4s5 c7
4.5. Formal Analysis c12s5
5. Requirements Specification
5.1. System Definition Document c4s2 c10
c4s2, c12s2,
5.2. System Requirements Specification c12s3, c12s4, c10
c12s5
5.3. Software Requirements Specification c4s3 c10
6. Requirements Validation
6.1. Requirements Reviews c4s6 c15
6.2. Prototyping c4s6 c13
6.3. Model Validation c4s6 c15
6.4. Acceptance Tests c4s6 c15
Wiegers 2003
[2*]
Sommerville 2011
[1*]
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
FURTHER READINGS This paper is a classic reference work on a key
I. Alexander and L. Beus-Dukic,Discovering element of requirements management. Based on
Requirements [5]. empirical studies, it sets out the reasons for and
the barriers to the effective tracing of
An easily digestible and practically oriented requirements. It is essential reading for an
book on software requirements, this is perhaps understanding of why requirements tracing is an
the best of current textbooks on how the various essential element of an effective software
elements of software requirements fit together. process.
It is full of practical advice on (for example)
how to identify the various system stakeholders N. Maiden and C. Ncube, Acquiring COTS
and how to evaluate alternative solutions. Its Software Selection Requirements [9].
coverage is exemplary and serves as a useful
This paper is significant because it recognises
reference for key techniques such as use case
explicitly that software products often integrate
modeling and requirements prioritization.
third-party components. It offers insights into
the problems of selecting off-the-shelf software
C. Potts, K. Takahashi, and A. Antn,
to satisfy requirements: there is usually a
InquiryBased Requirements Analysis [6].
mismatch. This challenges some of the
assumptions underpinning much of traditional
This paper is an easily digested account of work
requirements handling, which tends to assume
that has proven to be very influential in the
custom software.
development of requirements handling. It
REFERENCES
describes how and why the elaboration of
requirements cannot be a linear process by [1*] I. Sommerville, SoftwareEngineering, 9th
which the analyst simply transcribes and ed., Addison-Wesley, 2011.
reformulates requirements elicited from the
customer. The role of scenarios is described in a [2*] K.E. Wiegers, SoftwareRequirements, 2nd
way that helps to define their use in discovering ed., Microsoft Press, 2003.
and describing requirements.
A. van Lamsweerde, Requirements [3] INCOSE, SystemsEngineeringHandbook:
Engineering:FromSystemGoalstoUML AGuideforSystemLifeCycleProcesses
ModelstoSoftwareSpecifications [7]. andActivities, version 3.2.2, International
Council on Systems Engineering, 2012.
Serves as a good introduction to requirements
engineering but its unique value is as a [4] S. Friedenthal, A. Moore, and R. Steiner, A
reference book for the KAOS goal-oriented PracticalGuidetoSysML:TheSystems
requirements modelling language. Explains why ModelingLanguage, 2nd ed., Morgan
goal modelling is useful and shows how it can Kaufmann, 2012.
integrate with mainstream modelling techniques
[5] I. Alexander and L. Beus-Deukic,
using UML.
DiscoveringRequirements:HowtoSpecify
ProductsandServices, Wiley, 2009.
O. Gotel and A. Finkelstein, An Analysis of the
[6] C. Potts, K. Takahashi, and A.I. Antn,
Requirements Traceability Problem [8].
Inquiry-Based Requirements Analysis, [8] O. Gotel and C.W. Finkelstein, An Analysis

IEEESoftware,vol. 11, no. 2, Mar. 1994, of the Requirements Traceability Problem,
pp. 2132. Proc.1stIntlConf.RequirementsEng.,
IEEE, 1994.
[7] A. van Lamsweerde, Requirements
Engineering:FromSystemGoalstoUML [9] N.A. Maiden and C. Ncube, Acquiring
ModelstoSoftwareSpecifications, Wiley, COTS Software Selection Requirements,
2009. IEEESoftware,vol. 15, no. 2, Mar.Apr.
1998, pp. 4656.
CHAPTER 2 SOFTWARE DESIGN
ACRONYMS software engineers produce various models that

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

Construction, Software Engineering understanding the role and scope of software
Management, Software Engineering Models and design.
Methods, Software Quality, and Computing
Foundations KAs. 1.1. GeneralDesignConcepts
[4*, c1]
BREAKDOWN OF TOPICS FOR
SOFTWARE DESIGN

Design KA is shown in Figure 2.1.
1.Software Design Fundamentals
The concepts, notions, and terminology

introduced here form an underlying basis for
In the general sense, design can be viewed as a Software design principles are key notions that
form of problem solving. For example, the provide the basis for many different software
concept of a wicked problema problem with design approaches and concepts. Software
no definitive solutionis interesting in terms of design principles include abstraction; coupling
understanding the limits of design. A number of and cohesion; decomposition and
other notions and concepts are also of interest in modularization; encapsulation/information
understanding design in its general sense: goals, hiding; separation of interface and
constraints, alternatives, representations, and implementation; sufficiency, completeness, and
solutions (see Problem Solving Techniques in primitiveness; and separation of concerns.
the Computing Foundations KA).
Abstraction is a view of an object that
1.2. ContextofSoftwareDesign focuses on the information relevant to a
[4*, c3] particular purpose and ignores the
remainder of the information [1] (see
Software design is an important part of the Abstraction in the Computing Foundations
software development process. To understand KA). In the context of software design, two
the role of software design, we must see how it key abstraction mechanisms are
fits in the software development life cycle. parameterization and specification.
Thus, it is important to understand the major Abstraction by parameterization abstracts
characteristics of software requirements from the details of data representations by
analysis, software design, software construction, representing the data as named parameters.
software testing, and software maintenance. Abstraction by specification leads to three
major kinds of abstraction: procedural
1.3. SoftwareDesignProcess abstraction, data abstraction, and control
[4*, c2] (iteration) abstraction.
CouplingandCohesion.Coupling is
Software design is generally considered a defined as a measure of the
twostep process: interdependence among modules in a
Architectural design (also referred to as computer program, whereas cohesion is
highlevel design and top-level design) defined as a measure of the strength of
describes how software is organized into association of the elements within a
components. module [1].
Detailed design describes the desired Decompositionandmodularization.
behavior of these components. Decomposing and modularizing means that
large software is divided into a number of
The output of these two processes is a set of smaller named components having well-
models and artifacts that record the major defined interfaces that describe component
decisions that have been taken, along with an interactions. Usually the goal is to place
explanation of the rationale for each nontrivial different functionalities and responsibilities
decision. By recording the rationale, long-term in different components.
maintainability of the software product is Encapsulationandinformationhiding
enhanced. means grouping and packaging the internal
details of an abstraction and making those
1.4. SoftwareDesignPrinciples details inaccessible to external entities.
[4*] [5*, c6, c7, c21] [6*, c1, c8, c9] Separationofinterfaceand
implementation.Separating interface and
A principle is a comprehensive and implementation involves defining a
fundamental law, doctrine, or assumption [7]. component by specifying a public interface
(known to the clients) that is separate from 2.1. Concurrency

the details of how the component is realized [5*,
(see encapsulation and information hiding c18]
above).
Sufficiency,completeness,and Design for concurrency is concerned with
primitiveness.Achieving sufficiency and decomposing software into processes, tasks, and
completeness means ensuring that a threads and dealing with related issues of
software component captures all the efficiency, atomicity, synchronization, and
important characteristics of an abstraction scheduling.
and nothing more. Primitiveness means the
design should be based on patterns that are 2.2. ControlandHandlingofEvents
easy to implement. [5*,
Separation of concerns. A concern is an c21]
area of interest with respect to a software
design [8]. A design concern is an area of This design issue is concerned with how to
design that is relevant to one or more of its organize data and control flow as well as how to
stakeholders. Each architecture view frames handle reactive and temporal events through
one or more concerns. Separating concerns various mechanisms such as implicit invocation
by views allows interested stakeholders to and call-backs.
focus on a few things at a time and offers a
2.3. DataPersistence
means of managing complexity [9].
[12*,
c9]
2. Key Issues in Software Design
This design issue is concerned with how to
A number of key issues must be dealt with when
handle long-lived data.
designing software. Some are quality concerns
that all software must addressfor example,
2.4. DistributionofComponents
performance, security, reliability, usability, etc.
[5*,
Another important issue is how to decompose,
c18]
organize, and package software components.
This is so fundamental that all design This design issue is concerned with how to
approaches address it in one way or another (see distribute the software across the hardware
section 1.4, Software Design Principles, and (including computer hardware and network
topic 7, Software Design Strategies and hardware), how the components communicate,
Methods). In contrast, other issues deal with and how middleware can be used to deal with
some aspect of softwares behavior that is not in heterogeneous software.
the application domain, but which addresses
some of the supporting domains [10]. Such 2.5. ErrorandExceptionHandlingandFault
issues, which often crosscut the systems Tolerance
functionality, have been referred to as aspects, [5*,
which tend not to be units of softwares c18]
functional decomposition, but rather to be
properties that affect the performance or This design issue is concerned with how to
semantics of the components in systemic ways prevent, tolerate, and process errors and deal
[11]. A number of these key, crosscutting issues with exceptional conditions.
are discussed in the following sections 2.6. InteractionandPresentation
(presented in alphabetical order). [5*, c16]
This design issue is concerned with how to [14*, c1]

structure and organize interactions with users as
well as the presentation of information (for Different high-level facets of a software design
example, separation of presentation and can be described and documented. These facets
business logic using the Model-View-Controller are often called views: A view represents a
approach). Note that this topic does not specify partial aspect of a software architecture that
user interface details, which is the task of user shows specific properties of a software system
interface design (see topic 4, User Interface [14*]. Views pertain to distinct issues associated
Design). with software designfor example, the logical
view (satisfying the functional requirements) vs.
2.7.Security the process view (concurrency issues) vs. the
[5*, c12, c18] [13*, c4] physical view (distribution issues) vs. the
development view (how the design is broken
Design for security is concerned with how to down into implementation units with explicit
prevent unauthorized disclosure, creation, representation of the dependencies among the
change, deletion, or denial of access to units). Various authors use different
information and other resources. It is also terminologieslike behavioral vs. functional
concerned with how to tolerate security-related vs. structural vs. data modeling views. In
attacks or violations by limiting damage, summary, a software design is a multifaceted
continuing service, speeding repair and artifact produced by the design process and
recovery, and failing and recovering securely. generally composed of relatively independent
Access control is a fundamental concept of and orthogonal views.
security, and one should also ensure the proper
use of cryptology. 3.2. ArchitecturalStyles
[14*, c1, c2, c3, c4, c5]
3.Software Structure and Architecture
An architectural style is a specialization of
In its strict sense, a software architecture is the element and relation types, together with a set of
set of structures needed to reason about the constraints on how they can be used [14*]. An
system, which comprise software elements, architectural style can thus be seen as providing
relations among them, and properties of both the softwares high-level organization. Various
[14*]. During the mid-1990s, however, software authors have identified a number of major
architecture started to emerge as a broader architectural styles:
discipline that involved the study of software
structures and architectures in a more generic General structures (for example, layers,
way. This gave rise to a number of interesting pipes and filters, blackboard)
concepts about software design at different Distributed systems (for example,
levels of abstraction. Some of these concepts clientserver, three-tiers, broker)
can be useful during the architectural design Interactive systems (for example, Model-
(for example, architectural styles) as well as View-
during the detailed design (for example, design Controller, Presentation-Abstraction-Control)
patterns). These design concepts can also be Adaptable systems (for example,
used to design families of programs (also microkernel, reflection)
known as product lines). Interestingly, most of Others (for example, batch, interpreters,
these concepts can be seen as attempts to process control, rule-based).
describe, and thus reuse, design knowledge.
3.1. ArchitecturalStructuresand 3.3. DesignPatterns
Viewpoints [15*, c3, c4, c5]
Succinctly described, a pattern is a common completed software system that can be extended
solution to a common problem in a given by appropriately instantiating specific
context [16]. While architectural styles can be extensions (such as plug-ins).
viewed as patterns describing the high-level
organization of software, other design patterns 4.User Interface Design
can be used to describe details at a lower level.
These lower level design patterns include the User interface design is an essential part of the
following: software design process. User interface design
should ensure that interaction between the
Creational patterns (for example, builder, human and the machine provides for effective
factory, prototype, singleton) operation and control of the machine. For
Structural patterns (for example, adapter, software to achieve its full potential, the user
bridge, composite, decorator, faade, interface should be designed to match the skills,
flyweight, proxy) experience, and expectations of its anticipated
Behavioral patterns (for example, users.
command, interpreter, iterator, mediator,
memento, observer, state, strategy, template, 4.1. GeneralUserInterfaceDesignPrinciples
visitor). [5*, c29-web] [17*, c2]3
3.4. ArchitectureDesignDecisions Learnability. The software should be easy

[5*, c6] to learn so that the user can rapidly start
working with the software.
Architectural design is a creative process. User familiarity. The interface should use
During the design process, software designers terms and concepts drawn from the
have to make a number of fundamental experiences of the people who will use the
decisions that profoundly affect the software software.
and the development process. It is useful to Consistency. The interface should be
think of the architectural design process from a consistent so that comparable operations are
decision-making perspective rather than from an activated in the same way.
activity perspective. Often, the impact on Minimalsurprise.The behavior of software
quality attributes and tradeoffs among should not surprise users.
competing quality attributes are the basis for Recoverability.The interface should provide
design decisions. mechanisms allowing users to recover from
errors.
3.5. FamiliesofProgramsand User guidance. The interface should give
Frameworks meaningful feedback when errors occur and
[5*, c6, c7, c16] provide context-related help to users.
User diversity. The interface should
One approach to providing for reuse of software provide appropriate interaction mechanisms
designs and components is to design families of for diverse types of users and for users with
programs, also known as software product lines. different capabilities (blind, poor eyesight,
This can be done by identifying the deaf, colorblind, etc.).
commonalities among members of such families
and by designing reusable and customizable 4.2. UserInterfaceDesignIssues
components to account for the variability among
family members. 3 Chapter 29 is a web-based chapter available at
In object-oriented (OO) programming, a key http://ifs.host.cs.st-andrews.ac.uk/Books/SE9/
related notion is that of a framework: a partially WebChapters/.
[5*, c29-web] [17*, Commandlanguage. The user issues a

command and provides related parameters
c2] User interface design should solve two key to direct the software what to do.
Natural language. The user issues a
issues: command in natural language. That is, the
natural language is a front end to a
How should the user interact with the command language and is parsed and
software? translated into software commands.
How should information from the software
be presented to the user? 4.4. TheDesignofInformationPresentation
[5*, c29-web] [17*, c2]
User interface design must integrate user
interaction and information presentation. User Information presentation may be textual or
interface design should consider a compromise graphical in nature. A good design keeps the
between the most appropriate styles of information presentation separate from the
interaction and presentation for the software, the information itself. The MVC (Model-View-
background and experience of the software Controller) approach is an effective way to keep
users, and the available devices. information presentation separating from the
information being presented.
4.3. TheDesignofUserInteractionModalities Software engineers also consider software
[5*, c29-web] [17*, c2] response time and feedback in the design of
information presentation. Response time is
User interaction involves issuing commands and generally measured from the point at which a
providing associated data to the software. User user executes a certain control action until the
interaction styles can be classified into the
software responds with a response. An
following primary styles:
indication of progress is desirable while the
software is preparing the response. Feedback
Question-answer. The interaction is
can be provided by restating the users input
essentially restricted to a single question-
while processing is being completed.
answer exchange between the user and the
Abstract visualizations can be used when
software. The user issues a question to the
large amounts of information are to be
software, and the software returns the
presented.
answer to the question.
According to the style of information
Direct manipulation. Users interact with
presentation, designers can also use color to
objects on the computer screen. Direct
enhance the interface. There are several
manipulation often includes a pointing
important guidelines:
device (such as a mouse, trackball, or a
finger on touch screens) that manipulates an Limit the number of colors used.
object and invokes actions that specify what Use color change to show the change of
is to be done with that object. software status.
Menuselection. The user selects a Use color-coding to support the users task.
command from a menu list of commands. Use color-coding in a thoughtful and
Formfill-in. The user fills in the fields of a consistent way.
form. Sometimes fields include menus, in Use colors to facilitate access for people
which case the form has action buttons for with color blindness or color deficiency
the user to initiate action. (e.g., use the change of color saturation and
color brightness, try to avoid blue and red
combinations).
Dont depend on color alone to convey User interface designers can use metaphors and
important information to users with conceptual models to set up mappings between
different capabilities (blindness, poor the software and some reference system known
eyesight, colorblindness, etc.). to the users in the real world, which can help the
users to more readily learn and use the interface.
4.5. UserInterfaceDesignProcess For example, the operation delete file can be
[5*, c29-web] [17*, c2] made into a metaphor using the icon of a trash
can.
User interface design is an iterative process; When designing a user interface, software
interface prototypes are often used to determine engineers should be careful to not use more than
the features, organization, and look of the one metaphor for each concept. Metaphors also
software user interface. This process includes present potential problems with respect to
three core activities: internationalization, since not all metaphors are
meaningful or are applied in the same way
Useranalysis.In this phase, the designer within all cultures.
analyzes the users tasks, the working
environment, other software, and how users 5.Software Design Quality Analysis and
interact with other people. Evaluation
Softwareprototyping.Developing prototype
software help users to guide the evolution of This section includes a number of quality
the interface. analysis and evaluation topics that are
Interface evaluation. Designers can specifically related to software design. (See also
observe users experiences with the the Software Quality KA.)
evolving interface.
4.6. Localizationand 5.1. QualityAttributes
Internationalization [4*, c4]
[17*, c8, c9]
Various attributes contribute to the quality of a
User interface design often needs to consider software design, including various -ilities
internationalization and localization, which are (maintainability, portability, testability,
means of adapting software to the different usability) and -nesses (correctness,
languages, regional differences, and the robustness). There is an interesting distinction
technical requirements of a target market. between quality attributes discernible at runtime
Internationalization is the process of designing a (for example, performance, security,
software application so that it can be adapted to availability, functionality, usability), those not
various languages and regions without major discernible at runtime (for example,
engineering changes. Localization is the process modifiability, portability, reusability, testability),
of adapting internationalized software for a and those related to the architectures intrinsic
specific region or language by adding locale- qualities (for example, conceptual integrity,
specific components and translating the text. correctness, completeness). (See also the
Localization and internationalization should Software Quality KA.)
consider factors such as symbols, numbers,
currency, time, and measurement units. 5.2. QualityAnalysisandEvaluation
Techniques
4.7. MetaphorsandConceptual [4*, c4] [5*, c24]
Models
[17*, c5]
Various tools and techniques can help in Function-based (structured) design

analyzing and evaluating software design measures: measures obtained by analyzing
quality. functional decomposition; generally
represented using a structure chart
Software design reviews: informal and (sometimes called a hierarchical diagram)
formalized techniques to determine the on which various measures can be
quality of design artifacts (for example, computed.
architecture reviews, design reviews, and Object-oriented design measures: the design
inspections; scenario-based techniques; structure is typically represented as a class
requirements tracing). Software design diagram, on which various measures can be
reviews can also evaluate security. Aids for computed. Measures on the properties of the
installation, operation, and usage (for internal content of each class can also be
example, manuals and help files) can be computed.
reviewed.
Static analysis: formal or semiformal static 6.Software Design Notations
(nonexecutable) analysis that can be used to
evaluate a design (for example, faulttree Many notations exist to represent software
analysis or automated cross-checking). design artifacts. Some are used to describe the
Design vulnerability analysis (for example, structural organization of a design, others to
static analysis for security weaknesses) can represent software behavior. Certain notations
be performed if security is a concern. are used mostly during architectural design and
Formal design analysis uses mathematical others mainly during detailed design, although
models that allow designers to predicate the some notations can be used for both purposes.
behavior and validate the performance of In addition, some notations are used mostly in
the software instead of having to rely the context of specific design methods (see
entirely on testing. Formal design analysis topic 7, Software Design Strategies and
can be used to detect residual specification Methods). Please note that software design is
and design errors (perhaps caused by often accomplished using multiple notations.
imprecision, ambiguity, and sometimes Here, they are categorized into notations for
other kinds of mistakes). (See also the describing the structural (static) view vs. the
Software Engineering Models and Methods behavioral (dynamic) view.
KA.)
Simulation and prototyping: dynamic 6.1. StructuralDescriptions(StaticView)
techniques to evaluate a design (for [4*, c7] [5*, c6, c7] [6*, c4, c5, c6, c7]
example, performance simulation or [12*, c7] [14*, c7]
feasibility prototypes).
The following notations, mostly but not always
5.3. Measures
[4*, c4] [5*, c24] graphical, describe and represent the structural
aspects of a software designthat is, they are
Measures can be used to assess or to used to describe the major components and how
quantitatively estimate various aspects of a they are interconnected (static view):
software design; for example, size, structure, or
quality. Most measures that have been proposed Architecture description languages (ADLs):
depend on the approach used for producing the textual, often formal, languages used to
design. These measures are classified in two describe software architecture in terms of
broad categories: components and connectors.
Class and object diagrams: used to represent a Data flow diagrams (DFDs): used to show data
set of classes (and objects) and their flow among elements. A data flow diagram
interrelationships. provides a description based on modeling the
Component diagrams: used to represent a set of flow of information around a network of
components (physical and replaceable part[s] operational elements, with each element
of a system that [conform] to and [provide] making use of or modifying the information
the realization of a set of interfaces [18]) and flowing into that element [4*]. Data flows
their interrelationships. (and therefore data flow diagrams) can be
Class responsibility collaborator cards (CRCs): used for security analysis, as they offer
used to denote the names of components identification of possible paths for attack and
(class), their responsibilities, and their disclosure of confidential information.
collaborating components names. Decision tables and diagrams: used to represent
Deployment diagrams: used to represent a set of complex combinations of conditions and
(physical) nodes and their interrelationships, actions.
and, thus, to model the physical aspects of Flowcharts: used to represent the flow of control
software. and the associated actions to be performed.
Entity-relationship diagrams (ERDs): used to Sequence diagrams: used to show the
represent conceptual models of data stored in interactions among a group of objects, with
information repositories. emphasis on the time ordering of messages
Interface description languages (IDLs): passed between objects.
programming-like languages used to define State transition and state chart diagrams: used to
the interfaces (names and types of exported show the control flow from state to state and
operations) of software components. how the behavior of a component changes
Structure charts: used to describe the calling based on its current state in a state machine.
structure of programs (which modules call, Formal specification languages: textual
and are called by, which other modules). languages that use basic notions from
mathematics (for example, logic, set,
6.2. BehavioralDescriptions(DynamicView) sequence) to rigorously and abstractly define
[4*, c7, c13] [5*, c6, c7] [6*, c4, c5, c6, c7] software component interfaces and behavior,
[14*, c8] often in terms of pre- and postconditions. (See
also the Software Engineering Models and
The following notations and languages, some Methods KA.)
graphical and some textual, are used to describe Pseudo code and program design languages
the dynamic behavior of software systems and (PDLs): structured programming-like
components. Many of these notations are useful languages used to describe, generally at the
mostly, but not exclusively, during detailed detailed design stage, the behavior of a
design. Moreover, behavioral descriptions can procedure or method.
include a rationale for design decision such as 7.Software Design Strategies and Methods
how a design will meet security requirements.
Activity diagrams: used to show control flow There exist various general strategies to help
from activity to activity. Can be used to guide the design process. In contrast with
represent concurrent activities. general strategies, methods are more specific in
Communication diagrams: used to show the that they generally provide a set of notations to
interactions that occur among a group of be used with the method, a description of the
objects; emphasis is on the objects, their links, process to be used when following the method,
and the messages they exchange on those and a set of guidelines for using the method.
links. Such methods are useful as a common
framework for teams of software engineers.
(See also the Software Engineering Models and been proposed as an alternative approach to OO
Methods KA). design.
7.1. GeneralStrategies 7.4. DataStructure-CenteredDesign

[4*, c8, c9, c10] [12*, c7] [4*, c14, c15]
Some often-cited examples of general strategies Data structure-centered design starts from the
useful in the design process include the data structures a program manipulates rather
divideand-conquer and stepwise refinement than from the function it performs. The software
strategies, top-down vs. bottom-up strategies, engineer first describes the input and output
and strategies making use of heuristics, use of data structures and then develops the programs
patterns and pattern languages, and use of an control structure based on these data structure
iterative and incremental approach. diagrams. Various heuristics have been
proposed to deal with special casesfor
7.2. Function-Oriented(Structured) example, when there is a mismatch between the
Design input and output structures.
[4*, c13]
7.5. Component-BasedDesign(CBD)
This is one of the classical methods of software [4*, c17]
design, where decomposition centers on
identifying the major software functions and A software component is an independent unit,
then elaborating and refining them in a having well-defined interfaces and
hierarchical topdown manner. Structured design dependencies that can be composed and
is generally used after structured analysis, thus deployed independently. Component-based
producing (among other things) data flow design addresses issues related to providing,
diagrams and associated process descriptions. developing, and integrating such components in
Researchers have proposed various strategies order to improve reuse. Reused and off-the-shelf
(for example, transformation analysis, software components should meet the same
transaction analysis) and heuristics (for security requirements as new software. Trust
example, fan-in/fan-out, scope of effect vs. management is a design concern; components
scope of control) to transform a DFD into a treated as having a certain degree of
software architecture generally represented as a trustworthiness should not depend on less
structure chart. trustworthy components or services.
7.3. Object-OrientedDesign 7.6.OtherMethods

[4*, c16] [5*, c19, c21]
Numerous software design methods based on Other interesting approaches also exist (see the
objects have been proposed. The field has Software Engineering Models and Methods
evolved from the early object-oriented (OO) KA). Iterative and adaptive methods implement
design of the mid-1980s (noun = object; verb = software increments and reduce emphasis on
method; adjective = attribute), where rigorous software requirement and design.
inheritance and polymorphism play a key role, Aspect-oriented design is a method by which
to the field of component-based design, where software is constructed using aspects to
metainformation can be defined and accessed implement the crosscutting concerns and
(through reflection, for example). Although OO extensions that are identified during the
designs roots stem from the concept of data software requirements process. Service-oriented
abstraction, responsibility-driven design has architecture is a way to build distributed
software using web services executed on the software development process. They can
distributed computers. Software systems are support part or whole of the following activities:
often constructed by using services from
different providers because standard protocols to translate the requirements model into a
(such as HTTP, HTTPS, SOAP) have been design representation;
designed to support service communication and to provide support for representing
service information exchange. functional components and their
8. Software Design Tools interface(s);
[14*, c10, Appendix A] to implement heuristics refinement and
partitioning;
Software design tools can be used to support the to provide guidelines for quality assessment.
creation of the software design artifacts during
[13*]
Allen 2008 Nielsen[17
19
Budgen[4*]
2003
Page-Jones
Sommerville 1999 2008
Brookshear
2011
[5*] [6*] Gamma
Clements
[12*] et al.et al. 19
2010
[14*] [15*]
1. Software Design
Fundamentals
1.1. General Design
c1
Concepts
1.2. The Context of
c3
Software Design
1.3. The Software
c2
Design Process
1.4. Software Design c6, c7, c1, c8,
c1
Principles c21 c9
2. Key Issues in
Software Design
2.1. Concurrency c18
2.2. Control and
c21
Handling of Events
2.3. Data c9
Persistence
2.4. Distribution of
c18
Components
2.5. Error and

Exception Handling c18
and Fault Tolerance
2.6. Interaction and
c16
Presentation
c12,
2.7. Security c4
c18
3. Software Structure
and Architecture
3.1. Architectural
Structures and c1
Viewpoints
c1, c2,
3.2. Architectural
c3, c4,
Styles
c5
c3, c4,
3.3. Design Patterns
c5
Budgen[4*]
2003 [13*]
19
Page-Jones 1999
SommervilleBrookshear
2011 2008
[5*] [6*] Gamma
Clements
[12*] et al.et al. 19
2010
[14*] [15*]
3.4. Architecture
c6
Design Decisions
3.5. Families of
c6, c7,
Programs and
c16
Frameworks
4. User Interface
Design
4.1. General User
c29-
Interface Design c2
web
Principle
4.2. User Interface c29-
Design Issues web
4.3. The Design of

c29-
User Interaction
web
Modalities
4.4. The Design
c29-
of Information
web
Presentation
4.5. User Interface c29-
Design Process web
4.6. Localization and
c8, c9
Internationalization
4.7. Metaphors and
c5
Conceptual Models
5. Software Design
Quality Analysis and
Evaluation
5.1. Quality
c4
Attributes
5.2. Quality
Analysis and
c4 c24
Evaluation
Techniques
5.3. Measures c4 c24
[13*]
19
Budgen[4*]
2003
Page-Jones
Brookshear
2011
[5*] [6*] Gamma
Clements
[12*] et al.et al. 19
2010
[14*] [15*]
6. Software Design
Notations
6.1. Structural
c4, c5,
Descriptions (Static c7 c6, c7 c7 c7
c6, c7
View)
6.2. Behavioral
c7, c13, c4, c5,
Descriptions c6, c7 c8
c18 c6, c7
(Dynamic View)
7. Software Design
Strategies and
Methods
7.1. General c8, c9,
c7
Strategies c10
7.2.
FunctionOriented c13
(Structured) Design
7.3. Object-Oriented
c16
Design
7.4. Data Structure- c14,
Centered Design c15
7.5. Component-
c17
Based Design (CBD)
c19,
7.6. Other Methods
c21
8. Software Design c10,
Tools App. A
FURTHER READINGS such as end-users, developers, and project
managers.
Roger Pressman, SoftwareEngineering:A
PractitionersApproach(SeventhEdition) Len Bass, Paul Clements, and Rick Kazman,
[19]. SoftwareArchitectureinPractice [21].
For roughly three decades, Roger Pressmans This book introduces the concepts and best
SoftwareEngineering:APractitioners practices of software architecture, meaning how
Approach has been one of the worlds leading software is structured and how the softwares
textbooks in software engineering. Notably, this components interact. Drawing on their own
complementary textbook to [5*] experience, the authors cover the essential
comprehensively presents software design technical topics for designing, specifying, and
including design concepts, architectural design, validating software architectures. They also
component-level design, user interface design, emphasize the importance of the business
pattern-based design, and web application context in which large software is designed.
design. Their aim is to present software architecture in a
real-world setting, reflecting both the
The 4+1 View Model of Architecture [20]. opportunities and constraints that organizations
encounter. This is one of the best books
The seminal paper The 4+1 View Model currently available on software architecture.
organizes a description of a software REFERENCES
architecture using five concurrent views. The
four views of the model are the logical view, the [1] ISO/IEC/IEEE24765:2010Systemsand
development view, the process view, and the SoftwareEngineeringVocabulary, ISO/
physical view. In addition, selected use cases or IEC/IEEE, 2010.
scenarios are utilized to illustrate the
architecture. Hence, the model contains 4+1 [2] IEEEStd.12207-2008(a.k.a.ISO/IEC
views. The views are used to describe the
software as envisioned by different stakeholders
12207:2008)StandardforSystemsand [12*] J.G. Brookshear, ComputerScience:An

SoftwareEngineeringSoftwareLife Overview, 10th ed., Addison-Wesley, 2008.
CycleProcesses, IEEE, 2008.
[13*] J.H. Allen et al., SoftwareSecurity
[3] T. DeMarco, The Paradox of Software Engineering:AGuideforProject
Architecture and Design, Stevens Prize Managers, Addison-Wesley, 2008.
Lecture, 1999.
[14*] P. Clements et al., DocumentingSoftware
[4*] D. Budgen, SoftwareDesign, 2nd ed., Architectures:ViewsandBeyond, 2nd ed.,
Addison-Wesley, 2003. Pearson Education, 2010.
[5*] I. Sommerville, SoftwareEngineering, 9th [15*] E. Gamma et al., DesignPatterns:

ed., Addison-Wesley, 2011. ElementsofReusableObject-Oriented
Software, 1st ed., Addison-Wesley
[6*] M. Page-Jones, Fundamentalsof Professional, 1994.
ObjectOrientedDesigninUML, 1st ed.,
AddisonWesley, 1999. [16] I. Jacobson, G. Booch, and J. Rumbaugh,
TheUnifiedSoftwareDevelopmentProcess,
[7] Merriam-WebstersCollegiateDictionary, Addison-Wesley Professional, 1999.
11th ed., 2003. [17*] J. Nielsen, UsabilityEngineering, Morgan
Kaufmann, 1993.
[8] IEEEStd.1069-2009Standardfor
InformationTechnologySystemsDesign [18] G. Booch, J. Rumbaugh, and I. Jacobson,
SoftwareDesignDescriptions, IEEE, 2009. The Unified Modeling Language User
Guide, Addison-Wesley, 1999.
[9] ISO/IEC42010:2011SystemsandSoftware
EngineeringRecommendedPracticefor [19] R.S. Pressman, SoftwareEngineering:A
ArchitecturalDescriptionof PractitionersApproach, 7th ed.,
SoftwareIntensiveSystems, ISO/IEC, 2011. McGrawHill, 2010.
[10] J. Bosch, DesignandUseofSoftware [20] P.B. Kruchten, The 4+1 View Model of
Architectures:AdoptingandEvolvinga Architecture, IEEESoftware,vol. 12, no.
Product-LineApproach, ACM Press, 2000. 6, 1995, pp. 4255.
[11] G. Kiczales et al., Aspect-Oriented [21] L. Bass, P. Clements, and R. Kazman,

Programming, Proc.11thEuropeanConf. SoftwareArchitectureinPractice, 3rd ed.,
Object-OrientedProgramming (ECOOP Addison-Wesley Professional, 2013.
97), Springer, 1997.
CHAPTER 3 SOFTWARE CONSTRUCTION
ACRONYMS Integrated Development

IDE
Application Programming Environment
API
Interface OMG Object Management Group
COTS Commercial Off-the-Shelf Portable Operating System
POSIX
GUI Graphical User Interface Interface
TDD Test-Driven Development closely linked to the Software Configuration

Management KA.
UML Unified Modeling Language While software quality is important in all the
INTRODUCTION KAs, code is the ultimate deliverable of a
software project, and thus the Software Quality
The term software construction refers to the
KA is closely linked to the Software
detailed creation of working software through a
Construction KA.
combination of coding, verification, unit testing,
Since software construction requires
integration testing, and debugging.
knowledge of algorithms and of coding
The Software Construction knowledge area
practices, it is closely related to the Computing
(KA) is linked to all the other KAs, but it is
Foundations KA, which is concerned with the
most strongly linked to Software Design and
computer science foundations that support the
Software Testing because the software
design and construction of software products. It
construction process involves significant
is also related to project management, insofar as
software design and testing. The process uses
the management of construction can present
the design output and provides an input to
considerable challenges.
testing (design and testing in this case
referring to the activities, not the KAs). BREAKDOWN OF TOPICS FOR
Boundaries between design, construction, and SOFTWARE CONSTRUCTION
testing (if any) will vary depending on the
software life cycle processes that are used in a Figure 3.1 gives a graphical representation of
project. the top-level decomposition of the breakdown
Although some detailed design may be for the Software Construction KA.
performed prior to construction, much design
work is performed during the construction 1. Software Construction Fundamentals
activity. Thus, the Software Construction KA is
closely linked to the Software Design KA. Software construction fundamentals include
Throughout construction, software engineers
both unit test and integration test their work. minimizing complexity
Thus, the Software Construction KA is closely anticipating change
linked to the Software Testing KA as well. constructing for verification
Software construction typically produces the reuse
highest number of configuration items that need standards in construction.
to be managed in a software project (source
files, documentation, test cases, and so on). The first four concepts apply to design as well
Thus, the Software Construction KA is also as to construction. The following sections define
3-1
Figure 3.1. Breakdown of Topics for the Software Construction KA

these concepts and describe how they apply to Constructing for verification means building
construction. software in such a way that faults can be readily
found by the software engineers writing the
1.1. MinimizingComplexity software as well as by the testers and users
[1*] during independent testing and operational
activities. Specific techniques that support
Most people are limited in their ability to hold constructing for verification include following
complex structures and information in their coding standards to support code reviews and
working memories, especially over long periods unit testing, organizing code to support
of time. This proves to be a major factor automated testing, and restricting the use of
influencing how people convey intent to complex or hard-to-understand language
computers and leads to one of the strongest structures, among others.
drives in software construction: minimizing
complexity. The need to reduce complexity 1.4. Reuse
applies to essentially every aspect of software [2*]
construction and is particularly critical to testing
of software constructions. Reuse refers to using existing assets in solving
In software construction, reduced complexity different problems. In software construction,
is achieved through emphasizing code creation typical assets that are reused include libraries,
that is simple and readable rather than clever. It modules, components, source code, and
is accomplished through making use of commercial off-the-shelf (COTS) assets. Reuse
standards (see section 1.5, Standards in is best practiced systematically, according to a
Construction), modular design (see section 3.1, well-defined, repeatable process. Systematic
Construction Design), and numerous other reuse can enable significant software
specific techniques (see section 3.3, Coding). It productivity, quality, and cost improvements.
is also supported by construction-focused Reuse has two closely related facets:
quality techniques (see section 3.7, Construction construction for reuse and construction with
Quality). reuse. The former means to create reusable
software assets, while the latter means to reuse
1.2. AnticipatingChange software assets in the construction of a new
[1*] solution. Reuse often transcends the boundary
of projects, which means reused assets can be
Most software will change over time, and the constructed in other projects or organizations.
anticipation of change drives many aspects of
software construction; changes in the 1.5. StandardsinConstruction
environments in which software operates also [1*]
affect software in diverse ways.
Anticipating change helps software engineers Applying external or internal development
build extensible software, which means they can standards during construction helps achieve a
enhance a software product without disrupting projects objectives for efficiency, quality, and
the underlying structure. cost. Specifically, the choices of allowable
Anticipating change is supported by many programming language subsets and usage
specific techniques (see section 3.3, Coding). standards are important aids in achieving higher
security.
1.3. ConstructingforVerification Standards that directly affect construction
[1*] issues include
communication methods (for example, tend to emphasize the activities that precede
standards for document formats and construction (requirements and design) and to
contents) create more distinct separations between
programming languages (for example, activities. In these models, the main emphasis of
language standards for languages like Java construction may be coding.
and C++) Other models are more iterativesuch as
coding standards (for example, standards evolutionary prototyping and agile
for naming conventions, layout, and development. These approaches tend to treat
indentation) construction as an activity that occurs
platforms (for example, interface standards concurrently with other software development
for operating system calls) activities (including requirements, design, and
tools (for example, diagrammatic standards planning) or that overlaps them. These
for notations like UML (Unified Modeling approaches tend to mix design, coding, and
Language)). testing activities, and they often treat the
combination of activities as construction (see
Use of external standards. Construction the Software Management and Software Process
depends on the use of external standards for KAs).
construction languages, construction tools, Consequently, what is considered to be
technical interfaces, and interactions between construction depends to some degree on the
the Software Construction KA and other KAs. life cycle model used. In general, software
Standards come from numerous sources, construction is mostly coding and debugging,
including hardware and software interface but it also involves construction planning,
specifications (such as the Object Management detailed design, unit testing, integration testing,
Group (OMG)) and international organizations and other activities.
(such as the IEEE or ISO).
Useofinternalstandards. Standards may also 2.2. ConstructionPlanning
be created on an organizational basis at the [1*]
corporate level or for use on specific projects.
These standards support coordination of group The choice of construction method is a key
activities, minimizing complexity, anticipating aspect of the construction-planning activity. The
change, and constructing for verification. choice of construction method affects the extent
to which construction prerequisites are
2.Managing Construction performed, the order in which they are
performed, and the degree to which they should
2.1. ConstructioninLifeCycleModels be completed before construction work begins.
[1*] The approach to construction affects the
project teams ability to reduce complexity,
Numerous models have been created to develop anticipate change, and construct for verification.
software; some emphasize construction more Each of these objectives may also be addressed
than others. at the process, requirements, and design levels
Some models are more linear from the but they will be influenced by the choice of
construction point of viewsuch as the construction method.
waterfall and staged-delivery life cycle models. Construction planning also defines the order
These models treat construction as an activity in which components are created and integrated,
that occurs only after significant prerequisite the integration strategy (for example, phased or
work has been completedincluding detailed incremental integration), the software quality
requirements work, extensive design work, and management processes, the allocation of task
detailed planning. The more linear approaches
assignments to specific software engineers, and The details of the design activity at the
other tasks, according to the chosen method. construction level are essentially the same as
described in the Software Design KA, but they
2.3. ConstructionMeasurement are applied on a smaller scale of algorithms,
[1*] data structures, and interfaces.
Numerous construction activities and artifacts 3.2. ConstructionLanguages

can be measuredincluding code developed, [1*
code modified, code reused, code destroyed, ] Construction languages include all forms of
code complexity, code inspection statistics, communication by which a human can specify
fault-fix and fault-find rates, effort, and an executable problem solution to a problem.
scheduling. These measurements can be useful Construction languages and their
for purposes of managing construction, ensuring implementations (for example, compilers) can
quality during construction, and improving the affect software quality attributes of
construction process, among other uses (see the performance, reliability, portability, and so forth.
Software Engineering Process KA for more on They can be serious contributors to security
measurement). vulnerabilities.
3.Practical Considerations The simplest type of construction language is
a configurationlanguage, in which software
Construction is an activity in which the software engineers choose from a limited set of
engineer has to deal with sometimes chaotic and predefined options to create new or custom
changing real-world constraints, and he or she software installations. The text-based
must do so precisely. Due to the influence of configuration files used in both the Windows
realworld constraints, construction is more and Unix operating systems are examples of
driven by practical considerations than some this, and the menu-style selection lists of some
other KAs, and software engineering is perhaps program generators constitute another example
most craftlike in the construction activities. of a configuration language.
Toolkit languages are used to build
3.1. ConstructionDesign applications out of elements in toolkits
[1*] (integrated sets of application-specific reusable
parts); they are more complex than
Some projects allocate considerable design configuration languages. Toolkit languages may
activity to construction, while others allocate be explicitly defined as application
design to a phase explicitly focused on design. programming languages, or the applications
Regardless of the exact allocation, some may simply be implied by a toolkits set of
detailed design work will occur at the interfaces.
construction level, and that design work tends to Scriptinglanguages are commonly used kinds
be dictated by constraints imposed by the real- of application programming languages. In some
world problem that is being addressed by the scripting languages, scripts are called batch files
software. or macros.
Just as construction workers building a Programminglanguages are the most flexible
physical structure must make small-scale type of construction languages. They also
modifications to account for unanticipated gaps contain the least amount of information about
in the builders plans, software construction specific application areas and development
workers must make modifications on a smaller processes therefore, they require the most
or larger scale to flesh out details of the software training and skill to use effectively. The choice
design during construction. of programming language can have a large
effect on the likelihood of vulnerabilities being
introduced during coding for example, The following considerations apply to the
uncritical usage of C and C++ are questionable software construction coding activity:
choices from a security viewpoint.
There are three general kinds of notation used Techniques for creating understandable
for programming languages, namely source code, including naming conventions
and source code layout;
linguistic (e.g., C/C++, Java) formal (e.g., Use of classes, enumerated types, variables,
Event-B) named constants, and other similar entities;
visual (e.g., MatLab). Use of control structures;
Handling of error conditionsboth
Linguisticnotationsare distinguished in anticipated and exceptional (input of bad
particular by the use of textual strings to data, for example);
represent complex software constructions. The Prevention of code-level security breaches
combination of textual strings into patterns may (buffer overflows or array index bounds, for
have a sentence-like syntax. Properly used, each example);
such string should have a strong semantic Resource usage via use of exclusion
connotation providing an immediate intuitive mechanisms and discipline in accessing
understanding of what will happen when the serially reusable resources (including
software construction is executed. threads and database locks);
Formalnotationsrely less on intuitive, Source code organization (into statements,
everyday meanings of words and text strings routines, classes, packages, or other
and more on definitions backed up by precise, structures);
unambiguous, and formal (or mathematical) Code documentation;
definitions. Formal construction notations and Code tuning,
formal methods are at the semantic base of most 3.4. ConstructionTesting
forms of system programming notations, where [1*]
accuracy, time behavior, and testability are more
important than ease of mapping into natural Construction involves two forms of testing,
language. Formal constructions also use which are often performed by the software
precisely defined ways of combining symbols engineer who wrote the code:
that avoid the ambiguity of many natural
language constructions. Unit testing Integration testing.
Visualnotations rely much less on the textual
notations of linguistic and formal construction The purpose of construction testing is to
and instead rely on direct visual interpretation reduce the gap between the time when faults are
and placement of visual entities that represent inserted into the code and the time when those
the underlying software. Visual construction faults are detected, thereby reducing the cost
tends to be somewhat limited by the difficulty of incurred to fix them. In some instances, test
making complex statements using only the cases are written after code has been written. In
arrangement of icons on a display. However, other instances, test cases may be created before
these icons can be powerful tools in cases where code is written.
the primary programming task is simply to build Construction testing typically involves a
and adjust a visual interface to a program, the subset of the various types of testing, which are
detailed behavior of which has an underlying described in the Software Testing KA. For
definition. instance, construction testing does not typically
include system testing, alpha testing, beta
3.3. Coding testing, stress testing, configuration testing,
[1*]
usability testing, or other more specialized kinds the-shelf software often have the sameor
of testing. betterquality requirements as newly
Two standards have been published on the developed software (for example, security
topic of construction testing: IEEE Standard level).
829-1998,IEEE StandardforSoftwareTest The tasks related to software construction
Documentation, and IEEE Standard 1008-1987, with reuse during coding and testing are as
IEEEStandardforSoftwareUnitTesting. follows:
(See sections 2.1.1., Unit Testing, and 2.1.2.,
Integration Testing, in the Software Testing KA The selection of the reusable units,
for more specialized reference material.) databases, test procedures, or test data.
The evaluation of code or test reusability.
3.5. ConstructionforReuse The integration of reusable software assets
[2*] into the current software.
The reporting of reuse information on new
Construction for reuse creates software that has code, test procedures, or test data.
the potential to be reused in the future for the
present project or other projects taking a 3.7.ConstructionQuality
broadbased, multisystem perspective. [1*]
Construction for reuse is usually based on
variability analysis and design. To avoid the In addition to faults resulting from requirements
problem of code clones, it is desired to and design, faults introduced during
encapsulate reusable code fragments into well- construction can result in serious quality
structured libraries or components. problemsfor example, security vulnerabilities.
The tasks related to software construction for This includes not only faults in security
reuse during coding and testing are as follows: functionality but also faults elsewhere that allow
Variability implementation with bypassing of this functionality and other
mechanisms such as parameterization, security weaknesses or violations.
conditional compilation, design patterns, Numerous techniques exist to ensure the
and so forth. quality of code as it is constructed. The primary
Variability encapsulation to make the techniques used for construction quality include
software assets easy to configure and unit testing and integration testing (see
customize. section 3.4, Construction Testing)
Testing the variability provided by the test-first development (see section 2.2 in the
reusable software assets. Software Testing KA)
Description and publication of reusable use of assertions and defensive
software assets. programming
debugging
3.6. ConstructionwithReuse inspections
[2*] technical reviews, including security-
oriented reviews (see section 2.3.2 in the
Construction with reuse means to create new Software Quality KA)
software with the reuse of existing software static analysis (see section 2.3 of the
assets. The most popular method of reuse is to Software Quality KA)
reuse code from the libraries provided by the
language, platform, tools being used, or an The specific technique or techniques selected
organizational repository. Asides from these, the depend on the nature of the software being
applications developed today widely make use constructed as well as on the skillset of the
of many open-source libraries. Reused and off- software engineers performing the construction
activities. Programmers should know good program in small pieces and then combine the
practices and common vulnerabilitiesfor pieces one at a time. Additional test
example, from widely recognized lists about infrastructure, such as stubs, drivers, and mock
common vulnerabilities. Automated static objects, are usually needed to enable
analysis of code for security weaknesses is incremental integration. By building and
available for several common programming integrating one unit at a time (for example, a
languages and can be used in security-critical class or component), the construction process
projects. can provide early feedback to developers and
Construction quality activities are customers. Other advantages of incremental
differentiated from other quality activities by integration include easier error location,
their focus. Construction quality activities focus improved progress monitoring, more fully tested
on code and artifacts that are closely related to units, and so forth.
codesuch as detailed designas opposed to
other artifacts that are less directly connected to 4.Construction Technologies
the code, such as requirements, high-level
designs, and plans. 4.1. APIDesignandUse
[3*]
3.8.Integration
[1*] An application programming interface (API) is
the set of signatures that are exported and
A key activity during construction is the available to the users of a library or a
integration of individually constructed routines, framework to write their applications. Besides
classes, components, and subsystems into a signatures, an API should always include
single system. In addition, a particular software statements about the programs effects and/or
system may need to be integrated with other behaviors (i.e., its semantics).
software or hardware systems. API design should try to make the API easy to
Concerns related to construction integration learn and memorize, lead to readable code, be
include planning the sequence in which hard to misuse, be easy to extend, be complete,
components will be integrated, identifying what and maintain backward compatibility. As the
hardware is needed, creating scaffolding to APIs usually outlast their implementations for a
support interim versions of the software, widely used library or framework, it is desired
determining the degree of testing and quality that the API be straightforward and kept stable
work performed on components before they are to facilitate the development and maintenance of
integrated, and determining points in the project the client applications.
at which interim versions of the software are API use involves the processes of selecting,
tested. learning, testing, integrating, and possibly
Programs can be integrated by means of either extending APIs provided by a library or
the phased or the incremental approach. Phased framework (see section 3.6, Construction with
integration, also called big bang integration, Reuse).
entails delaying the integration of component 4.2. Object-OrientedRuntimeIssues
software parts until all parts intended for release [1*]
in a version are complete. Incremental
integration is thought to offer many advantages Object-oriented languages support a series of
over the traditional phased integrationfor runtime mechanisms including polymorphism
example, easier error location, improved and reflection. These runtime mechanisms
progress monitoring, earlier product delivery, increase the flexibility and adaptability of
and improved customer relations. In incremental objectoriented programs. Polymorphism is the
integration, the developers write and test a ability of a language to support general
operations without knowing until runtime what and postconditions are used, each routine or
kind of concrete objects the software will class is said to form a contract with the rest of
include. Because the program does not know the the program. Furthermore, a contract provides a
exact types of the objects in advance, the exact precise specification of the semantics of a
behaviour is determined at runtime (called routine, and thus helps the understanding of its
dynamic binding). behavior. Design by contract is thought to
Reflection is the ability of a program to improve the quality of software construction.
observe and modify its own structure and Defensive programming means to protect a
behavior at runtime. Reflection allows routine from being broken by invalid inputs.
inspection of classes, interfaces, fields, and Common ways to handle invalid inputs include
methods at runtime without knowing their checking the values of all the input parameters
names at compile time. It also allows and deciding how to handle bad inputs.
instantiation at runtime of new objects and Assertions are often used in defensive
invocation of methods using parameterized class programming to check input values.
and method names.
4.5. ErrorHandling,ExceptionHandling,and
4.3. ParameterizationandGenerics FaultTolerance
[4*] [1*]
Parameterized types, also known as generics The way that errors are handled affects
(Ada, Eiffel) and templates (C++), enable the softwares ability to meet requirements related
definition of a type or class without specifying to correctness, robustness, and other
all the other types it uses. The unspecified types nonfunctional attributes. Assertions are
are supplied as parameters at the point of use. sometimes used to check for errors. Other error
Parameterized types provide a third way (in handling techniquessuch as returning a
addition to class inheritance and object neutral value, substituting the next piece of
composition) to compose behaviors in object- valid data, logging a warning message,
oriented software. returning an error code, or shutting down the
softwareare also used.
4.4. Assertions,DesignbyContract,and Exceptions are used to detect and process
DefensiveProgramming
errors or exceptional events. The basic structure
[1*]
of an exception is that a routine uses throw to
throw a detected exception and an exception
An assertion is an executable predicate thats
handling block will catch the exception in a try-
placed in a programusually a routine or
catch block. The try-catch block may process
macro that allows runtime checks of the
the erroneous condition in the routine or it may
program. Assertions are especially useful in
return control to the calling routine. Exception
high-reliability programs. They enable
handling policies should be carefully designed
programmers to more quickly flush out
following common principles such as including
mismatched interface assumptions, errors that
in the exception message all information that led
creep in when code is modified, and so on.
to the exception, avoiding empty catch blocks,
Assertions are normally compiled into the code
knowing the exceptions the library code throws,
at development time and are later compiled out
perhaps building a centralized exception
of the code so that they dont degrade the
reporter, and standardizing the programs use of
performance.
exceptions.
Design by contract is a development approach
Fault tolerance is a collection of techniques
in which preconditions and postconditions are
that increase software reliability by detecting
included for each routine. When preconditions
errors and then recovering from them if possible
or containing their effects if recovery is not is to construct computer programs the same way
possible. The most common fault tolerance the automation of technological processes is
strategies include backing up and retrying, using done. State-based programming is usually
auxiliary code, using voting algorithms, and combined with object-oriented programming,
replacing an erroneous value with a phony value forming a new composite approach called state-
that will have a benign effect. based,object-orientedprogramming.
A table-driven method is a schema that uses
4.6. ExecutableModels tables to look up information rather than using
[5*] logic statements (such as ifand case). Used in
appropriate circumstances, table-driven code is
Executable models abstract away the details of simpler than complicated logic and easier to
specific programming languages and decisions modify. When using table-driven methods, the
about the organization of the software. Different programmer addresses two issues: what
from traditional software models, a specification information to store in the table or tables, and
built in an executable modeling language like how to efficiently access information in the
xUML (executable UML) can be deployed in table.
various software environments without change.
An executable-model compiler (transformer) 4.8.RuntimeConfigurationand
can turn an executable model into an Internationalization
implementation using a set of decisions about [1*]
the target hardware and software environment.
Thus, constructing executable models can be To achieve more flexibility, a program is often
regarded as a way of constructing executable constructed to support late binding time of its
software. variables. Runtime configuration is a technique
Executable models are one foundation that binds variable values and program settings
supporting the Model-Driven Architecture when the program is running, usually by
(MDA) initiative of the Object Management updating and reading configuration files in a
Group (OMG). An executable model is a way to just-in-time mode.
completely specify a Platform Independent Internationalization is the technical activity of
Model (PIM); a PIM is a model of a solution to preparing a program, usually interactive
a problem that does not rely on any software, to support multiple locales. The
implementation technologies. Then a Platform corresponding activity, localization, is the
Specific Model (PSM), which is a model that activity of modifying a program to support a
contains the details of the implementation, can specific local language. Interactive software
be produced by weaving together the PIM and may contain dozens or hundreds of prompts,
the platform on which it relies. status displays, help messages, error messages,
and so on. The design and construction
4.7.State-BasedandTable-Driven processes should accommodate string and
ConstructionTechniques character-set issues including which character
[1*] set is to be used, what kinds of strings are used,
how to maintain the strings without changing
State-based programming, or automata-based the code, and translating the strings into
programming, is a programming technology different languages with minimal impact on the
using finite state machines to describe program processing code and the user interface.
behaviours. The transition graphs of a state
machine are used in all stages of software 4.9.Grammar-BasedInputProcessing
development (specification, implementation, [1*] [6*]
debugging, and documentation). The main idea
Grammar-based input processing involves message passing, persistence, and a transparent

syntax analysis, or parsing, of the input token location across a network. Middleware can be
stream. It involves the creation of a data viewed as a connector between the components
structure (called a parsetree or syntaxtree) that use the middleware. Modern message-
representing the input data. The inorder oriented middleware usually provides an
traversal of the parse tree usually gives the Enterprise Service Bus (ESB), which supports
expression just parsed. The parser checks the service-oriented interaction and communication
symbol table for the presence of programmer- between multiple software applications.
defined variables that populate the tree. After 4.12. ConstructionMethodsforDistributed
building the parse tree, the program uses it as Software
input to the computational processes. [7*]
4.10.ConcurrencyPrimitives A distributed system is a collection of physically

[7*] separate, possibly heterogeneous computer
systems that are networked to provide the users
A synchronization primitive is a programming with access to the various resources that the
abstraction provided by a programming system maintains. Construction of distributed
language or the operating system that facilitates software is distinguished from traditional
concurrency and synchronization. Well-known software construction by issues such as
concurrency primitives include semaphores, parallelism, communication, and fault tolerance.
monitors, and mutexes. Distributed programming typically falls into
A semaphore is a protected variable or one of several basic architectural categories:
abstract data type that provides a simple but clientserver, 3-tier architecture, n-tier
useful abstraction for controlling access to a architecture, distributed objects, loose coupling,
common resource by multiple processes or or tight coupling (see section 14.3 of the
threads in a concurrent programming Computing Foundations KA and section 3.2 of
environment. the Software Design KA).
A monitor is an abstract data type that
presents a set of programmer-defined operations 4.13. ConstructingHeterogeneousSystems
that are executed with mutual exclusion. A [6*]
monitor contains the declaration of shared
variables and procedures or functions that Heterogeneous systems consist of a variety of
operate on those variables. The monitor specialized computational units of different
construct ensures that only one process at a time types, such as Digital Signal Processors (DSPs),
is active within the monitor. microcontrollers, and peripheral processors.
A mutex (mutual exclusion) is a These computational units are independently
synchronization primitive that grants exclusive controlled and communicate with one another.
access to a shared resource by only one process Embedded systems are typically heterogeneous
or thread at a time. systems.
The design of heterogeneous systems may
4.11. Middleware require the combination of several specification
[3*] [6*] languages in order to design different parts of
the systemin other words, hardware/software
Middleware is a broad classification for codesign. The key issues include multilanguage
software that provides services above the validation, cosimulation, and interfacing.
operating system layer yet below the application During the hardware/software codesign,
program layer. Middleware can provide runtime software development and virtual hardware
containers for software components to provide development proceed concurrently through
stepwise decomposition. The hardware part is 4.16. Test-FirstProgramming

usually simulated in field programmable gate [1*]
arrays (FPGAs) or application-specific
integrated circuits (ASICs). The software part is Test-first programming (also known as
translated into a low-level programming TestDriven DevelopmentTDD) is a popular
language. development style in which test cases are
written prior to writing any code. Test-first
4.14. PerformanceAnalysisandTuning programming can usually detect defects earlier
[1*] and correct them more easily than traditional
programming styles. Furthermore, writing test
Code efficiencydetermined by architecture, cases first forces programmers to think about
detailed design decisions, and data-structure and requirements and design before coding, thus
algorithm selectioninfluences an execution exposing requirements and design problems
speed and size. Performance analysis is the sooner.
investigation of a programs behavior using 5.Software Construction Tools
information gathered as the program executes,
with the goal of identifying possible hot spots in 5.1. DevelopmentEnvironments
the program to be improved. [1*]
Code tuning, which improves performance at
the code level, is the practice of modifying A development environment, or integrated
correct code in ways that make it run more development environment (IDE), provides
efficiently. Code tuning usually involves only comprehensive facilities to programmers for
small-scale changes that affect a single class, a software construction by integrating a set of
single routine, or, more commonly, a few lines development tools. The choices of development
of code. A rich set of code tuning techniques is environments can affect the efficiency and
available, including those for tuning logic quality of software construction.
expressions, loops, data transformations, In additional to basic code editing functions,
expressions, and routines. Using a low-level modern IDEs often offer other features like
language is another common technique for compilation and error detection from within the
improving some hot spots in a program. editor, integration with source code control,
build/ test/debugging tools, compressed or
4.15. PlatformStandards outline views of programs, automated code
[6*] [7*] transforms, and support for refactoring.
Platform standards enable programmers to 5.2. GUIBuilders

develop portable applications that can be [1*]
executed in compatible environments without
changes. Platform standards usually involve a A GUI (Graphical User Interface) builder is a
set of standard services and APIs that software development tool that enables the
compatible platform implementations must developer to create and maintain GUIs in a
implement. Typical examples of platform WYSIWYG (what you see is what you get)
standards are Java mode. A GUI builder usually includes a visual
2 Platform Enterprise Edition (J2EE) and the editor for the developer to design forms and
POSIX standard for operating systems (Portable windows and manage the layout of the widgets
Operating System Interface), which represents a by dragging, dropping, and parameter setting.
set of standards implemented primarily for Some GUI builders can automatically generate
UNIX-based operating systems. the source code corresponding to the visual GUI
design.
Because current GUI applications usually execution, those failed test cases will be
follow the event-driven style (in which the flow automatically flagged and reported.
of the program is determined by events and
event handling), GUI builder tools usually 5.4. Profiling,PerformanceAnalysis,and
provide code generation assistants, which SlicingTools
automate the most repetitive tasks required for [1*]
event handling. The supporting code connects
Performance analysis tools are usually used to
widgets with the outgoing and incoming events
support code tuning. The most common
that trigger the functions providing the
application logic. performance analysis tools are profiling tools.
An execution profiling tool monitors the code
Some modern IDEs provide integrated GUI
while it runs and records how many times each
builders or GUI builder plug-ins. There are also
many standalone GUI builders. statement is executed or how much time the
5.3. UnitTestingTools program spends on each statement or execution
path. Profiling the code while it is running gives
[1*] [2*]
insight into how the program works, where the
Unit testing verifies the functioning of
hot spots are, and where the developers should
software modules in isolation from other
focus the code tuning efforts.
software elements that are separately testable
Program slicing involves computation of the
(for example, classes, routines, components).
set of program statements (i.e., the program
Unit testing is often automated. Developers can
slice) that may affect the values of specified
use unit testing tools and frameworks to extend
variables at some point of interest, which is
and create automated testing environment. With
referred to as a slicing criterion. Program slicing
unit testing tools and frameworks, the developer
can be used for locating the source of errors,
can code criteria into the test to verify the units
program understanding, and optimization
correctness under various data sets. Each
analysis. Program slicing tools compute
individual test is implemented as an object, and
program slices for various programming
a test runner runs all of the tests. During the test
languages using static or dynamic analysis
methods.
McConnell 2004 Gamma et al. 1994

[1*] Clements
Sommerville et al. 2010
[2*]2011
[3*]Mellor
Null Balcer
[4*] and and Lobur
200220
Silberscha
[5*] [6*]
1. Software
Construction
Fundamentals
c2, c3,
c7-c9,
1.1. Minimizing
c24, c27,
Complexity
c28, c31,
c32, c34
c3c5,
1.2. Anticipating
c24, c31,
Change
c32, c34
c8, c20
1.3. Constructing for c23, c31,
Verification c34
1.4. Reuse c16

1.5. Standards in
c4
Construction
2. Managing
Construction
2.1. Construction in c2, c3,
Life Cycle Models c27, c29
c3, c4,
2.2. Construction
c21,
Planning
c27c29
2.3. Construction
c25, c28
Measurement
3. Practical
Considerations
3.1. Construction c3, c5,
Design c24
3.2. Construction
c4
Languages
c5c19,
3.3. Coding
c25c26

[1*] Clements
[2*]2011
[3*]Mellor
Null Balcer
[4*] and and Lobur
200220
Silberscha
[5*] [6*]
3.4. Construction
c22, c23
Testing
3.5. Construction for
c16
Reuse
3.6. Construction
c16
with Reuse
3.7. Construction c8,
Quality c20c25
3.8. Integration c29
4. Construction
Technologies
4.1. API Design and
c7
Use
4.2. Object-Oriented
c6, c7
Runtime Issues
4.3.
Parameterization c1
and Generics
4.4. Assertions,
Design by Contract,
c8, c9
and Defensive
Programming
4.5. Error Handling,
Exception Handling, c3, c8
and Fault Tolerance
4.6. Executable
c1
Models
4.7. State-Based
and Table-Driven
c18
Construction
Techniques
4.8. Runtime
Configuration and c3, c10
Internationalization
4.9. Grammar-Based
c5 c8
Input Processing

[1*] Clements
[2*]2011
[3*]Mellor
Null Balcer
[4*] and and Lobur
200220
Silberscha
[5*] [6*]
4.10. Concurrency
c6
Primitives
4.11. Middleware c1 c8
4.12. Construction
Methods for c2
Distributed Software
4.13. Constructing
Heterogeneous c9
Systems
4.14. Performance
Analysis and c25, c26
Tuning
4.15. Platform
c10 c1
Standards
4.16. Test-First
c22
Programming
5. Construction
Tools
5.1. Development
c30
Environments
5.2. GUI Builders c30

5.3. Unit Testing
c22 c8
Tools
5.4. Profiling,
Performance
c25, c26
Analysis, and
Slicing Tools
FURTHER READINGS [3*] P. Clements et al., DocumentingSoftware
Architectures:ViewsandBeyond, 2nd ed.,
IEEEStd.1517-2010StandardforInformation Pearson Education, 2010.
TechnologySystemandSoftwareLife
CycleProcessesReuseProcesses, IEEE, [4*] E. Gamma et al., DesignPatterns:
2010 [8]. ElementsofReusableObject-Oriented
Software, 1st ed., Addison-Wesley
This standard specifies the processes, activities, Professional, 1994.
and tasks to be applied during each phase of the
software life cycle to enable a software product [5*] S.J. Mellor and M.J. Balcer, Executable
to be constructed from reusable assets. It covers UML:AFoundationforModel-Driven
the concept of reuse-based development and the Architecture, 1st ed., Addison-Wesley,
processes of construction for reuse and 2002.
construction with reuse.
[6*] L. Null and J. Lobur, TheEssentialsof
IEEEStd.12207-2008(a.k.a.ISO/IEC ComputerOrganizationandArchitecture,
12207:2008)StandardforSystemsand 2nd ed., Jones and Bartlett Publishers, 2006.
SoftwareEngineeringSoftwareLife
CycleProcesses, IEEE, 2008 [9]. [7*] A. Silberschatz, P.B. Galvin, and G. Gagne,
OperatingSystemConcepts, 8th ed., Wiley,
This standard defines a series of software 2008.
development processes, including software
construction process, software integration [8] IEEEStd.1517-2010Standardfor
process, and software reuse process. InformationTechnologySystemand
REFERENCES SoftwareLifeCycleProcessesReuse
Processes, IEEE, 2010.
[1*] S. McConnell, CodeComplete, 2nd ed.,
Microsoft Press, 2004. [9] IEEEStd.12207-2008(a.k.a.ISO/IEC
12207:2008)StandardforSystemsand
[2*] I. Sommerville, SoftwareEngineering, 9th SoftwareEngineeringSoftwareLife
ed., Addison-Wesley, 2011. CycleProcesses, IEEE, 2008.
CHAPTER 4 SOFTWARE TESTING
ACRONYMS Testing and Test Control Notation

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

and test plans and procedures should be to correct them. Testing can be seen, then, as a
systematically and continuously developed means for providing information about the
and possibly refinedas software development functionality and quality attributes of the
proceeds. These test planning and test designing software and also for identifying faults in those
activities provide useful input for software cases where error prevention has not been
designers and help to highlight potential effective. It is perhaps obvious but worth
weaknesses, such as design recognizing that software can still contain faults,
oversights/contradictions, or omissions/ even after completion of an extensive testing
ambiguities in the documentation. activity. Software failures experienced after
For many organizations, the approach to delivery are addressed by corrective
software quality is one of prevention: it is maintenance. Software maintenance topics are
obviously much better to prevent problems than covered in the Software Maintenance KA.
In the Software Quality KA (see Software the second question are the test selection
Quality Management Techniques), software criteria.
quality management techniques are notably Several Test Techniques have been developed
categorized into static techniques (no code in the past few decades, and new ones are still
execution) and dynamic techniques (code being proposed. Generally accepted techniques
execution). Both categories are useful. This KA are covered in the third topic.
focuses on dynamic techniques. Test-Related Measures are dealt with in the
Software testing is also related to software fourth topic, while the issues relative to Test
construction (see Construction Testing in the Process are covered in the fifth. Finally,
Software Construction KA). In particular, unit Software Testing Tools are presented in topic
and integration testing are intimately related to six.
software construction, if not part of it. 1.Software Testing Fundamentals
BREAKDOWN OF TOPICS FOR 1.1. Testing-RelatedTerminology

SOFTWARE TESTING
1.1.1. DefinitionsofTesting
The breakdown of topics for the Software andRelated
Testing KA is shown in Figure 4.1. A more Terminology
detailed breakdown is provided in the Matrix of [1*, c1, c2] [2*, c8]
Topics vs. Reference Material at the end of this
KA. Definitions of testing and testing-related
The first topic describes Software Testing terminology are provided in the cited references
Fundamentals. It covers the basic definitions in and summarized as follows.
the field of software testing, the basic
terminology and key issues, and software 1.1.2. Faultsvs.Failures
testings relationship with other activities. [1*, c1s5] [2*, c11]
The second topic, Test Levels, consists of two
(orthogonal) subtopics: the first subtopic lists Many terms are used in the software engineering
the levels in which the testing of large software literature to describe a malfunction: notably
is traditionally subdivided, and the second fault, failure, and error, among others. This
subtopic considers testing for specific conditions terminology is precisely defined in [3, c2]. It is
or properties and is referred to as Objectives of essential to clearly distinguish between the
Testing. Not all types of testing apply to every cause of a malfunction (for which the term fault
software product, nor has every possible type will be used here) and an undesired effect
been listed. observed in the systems delivered service
The test target and test objective together (which will be called a failure). Indeed there
determine how the test set is identified, both may well be faults in the software that never
with regard to its consistencyhowmuch manifest themselves as failures (see Theoretical
testingisenoughforachievingthestated and Practical Limitations of Testing in section
objectiveand to its compositionwhich test 1.2, Key Issues). Thus testing can reveal
cases shouldbe selected for achieving the failures, but it is the faults that can and must be
stated objective (although usually for removed [3]. The more generic term defect can
achieving the stated objective remains implicit be used to refer to either a fault or a failure,
and only the first part of the two italicized when the distinction is not important [3].
questions above is posed). Criteria for However, it should be recognized that the
addressing the first question are referred to as cause of a failure cannot always be
testadequacy criteria, while those addressing unequivocally identified. 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 An oracle is any human or mechanical agent
to remove the failure, but other modifications that decides whether a program behaved
might have worked just as well. To avoid correctly in a given test and accordingly results
ambiguity, one could refer to failure-causing in a verdict of pass or fail. There exist many
inputs instead of faultsthat is, those sets of different kinds of oracles; for example,
inputs that cause a failure to appear. unambiguous requirements specifications,
behavioral models, and code annotations.
1.2. KeyIssues Automation of mechanized oracles can be
difficult and expensive.
1.2.1. TestSelection
Criteria/Test 1.2.5. TheoreticalandPracticalLimitations
AdequacyCriteria ofTesting
(StoppingRules) [1*, c2s7]
[1*, c1s14, c6s6, c12s7]
Testing theory warns against ascribing an
A test selection criterion is a means of selecting unjustified level of confidence to a series of
test cases or determining that a set of test cases successful tests. Unfortunately, most established
is sufficient for a specified purpose. Test results of testing theory are negative ones, in
adequacy criteria can be used to decide when that they state what testing can never achieve as
sufficient testing will be, or has been opposed to what is actually achieved. The most
accomplished [4] (see Termination in section famous quotation in this regard is the Dijkstra
5.1, Practical Considerations). aphorism that program testing can be used to
show the presence of bugs, but never to show
1.2.2. TestingEffectiveness/Objectivesfor their absence [5]. The obvious reason for this is
Testing that complete testing is not feasible in realistic
[1*, c11s4, c13s11] software. Because of this, testing must be driven
based on risk [6, part 1] and can be seen as a
Testing effectiveness is determined by analyzing
risk management strategy.
a set of program executions. Selection of tests to
be executed can be guided by different 1.2.6. TheProblemofInfeasiblePaths
objectives: it is only in light of the objective [1*, c4s7]
pursued that the effectiveness of the test set can
be evaluated. Infeasible paths are control flow paths that
cannot be exercised by any input data. They are
1.2.3. TestingforDefectDiscovery a significant problem in path-based testing,
[1*, c1s14] particularly in automated derivation of test
inputs to exercise control flow paths.
In testing for defect discovery, a successful test
is one that causes the system to fail. This is 1.2.7.Testability
quite different from testing to demonstrate that [1*, c17s2]
the software meets its specifications or other
desired properties, in which case testing is The term software testability has two related
successful if no failures are observed under but different meanings: on the one hand, it
realistic test cases and test environments. refers to the ease with which a given test
coverage criterion can be satisfied; on the other
1.2.4. TheOracleProblem hand, it is defined as the likelihood, possibly
[1*, c1s9, c9s7] measured statistically, that a set of test cases
will expose a failure if the software is faulty. 2.1.1. UnitTesting

Both meanings are important. [1*, c3] [2*, c8]
1.3. RelationshipofTestingtoOtherActivities Unit testing verifies the functioning in isolation

of software elements that are separately testable.
Software testing is related to, but different from, Depending on the context, these could be the
static software quality management techniques, individual subprograms or a larger component
proofs of correctness, debugging, and program made of highly cohesive units. Typically, unit
construction. However, it is informative to testing occurs with access to the code being
consider testing from the point of view of tested and with the support of debugging tools.
software quality analysts and of certifiers. The programmers who wrote the code typically,
but not always, conduct unit testing.
Testing vs. Static Software Quality
Management Techniques (see Software 2.1.2. IntegrationTesting
Quality Management Techniques in the [1*, c7] [2*, c8]
Software Quality KA [1*, c12]).
Testing vs. Correctness Proofs and Formal Integration testing is the process of verifying the
Verification (see the Software Engineering interactions among software components.
Models and Methods KA [1*, c17s2]). Classical integration testing strategies, such as
Testing vs. Debugging (see Construction topdown and bottom-up, are often used with
Testing in the Software Construction KA hierarchically structured software.
and Debugging Tools and Techniques in the Modern, systematic integration strategies are
Computing Foundations KA [1*, c3s6]). typically architecture-driven, which involves
Testing vs. Program Construction (see incrementally integrating the software
Construction Testing in the Software components or subsystems based on identified
Construction KA [1*, c3s2]). functional threads. Integration testing is often an
ongoing activity at each stage of development
2.Test Levels during which software engineers abstract away
lower-level perspectives and concentrate on the
Software testing is usually performed at perspectives of the level at which they are
different levels throughout the development and integrating. For other than small, simple
maintenance processes. Levels can be software, incremental integration testing
distinguished based on the object of testing, strategies are usually preferred to putting all of
which is called the target, or on the purpose, the components together at oncewhich is
which is called the objective (of the test level). often called big bang testing.
2.1. TheTargetoftheTest 2.1.3. SystemTesting

[1*, c1s13] [2*, c8s1] [1*, c8] [2*, c8]
The target of the test can vary: a single module, System testing is concerned with testing the
a group of such modules (related by purpose, behavior of an entire system. Effective unit and
use, behavior, or structure), or an entire system. integration testing will have identified many of
Three test stages can be distinguished: unit, the software defects. System testing is usually
integration, and system. These three test stages considered appropriate for assessing the
do not imply any process model, nor is any one nonfunctional system requirementssuch as
of them assumed to be more important than the security, speed, accuracy, and reliability (see
other two. Functional and Non-Functional Requirements in
the Software Requirements KA and Software
Quality Requirements in the Software Quality The customer or a customers representative

KA). External interfaces to other applications, thus specifies or directly undertakes activities to
utilities, hardware devices, or the operating check that their requirements have been met, or
environments are also usually evaluated at this in the case of a consumer product, that the
level. organization has satisfied the stated
requirements for the target market. This testing
2.2. ObjectivesofTesting activity may or may not involve the developers
[1*, c1s7] of the system.
Testing is conducted in view of specific 2.2.2. InstallationTesting

objectives, which are stated more or less [1*, c12s2]
explicitly and with varying degrees of precision.
Stating the objectives of testing in precise, Often, after completion of system and
quantitative terms supports measurement and acceptance testing, the software is verified upon
control of the test process. installation in the target environment.
Testing can be aimed at verifying different Installation testing can be viewed as system
properties. Test cases can be designed to check testing conducted in the operational
that the functional specifications are correctly environment of hardware configurations and
implemented, which is variously referred to in other operational constraints. Installation
the literature as conformance testing, procedures may also be verified.
correctness testing, or functional testing.
However, several other nonfunctional properties 2.2.3. AlphaandBetaTesting
may be tested as well including performance, [1*, c13s7, c16s6] [2*, c8s4]
reliability, and usability, among many others
(see Models and Quality Characteristics in the Before software is released, it is sometimes
Software Quality KA). given to a small, selected group of potential
Other important objectives for testing include users for trial use (alphatesting) and/or to a
but are not limited to reliability measurement, larger set of representative users (beta testing).
identification of security vulnerabilities, These users report problems with the product.
usability evaluation, and software acceptance, Alpha and beta testing are often uncontrolled
for which different approaches would be taken. and are not always referred to in a test plan.
Note that, in general, the test objectives vary 2.2.4. ReliabilityAchievementandEvaluation
with the test target; different purposes are [1*, c15] [2*, c15s2]
addressed at different levels of testing.
Testing improves reliability by identifying and
The subtopics listed below are those most
correcting faults. In addition, statistical
often cited in the literature. Note that some
measures of reliability can be derived by
kinds of testing are more appropriate for
randomly generating test cases according to the
custom-made software packagesinstallation
operational profile of the software (see
testing, for exampleand others for consumer
Operational Profile in section 3.5, Usage-Based
products, like beta testing.
Techniques). The latter approach is called
operationaltesting. Using reliability growth
2.2.1. Acceptance/QualificationTesting
models, both objectives can be pursued together
[1*, c1s7] [2*, c8s4]
[3] (see Life Test, Reliability Evaluation in
section 4.1, Evaluation of the Program under
Acceptance / qualification testing determines
Test).
whether a system satisfies its acceptance
criteria, usually by checking desired system
2.2.5. RegressionTesting
behaviors against the customers requirements.
[1*, c8s11, c13s3] [1*, c8s8]
According to [7], regression testing is the Stress testing exercises software at the
selective retesting of a system or component to maximum design load, as well as beyond it,
verify that modifications have not caused with the goal of determining the behavioral
unintended effects and that the system or limits, and to test defense mechanisms in critical
component still complies with its specified systems.
requirements. In practice, the approach is to
show that software still passes previously 2.2.9.Back-to-BackTesting
passed tests in a test suite (in fact, it is also [7]
sometimes referred to as nonregression testing).
For incremental development, the purpose of IEEE/ISO/IEC Standard 24765 defines back-
regression testing is to show that software toback testing as testing in which two or more
behavior is unchanged by incremental changes variants of a program are executed with the
to the software, except insofar as it should. In same inputs, the outputs are compared, and
some cases, a tradeoff must be made between errors are analyzed in case of discrepancies.
the assurance given by regression testing every
time a change is made and the resources 2.2.10.RecoveryTesting
required to perform the regression tests, which [1*, c14s2]
can be quite time consuming due to the large
Recovery testing is aimed at verifying software
number of tests that may be executed.
restart capabilities after a system crash or other
Regression testing involves selecting,
disaster.
minimizing, and/or prioritizing a subset of the
test cases in an existing test suite [8].
2.2.11. InterfaceTesting
Regression testing can be conducted at each of
[2*, c8s1.3] [9*, c4s4.5]
the test levels described in section 2.1, The
Target of the Test, and may apply to functional Interface defects are common in complex
and nonfunctional testing. systems. Interface testing aims at verifying
whether the components interface correctly to
2.2.6. PerformanceTesting
provide the correct exchange of data and control
[1*, c8s6]
information. Usually the test cases are generated
from the interface specification. A specific
Performance testing verifies that the software
objective of interface testing is to simulate the
meets the specified performance requirements
use of APIs by end-user applications. This
and assesses performance characteristicsfor
involves the generation of parameters of the API
instance, capacity and response time.
calls, the setting of external environment
2.2.7.SecurityTesting
conditions, and the definition of internal data
[1*, c8s3] [2*, c11s4]
that affect the API.
2.2.12. ConfigurationTesting
Security testing is focused on the verification
[1*, c8s5]
that the software is protected from external
attacks. In particular, security testing verifies the
In cases where software is built to serve
confidentiality, integrity, and availability of the
different users, configuration testing verifies the
systems and its data. Usually, security testing
software under different specified
includes verification against misuse and abuse
configurations.
of the software or system (negative testing).
2.2.13. UsabilityandHumanComputer
2.2.8.StressTesting
InteractionTesting
[10*, c6] experience with similar programs. Ad hoc

testing can be useful for identifying tests cases
The main task of usability and human computer that not easily generated by more formalized
interaction testing is to evaluate how easy it is techniques.
for end users to learn and to use the software. In
general, it may involve testing the software 3.1.2. ExploratoryTesting
functions that supports user tasks,
documentation that aids users, and the ability of Exploratory testing is defined as simultaneous
the system to recover from user errors (see User learning, test design, and test execution [6, part
Interface Design in the Software Design KA). 1]; that is, the tests are not defined in advance in
an established test plan, but are dynamically
3.Test Techniques designed, executed, and modified. The
effectiveness of exploratory testing relies on the
One of the aims of testing is to detect as many software engineers knowledge, which can be
failures as possible. Many techniques have been derived from various sources: observed product
developed to do this [6, part 4]. These behavior during testing, familiarity with the
techniques attempt to break a program by application, the platform, the failure process, the
being as systematic as possible in identifying type of possible faults and failures, the risk
inputs that will produce representative program associated with a particular product, and so on.
behaviors; for instance, by considering
subclasses of the input domain, scenarios, states, 3.2. InputDomain-BasedTechniques
and data flows.
The classification of testing techniques 3.2.1. Equivalence
presented here is based on how tests are Partitioning
generated: from the software engineers [1*, c9s4]
intuition and experience, the specifications, the
code structure, the real or imagined faults to be Equivalence partitioning involves partitioning
discovered, predicted usage, models, or the the input domain into a collection of subsets (or
nature of the application. One category deals equivalent classes) based on a specified
with the combined use of two or more criterion or relation. This criterion or relation
techniques. may be different computational results, a
Sometimes these techniques are classified as relation based on control flow or data flow, or a
white-box (also called glass-box), if the tests are distinction made between valid inputs that are
based on information about how the software accepted and processed by the system and
has been designed or coded, or as black-box if invalid inputs, such as out of range values, that
the test cases rely only on the input/output are not accepted and should generate an error
behavior of the software. The following list message or initiate error processing. A
includes those testing techniques that are representative set of tests (sometimes only one)
commonly used, but some practitioners rely on is usually taken from each equivalency class.
some of the techniques more than others.
3.1. BasedontheSoftwareEngineers 3.2.2. PairwiseTesting
IntuitionandExperience [1*, c9s3]
3.1.1. AdHoc Test cases are derived by combining interesting

values for every pair of a set of input variables
Perhaps the most widely practiced technique is instead of considering all possible
ad hoc testing: tests are derived relying on the combinations. Pairwise testing belongs to
software engineers skill, intuition, and combinatorial testing, which in general also
includes higher-level combinations than pairs: paths in a programs control flow graph. Since
these techniques are referred to as t-wise, exhaustive path testing is generally not feasible
whereby every possible combination of t input because of loops, other less stringent criteria
variables is considered. focus on coverage of paths that limit loop
iterations such as statement coverage, branch
3.2.3. Boundary-Value coverage, and condition/decision testing. The
Analysis adequacy of such tests is measured in
[1*, c9s5] percentages; for example, when all branches
have been executed at least once by the tests,
Test cases are chosen on or near the boundaries 100% branch coverage has been achieved.
of the input domain of variables, with the
underlying rationale that many faults tend to 3.3.2. DataFlow-BasedCriteria
concentrate near the extreme values of inputs. [1*, c5]
An extension of this technique is robustness
testing, wherein test cases are also chosen In data flow-based testing, the control flow
outside the input domain of variables to test graph is annotated with information about how
program robustness in processing unexpected or the program variables are defined, used, and
erroneous inputs. killed (undefined). The strongest criterion, all
definition-use paths, requires that, for each
3.2.4. RandomTesting variable, every control flow path segment from
[1*, c9s7] a definition of that variable to a use of that
definition is executed. In order to reduce the
Tests are generated purely at random (not to be number of paths required, weaker strategies
confused with statistical testing from the such as all-definitions and all-uses are
operational profile, as described in Operational employed.
Profile in section 3.5). This form of testing falls
under the heading of input domain testing since 3.3.3. ReferenceModelsforCode-
the input domain must be known in order to be BasedTesting
able to pick random points within it. Random [1*, c4]
testing provides a relatively simple approach for
test automation; recently, enhanced forms of Although not a technique in itself, the control
random testing have been proposed in which the structure of a program can be graphically
random input sampling is directed by other represented using a flow graph to visualize
input selection criteria [11]. Fuzz testing or codebased testing techniques. A flow graph is a
fuzzing is a special form of random testing directed graph, the nodes and arcs of which
aimed at breaking the software; it is most often correspond to program elements (see Graphs
used for security testing. 3.3. Code-Based and Trees in the Mathematical Foundations
Techniques KA). For instance, nodes may represent
statements or uninterrupted sequences of
3.3.1. ControlFlow-BasedCriteria statements, and arcs may represent the transfer
[1*, c4] of control between nodes.
Control flow-based coverage criteria are aimed 3.4. Fault-BasedTechniques

at covering all the statements, blocks of [1*, c1s14]
statements, or specified combinations of
statements in a program. The strongest of the With different degrees of formalization,
control flowbased criteria is path testing, which faultbased testing techniques devise test cases
aims to execute all entry-to-exit control flow specifically aimed at revealing categories of
likely or predefined faults. To better focus the software, or the operational profile, as closely
test case generation or selection, a fault model as possible. The goal is to infer from the
can be introduced that classifies the different observed test results the future reliability of the
types of faults. software when in actual use. To do this, inputs
3.4.1. ErrorGuessing are assigned probabilities, or profiles, according
[1*, c9s8] to their frequency of occurrence in actual
operation. Operational profiles can be used
In error guessing, test cases are specifically during system testing to guide derivation of test
designed by software engineers who try to cases that will assess the achievement of
anticipate the most plausible faults in a given reliability objectives and exercise relative usage
program. A good source of information is the and criticality of different functions similar to
history of faults discovered in earlier projects, what will be encountered in the operational
as well as the software engineers expertise. environment [3].
3.4.2. MutationTesting 3.5.2. UserObservationHeuristics

[1*, c3s5] [10*, c5, c7]
A mutant is a slightly modified version of the Usability principles can provide guidelines for
program under test, differing from it by a small discovering problems in the design of the user
syntactic change. Every test case exercises both interface [10*, c1s4] (see User Interface Design
the original program and all generated mutants: in the Software Design KA). Specialized
if a test case is successful in identifying the heuristics, also called usability inspection
difference between the program and a mutant, methods, are applied for the systematic
the latter is said to be killed. Originally observation of system usage under controlled
conceived as a technique to evaluate test sets conditions in order to determine how well
(see section 4.2. Evaluation of the Tests people can use the system and its interfaces.
Performed), mutation testing is also a testing Usability heuristics include cognitive
criterion in itself: either tests are randomly walkthroughs, claims analysis, field
generated until enough mutants have been observations, thinking aloud, and even indirect
killed, or tests are specifically designed to kill approaches such as user questionnaires and
surviving mutants. In the latter case, mutation interviews.
testing can also be categorized as a code-based
technique. The underlying assumption of 3.6. Model-BasedTestingTechniques
mutation testing, the coupling effect, is that by
looking for simple syntactic faults, more A model in this context is an abstract (formal)
complex but real faults will be found. For the representation of the software under test or of its
technique to be effective, a large number of software requirements (see Modeling in the
mutants must be automatically generated and Software Engineering Models and Methods
executed in a systematic way [12]. KA). Model-based testing is used to validate
requirements, check their consistency, and
3.5. Usage-BasedTechniques generate test cases focused on the behavioral
aspects of the software. The key components of
3.5.1. OperationalProfile model-based testing are [13]: the notation used
[1*, c15s5] to represent the model of the software or its
requirements; workflow models or similar
In testing for reliability evaluation (also called models; the test strategy or algorithm used for
operational testing), the test environment test case generation; the supporting
reproduces the operational environment of the infrastructure for the test execution; and the
evaluation of test results compared to expected scenario). Both typical and alternate workflows
results. Due to the complexity of the techniques, should be tested [6, part 4]. A special focus on
model-based testing approaches are often used the roles in a workflow specification is targeted
in conjunction with test automation harnesses. in business process testing.
Model-based testing techniques include the
following. 3.7.TechniquesBasedontheNatureofthe
Application
3.6.1. DecisionTables
[1*, c9s6] The above techniques apply to all kinds of
software. Additional techniques for test
Decision tables represent logical relationships derivation and execution are based on the nature
between conditions (roughly, inputs) and actions of the software being tested; for example,
(roughly, outputs). Test cases are systematically object-oriented software
derived by considering every possible component-based software
combination of conditions and their web-based software
corresponding resultant actions. A related concurrent programs
technique is cause-effectgraphing [1*, c13s6]. protocol-based software
real-time systems
3.6.2. Finite-StateMachines safety-critical systems
[1*, c10] service-oriented software
open-source software
By modeling a program as a finite state embedded software
machine, tests can be selected in order to cover
the states and transitions. 3.8.SelectingandCombiningTechniques
3.6.3. FormalSpecifications 3.8.1. CombiningFunctionaland

[1*, c10s11] [2*, c15] Structural
[1*, c9]
Stating the specifications in a formal language
(see Formal Methods in the Software Model-based and code-based test techniques are
Engineering Models and Methods KA) permits often contrasted as functional vs. structural
automatic derivation of functional test cases, testing. These two approaches to test selection
and, at the same time, provides an oracle for are not to be seen as alternatives but rather as
checking test results. complements; in fact, they use different sources
TTCN3 (Testing and Test Control Notation of information and have been shown to
version 3) is a language developed for writing highlight different kinds of problems. They
test cases. The notation was conceived for the could be used in combination, depending on
specific needs of testing telecommunication budgetary considerations.
systems, so it is particularly suitable for testing
complex communication protocols. 3.8.2. Deterministicvs.Random
[1*, c9s6]
3.6.4. WorkflowModels
[2*, c8s3.2, c19s3.1] Test cases can be selected in a deterministic
way, according to one of many techniques, or
Workflow models specify a sequence of randomly drawn from some distribution of
activities performed by humans and/or software inputs, such as is usually done in reliability
applications, usually represented through testing. Several analytical and empirical
graphical notations. Each sequence of actions comparisons have been conducted to analyze
constitutes one workflow (also called a
the conditions that make one approach more also include measurements that determine the
effective than the other. 4. Test-Related frequency with which modules call one another.
Measures
4.1.2. FaultTypes,Classification,and
Sometimes testing techniques are confused with Statistics
testing objectives. Testing techniques can be [9*, c4]
viewed as aids that help to ensure the
achievement of test objectives [6, part 4]. For The testing literature is rich in classifications
instance, branch coverage is a popular testing and taxonomies of faults. To make testing more
technique. Achieving a specified branch effective, it is important to know which types of
coverage measure (e.g., 95% branch coverage) faults may be found in the software under test
should not be the objective of testing per se: it is and the relative frequency with which these
a way of improving the chances of finding faults have occurred in the past. This
failures by attempting to systematically exercise information can be useful in making quality
every program branch at every decision point. predictions as well as in process improvement
To avoid such misunderstandings, a clear (see Defect Characterization in the Software
distinction should be made between test-related Quality KA).
measures that provide an evaluation of the 4.1.3. FaultDensity
program under test, based on the observed test [1*, c13s4] [9*, c4]
outputs, and the measures that evaluate the
thoroughness of the test set. (See Software A program under test can be evaluated by
Engineering Measurement in the Software counting discovered faults as the ratio between
Engineering Management KA for information the number of faults found and the size of the
on measurement programs. See Software program.
Process and Product Measurement in the
Software Engineering Process KA for 4.1.4. LifeTest,ReliabilityEvaluation
information on measures.) [1*, c15] [9*, c3]
Measurement is usually considered
fundamental to quality analysis. Measurement A statistical estimate of software reliability,
may also be used to optimize the planning and which can be obtained by observing reliability
execution of the tests. Test management can use achieved, can be used to evaluate a software
several different process measures to monitor product and decide whether or not testing can be
progress. (See section 5.1, Practical stopped (see section 2.2, Reliability
Considerations, for a discussion of measures of Achievement and Evaluation).
the testing process useful for management
4.1.5. ReliabilityGrowthModels
purposes.)
[1*, c15] [9*, c8]
4.1. EvaluationoftheProgramUnderTest
Reliability growth models provide a prediction
4.1.1. ProgramMeasurementsThatAidin of reliability based on failures. They assume, in
PlanningandDesigningTests general, that when the faults that caused the
[9*, c11] observed failures have been fixed (although
some models also accept imperfect fixes), the
Measures based on software size (for example, estimated products reliability exhibits, on
source lines of code or functional size; see average, an increasing trend. There are many
Measuring Requirements in the Software published reliability growth models. Notably,
Requirements KA) or on program structure can these models are divided into failure-count and
be used to guide testing. Structural measures time-between-failure models.
4.2. EvaluationoftheTestsPerformed In mutation testing (see Mutation Testing in

section 3.4, Fault-Based Techniques), the ratio
4.2.1. Coverage/ThoroughnessMeasures of killed mutants to the total number of
[9*, c11] generated mutants can be a measure of the
effectiveness of the executed test set.
Several test adequacy criteria require that the
test cases systematically exercise a set of 4.2.4. ComparisonandRelativeEffectiveness
elements identified in the program or in the ofDifferentTechniques
specifications (see topic 3, Test Techniques). To
evaluate the thoroughness of the executed tests, Several studies have been conducted to compare
software engineers can monitor the elements the relative effectiveness of different testing
covered so that they can dynamically measure techniques. It is important to be precise as to the
the ratio between covered elements and the total property against which the techniques are being
number. For example, it is possible to measure assessed; what, for instance, is the exact
the percentage of branches covered in the meaning given to the term effectiveness?
program flow graph or the percentage of Possible interpretations include the number of
functional requirements exercised among those tests needed to find the first failure, the ratio of
listed in the specifications document. Code- the number of faults found through testing to all
based adequacy criteria require appropriate the faults found during and after testing, and
instrumentation of the program under test. how much reliability was improved. Analytical
4.2.2. FaultSeeding and empirical comparisons between different
[1*, c2s5] [9*, c6] techniques have been conducted according to
each of the notions of effectiveness specified
In fault seeding, some faults are artificially above.
introduced into a program before testing. When
the tests are executed, some of these seeded 5.Test Process
faults will be revealed as well as, possibly, some
faults that were already there. In theory, Testing concepts, strategies, techniques, and
depending on which and how many of the measures need to be integrated into a defined
artificial faults are discovered, testing and controlled process. The test process
effectiveness can be evaluated and the supports testing activities and provides guidance
remaining number of genuine faults can be to testers and testing teams, from test planning
estimated. In practice, statisticians question the to test output evaluation, in such a way as to
distribution and representativeness of seeded provide assurance that the test objectives will be
faults relative to genuine faults and the small met in a cost-effective way.
sample size on which any extrapolations are
based. Some also argue that this technique 5.1. PracticalConsiderations
should be used with great care since inserting
faults into software involves the obvious risk of 5.1.1. Attitudes/Egoless
leaving them there. Programming
[1*c16] [9*, c15]
4.2.3. MutationScore
[1*, c3s5] 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 5.1.5. Test-Driven

mindset of individual code ownership among Development
programmers and by promoting a collaborative [1*, c1s16]
environment with team responsibility for
anomalies in the code. Test-driven development (TDD) originated as
one of the core XP (extreme programming)
5.1.2. TestGuides practices and consists of writing unit tests prior
[1*, c12s1] [9*, c15s1] to writing the code to be tested (see Agile
Methods in the Software Engineering Models
The testing phases can be guided by various and Method KA). In this way, TDD develops
aimsfor example, risk-based testing uses the the test cases as a surrogate for a software
product risks to prioritize and focus the test requirements specification document rather than
strategy, and scenario-based testing defines test as an independent check that the software has
cases based on specified software scenarios. correctly implemented the requirements. Rather
than a testing strategy, TDD is a practice that
5.1.3. TestProcess requires software developers to define and
Management maintain unit tests; it thus can also have a
[1*, c12] [9*, c15] positive impact on elaborating user needs and
software requirements specifications.
Test activities conducted at different levels (see
topic 2, Test Levels) must be organized 5.1.6. Internalvs.
together with people, tools, policies, and IndependentTestTeam
measuresinto a well-defined process that is an [1*, c16]
integral part of the life cycle.
Formalizing the testing process may also
5.1.4. TestDocumentation involve formalizing the organization of the
andWorkProducts testing team. The testing team can be composed
[1*, c8s12] [9*, c4s5] of internal members (that is, on the project
team, involved or not in software construction),
Documentation is an integral part of the of external members (in the hope of bringing an
formalization of the test process [6, part 3]. Test unbiased, independent perspective), or of both
documents may include, among others, the test internal and external members. Considerations
plan, test design specification, test procedure of cost, schedule, maturity levels of the
specification, test case specification, test log, involved organizations, and criticality of the
and test incident report. The software under test application can guide the decision.
is documented as the test item. Test
documentation should be produced and 5.1.7. Cost/Effort
continually updated to the same level of quality EstimationandTest
as other types of documentation in software ProcessMeasures
engineering. Test documentation should also be [1*, c18s3] [9*, c5s7]
under the control of software configuration
management (see the Software Configuration Several measures related to the resources spent
Management KA). Moreover, test on testing, as well as to the relative fault-finding
documentation includes work products that can effectiveness of the various test phases, are used
provide material for user manuals and user by managers to control and improve the testing
training. process. These test measures may cover such
aspects as number of test cases specified,
number of test cases executed, number of test
cases passed, and number of test cases failed, As shown in the following description,
among others. successful management of test activities
Evaluation of test phase reports can be strongly depends on the software configuration
combined with root-cause analysis to evaluate management process (see the Software
testprocess effectiveness in finding faults as Configuration Management KA).
early as possible. Such an evaluation can be
associated with the analysis of risks. Moreover, 5.2.1. Planning
the resources that are worth spending on testing [1*, c12s1, c12s8]
should be commensurate with the use/criticality
of the application: different techniques have Like all other aspects of project management,
different costs and yield different levels of testing activities must be planned. Key aspects
confidence in product reliability. of test planning include coordination of
personnel, availability of test facilities and
5.1.8. Termination equipment, creation and maintenance of all test-
[9*, c10s4] related documentation, and planning for
possible undesirable outcomes. If more than one
A decision must be made as to how much baseline of the software is being maintained,
testing is enough and when a test stage can be then a major planning consideration is the time
terminated. Thoroughness measures, such as and effort needed to ensure that the test
achieved code coverage or functional coverage, environment is set to the proper configuration.
as well as estimates of fault density or of
operational reliability, provide useful support 5.2.2. Test-CaseGeneration
but are not sufficient in themselves. The [1*, c12s1, c12s3]
decision also involves considerations about the
costs and risks incurred by possible remaining Generation of test cases is based on the level of
failures, as opposed to the costs incurred by testing to be performed and the particular
continuing to test (see Test Selection Criteria / testing techniques. Test cases should be under
Test Adequacy Criteria in section 1.2, Key the control of software configuration
Issues). management and include the expected results
for each test.
5.1.9.TestReuseandTestPatterns
[9*, c2s5] 5.2.3. TestEnvironmentDevelopment
[1*, c12s6]
To carry out testing or maintenance in an
organized and cost-effective way, the means The environment used for testing should be
used to test each part of the software should be compatible with the other adopted software
reused systematically. A repository of test engineering tools. It should facilitate
materials should be under the control of development and control of test cases, as well as
software configuration management so that logging and recovery of expected results,
changes to software requirements or design can scripts, and other testing materials.
be reflected in changes to the tests conducted.
The test solutions adopted for testing some 5.2.4. Execution
application types under certain circumstances, [1*, c12s7]
with the motivations behind the decisions taken,
form a test pattern that can itself be documented Execution of tests should embody a basic
for later reuse in similar projects. principle of scientific experimentation:
5.2. TestActivities everything done during testing should be
performed and documented clearly enough that
another person could replicate the results. declaration, memory leak, programming syntax
Hence, testing should be performed in error), and when they could have been first
accordance with documented procedures using a observed in the software. Defect tracking
clearly defined version of the software under information is used to determine what aspects of
test. software testing and other processes need
improvement and how effective previous
5.2.5. TestResultsEvaluation approaches have been.
[9*, c15]
6.Software Testing Tools
The results of testing should be evaluated to
determine whether or not the testing has been 6.1. TestingToolSupport
successful. In most cases, successful means [1*, c12s11] [9*, c5]
that the software performed as expected and did
not have any major unexpected outcomes. Not Testing requires many labor-intensive tasks,
all unexpected outcomes are necessarily faults running numerous program executions, and
but are sometime determined to be simply noise. handling a great amount of information.
Before a fault can be removed, an analysis and Appropriate tools can alleviate the burden of
debugging effort is needed to isolate, identify, clerical, tedious operations and make them less
and describe it. When test results are error-prone. Sophisticated tools can support test
particularly important, a formal review board design and test case generation, making it more
may be convened to evaluate them. effective.
5.2.6. ProblemReporting/TestLog 6.1.1. SelectingTools

[1*, c13s9] [1*, c12s11]
Testing activities can be entered into a testing Guidance to managers and testers on how to
log to identify when a test was conducted, who select testing tools that will be most useful to
performed the test, what software configuration their organization and processes is a very
was used, and other relevant identification important topic, as tool selection greatly affects
information. Unexpected or incorrect test results testing efficiency and effectiveness. Tool
can be recorded in a problem reporting system, selection depends on diverse evidence, such as
the data for which forms the basis for later development choices, evaluation objectives,
debugging and fixing the problems that were execution facilities, and so on. In general, there
observed as failures during testing. Also, may not be a unique tool that will satisfy
anomalies not classified as faults could be particular needs, so a suite of tools could be an
documented in case they later turn out to be appropriate choice.
more serious than first thought. Test reports are
also inputs to the change management request 6.2. CategoriesofTools
process (see Software Configuration Control in
the Software Configuration Management KA). We categorize the available tools according to
their functionality:
5.2.7.DefectTracking
[9*, c9] Test harnesses (drivers, stubs) [1*, c3s9]
provide a controlled environment in which
Defects can be tracked and analyzed to tests can be launched and the test outputs can
determine when they were introduced into the be logged. In order to execute parts of a
software, why they were created (for example, program, drivers and stubs are provided to
poorly defined requirements, incorrect variable
simulate calling and called modules, flow graph have been exercised amongst all
respectively. those required by the selected test coverage
Testgenerators [1*, c12s11] provide assistance criterion. The analysis can be done thanks to
in the generation test cases. The generation program instrumenters that insert recording
can be random, path-based, modelbased, or a probes into the code.
mix thereof. Tracers [1*, c1s7] record the history of a
Capture/replay tools [1*, c12s11] automatically programs execution paths.
reexecute, or replay, previously executed tests Regressiontestingtools [1*, c12s16] support the
which have recorded inputs and outputs (e.g., reexecution of a test suite after a section of
screens). software has been modified. They can also
Oracle/file comparators/assertion checking help to select a test subset according to the
tools [1*, c9s7] assist in deciding whether a change made.
test outcome is successful or not. Reliabilityevaluationtools [9*, c8] support test
Coverageanalyzersandinstrumenters [1*, c4] results analysis and graphical visualization in
work together. Coverage analyzers assess order to assess reliability-related measures
which and how many entities of the program according to selected models.
Kan 2003
[9*] Nielsen[10*]
199
Sommerville 2011
[2*]
Naik and Tripathy 2008
[1*]
1. Software Testing
Fundamentals
1.1. Testing-Related Terminology
1.1.1. Definitions of Testing
and c1,c2 c8
Related Terminology
1.1.2. Faults vs. Failures c1s5 c11
1.2. Key Issues
1.2.1. Test Selection Criteria /
c1s14, c6s6,
Test Adequacy Criteria
c12s7
(Stopping Rules)
1.2.2. Testing Effectiveness / c13s11,
Objectives for Testing c11s4
1.2.3. Testing for Defect

c1s14
Identification
c1s9,
1.2.4. The Oracle Problem
c9s7
1.2.5. Theoretical and Practical
c2s7
Limitations of Testing
1.2.6. The Problem of
Infeasible c4s7
Paths
1.2.7. Testability c17s2
1.3. Relationship of Testing to
Other Activities
1.3.1. Testing vs. Static
Software Quality Management c12
Techniques
1.3.2. Testing vs. Correctness
c17s2
Proofs and Formal Verification
1.3.3. Testing vs. Debugging c3s6
1.3.4. Testing vs. Programming c3s2
2. Test Levels
2.1. The Target of the Test c1s13 c8s1
2.1.1. Unit Testing c3 c8
2.1.2. Integration Testing c7 c8
2.1.3. System Testing c8 c8
Kan 2003
[9*] Nielsen[10*]
199
Sommerville 2011
[2*]
[1*]
2.2. Objectives of Testing c1s7

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

3.3.3. Reference Models for
c4
Code-Based Testing
3.4. Fault-Based Techniques c1s14
3.4.1. Error Guessing c9s8
3.4.2. Mutation Testing c3s5
3.5. Usage-Based Techniques
3.5.1. Operational Profile c15s5
3.5.2. User Observation
c5, c7
Heuristics
3.6. Model-Based Testing
Techniques
3.6.1. Decision Table c9s6
3.6.2. Finite-State Machines c10
3.6.3. Testing from Formal
c10s11 c15
Specifications
3.7. Techniques Based on the
Nature of the Application
3.8. Selecting and Combining
Techniques
3.8.1. Functional and Structural c9
3.8.2. Deterministic vs. c9s6
Random
4. Test-Related Measures
4.1. Evaluation of the Program
Under Test
4.1.1. Program Measurements

That Aid in Planning and c11
Designing Testing
4.1.2. Fault Types,
c4
Classification, and Statistics
4.1.3. Fault Density c13s4 c4
4.1.4. Life Test, Reliability
c15 c3
Evaluation
4.1.5. Reliability Growth c15 c8
Models
Kan 2003
[9*] Nielsen[10*]
199
Sommerville 2011
[2*]
[1*]
4.2. Evaluation of the Tests

Performed
4.2.1. Coverage / Thoroughness
c11
Measures
4.2.2. Fault Seeding c2s5 c6
4.2.3. Mutation Score c3s5
4.2.4. Comparison and Relative
Effectiveness of Different
Techniques
5. Test Process
5.1. Practical Considerations
5.1.1. Attitudes / Egoless
c16 c15
Programming
5.1.2. Test Guides c12s1 c15s1
5.1.3. Test Process c12 c15
Management
5.1.4. Test Documentation and

c8s12 c4s5
Work Products
5.1.5. Test-Driven c1s16
Development
5.1.6. Internal vs. Independent
c16
Test Team
5.1.7. Cost/Effort Estimation and
c18s3 c5s7
Other Process Measures
5.1.8. Termination c10s4
5.1.9. Test Reuse and Patterns c2s5
5.2. Test Activities
c12s1
5.2.1. Planning
c12s8
c12s1
5.2.2. Test-Case Generation
c12s3
5.2.3. Test Environment
c12s6
Development
5.2.4. Execution c12s7
5.2.5. Test Results Evaluation c15
Kan 2003
[9*] Nielsen[10*]
199
Sommerville 2011
[2*]
[1*]
5.2.6. Problem Reporting /

Test c13s9
Log
5.2.7. Defect Tracking c9
6. Software Testing Tools
6.1. Testing Tool Support c12s11 c5
6.1.1. Selecting Tools c12s11
c1s7, c3s9,
c4, c9s7,
6.2. Categories of Tools c8
c12s11,
c12s16
REFERENCES [7] ISO/IEC/IEEE24765:2010Systemsand
SoftwareEngineeringVocabulary, ISO/
[1*] S. Naik and P. Tripathy, SoftwareTesting
IEC/IEEE, 2010.
andQualityAssurance:Theoryand
[8] S. Yoo and M. Harman, Regression Testing
Practice, Wiley-Spektrum, 2008.
Minimization, Selection and Prioritization: A
[2*] I. Sommerville, SoftwareEngineering, 9th Survey, SoftwareTestingVerificationand
ed., Addison-Wesley, 2011. Reliability,vol. 22, no. 2, Mar. 2012, pp. 67
120.
[3] M.R. Lyu, ed., HandbookofSoftware
ReliabilityEngineering, McGraw-Hill and [9*] S.H. Kan, MetricsandModelsinSoftware
IEEE Computer Society Press, 1996. QualityEngineering, 2nd ed.,
AddisonWesley, 2002.
[4] H. Zhu, P.A.V. Hall, and J.H.R. May,
Software Unit Test Coverage and [10*] J. Nielsen, UsabilityEngineering, Morgan
Adequacy, ACMComputingSurveys,vol. Kaufmann, 1993.
29, no. 4, Dec. 1997, pp. 366427.
[11] T.Y. Chen et al., Adaptive Random
[5] E.W. Dijkstra, Notes on Structured Testing: The ART of Test Case Diversity,
Programming, T.H.-Report 70-WSE-03, JournalofSystemsandSoftware,vol. 83,
Technological University, Eindhoven, 1970; no. 1, Jan. 2010, pp. 6066.
http://www.cs.utexas.edu/users/EWD/
[12] Y. Jia and M. Harman, An Analysis and
ewd02xx/EWD249.PDF.
Survey of the Development of Mutation
[6] ISO/IEC/IEEEP29119-1/DISDraft Testing, IEEETrans.Software
StandardforSoftwareandSystems Engineering,vol. 37, no. 5, Sep.Oct. 2011,
Engineering SoftwareTestingPart1: pp. 649678.
ConceptsandDefinitions, ISO/IEC/IEEE,
2012. [13] M. Utting and B. Legeard, PracticalModel-
BasedTesting:AToolsApproach, Morgan
Kaufmann, 2007.
CHAPTER 5 SOFTWARE MAINTENANCE
ACRONYMS V&V Verification and Validation

MR Modification Request INTRODUCTION
PR Problem Report Software development efforts result in the
Software Configuration delivery of a software product that satisfies user
SCM
Management requirements. Accordingly, the software product
SLA Service-Level Agreement must change or evolve. Once in operation,
defects are uncovered, operating environments
SQA Software Quality Assurance
change, and new user requirements surface. The
maintenance phase of the life cycle begins This first section introduces the concepts and
following a warranty period or terminology that form an underlying basis to
postimplementation support delivery, but understanding the role and scope of software
maintenance activities occur much earlier. maintenance. The topics provide definitions and
Software maintenance is an integral part of a emphasize why there is a need for maintenance.
software life cycle. However, it has not received Categories of software maintenance are critical
the same degree of attention that the other to understanding its underlying meaning.
phases have. Historically, software development
has had a much higher profile than software 1.1. DefinitionsandTerminology
maintenance in most organizations. This is now [1*, c3] [2*, c1s2, c2s2]
changing, as organizations strive to squeeze the
most out of their software development The purpose of software maintenance is defined
investment by keeping software operating as in the international standard for software
long as possible. The open source paradigm has maintenance: ISO/IEC/IEEE 14764 [1*].4 In the
brought further attention to the issue of context of software engineering, software
maintaining software artifacts developed by maintenance is essentially one of the many
others. technical processes.
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
activities 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.

SOFTWARE MAINTENANCE

Maintenance KA is shown in Figure 5.1.
1.Software Maintenance Fundamentals
4 For the purpose of conciseness and ease of

reading, this standard is referred to simply as
IEEE 14764 in the subsequent text of this KA.
5-1
Figure 5.1. Breakdown of Topics for the Software Maintenance KA

The objective of software maintenance is to proposed changes is determined, code and other
modify existing software while preserving its software artifacts are modified, testing is
integrity. The international standard also states conducted, and a new version of the software
the importance of having some maintenance product is released. Also, training and daily
activities prior to the final delivery of software support are provided to users. The term
(predelivery activities). Notably, IEEE 14764 maintainer is defined as an organization that
emphasizes the importance of the predelivery performs maintenance activities. In this KA, the
aspects of maintenanceplanning, for example. term will sometimes refer to individuals who
perform those activities, contrasting them with
1.2. NatureofMaintenance the developers.
[2*, c1s3] IEEE 14764 identifies the primary activities
of software maintenance as process
Software maintenance sustains the software implementation, problem and modification
product throughout its life cycle (from analysis, modification implementation,
development to operations). Modification maintenance review/acceptance, migration, and
requests are logged and tracked, the impact of
retirement. These activities are discussed in preventing software performance

section 3.2, Maintenance Activities. from degrading to unacceptable levels.
Maintainers can learn from the developers
knowledge of the software. Contact with the 1.4. MajorityofMaintenanceCosts
developers and early involvement by the [2*, c4s3, c5s5.2]
maintainer helps reduce the overall maintenance
effort. In some instances, the initial developer Maintenance consumes a major share of the
cannot be reached or has moved on to other financial resources in a software life cycle. A
tasks, which creates an additional challenge for common perception of software maintenance is
maintainers. Maintenance must take software that it merely fixes faults. However, studies and
artifacts from development (for example, code surveys over the years have indicated that the
or documentation) and support them majority, over 80 percent, of software
immediately, then progressively evolve/maintain maintenance is used for noncorrective actions
them over a software life cycle. [2*, figure 4.1]. Grouping enhancements and
corrections together in management reports
1.3. NeedforMaintenance contributes to some misconceptions regarding
[2*, c1s5] the high cost of corrections. Understanding the
categories of software maintenance helps to
Maintenance is needed to ensure that the understand the structure of software
software continues to satisfy user requirements. maintenance costs. Also, understanding the
Maintenance is applicable to software that is factors that influence the maintainability of
developed using any software life cycle model software can help to contain costs. Some
(for example, spiral or linear). Software environmental factors and their relationship to
products change due to corrective and software maintenance costs include the
noncorrective software actions. following:
Maintenance must be performed in order to
Operating environment refers to hardware
correct faults; and software.
improve the design; Organizational environment refers to
implement enhancements; policies, competition, process, product, and
interface with other software; personnel.
adapt programs so that different hardware,
software, system features, and 1.5. EvolutionofSoftware
telecommunications facilities can be used; [2*, c3s5]
migrate legacy software; and
retire software. Software maintenance in terms of evolution was
first addressed in the late 1960s. Over a period
Five key characteristics comprise the of twenty years, research led to the formulation
maintainers activities: of eight Laws of Evolution. Key findings
include a proposal that maintenance is
maintaining control over the softwares evolutionary development and that maintenance
dayto-day functions; decisions are aided by understanding what
maintaining control over software happens to software over time. Some state that
modification; maintenance is continued development, except
perfecting existing functions; that there is an extra input (or constraint)in
identifying security threats and fixing other words, existing large software is never
security vulnerabilities; and complete and continues to evolve; as it evolves,
it grows more complex unless some action is Reactive Corrective Adaptive

taken to reduce this complexity. 2. Key Issues in Software Maintenance
1.6. CategoriesofMaintenance A number of key issues must be dealt with to
[1*, c3, c6s2] [2*, c3s3.1] ensure the effective maintenance of software.
Software maintenance provides unique technical
Three categories (types) of maintenance have
and management challenges for software
been defined: corrective, adaptive, and
engineersfor example, trying to find a fault in
perfective [2*, c4s3]. IEEE 14764 includes a
software containing a large number of lines of
fourth categorypreventative.
code that another software engineer developed.
Corrective maintenance: reactive Similarly, competing with software developers
modification (or repairs) of a software for resources is a constant battle. Planning for a
product performed after delivery to correct future release, which often includes coding the
discovered problems. Included in this next release while sending out emergency
category is emergency maintenance, which patches for the current release, also creates a
is an unscheduled modification performed challenge. The following section presents some
to temporarily keep a software product of the technical and management issues related
operational pending corrective maintenance. to software maintenance. They have been
grouped under the following topic headings:
Adaptive maintenance: modification of a
software product performed after delivery to
technical issues,
keep a software product usable in a changed
management issues, cost estimation, and
or changing environment. For example, the
measurement.
operating system might be upgraded and
some changes to the software may be
2.1. TechnicalIssues
necessary.
Perfective maintenance: modification of a 2.1.1. LimitedUnderstanding
software product after delivery to provide [2*, c6]
enhancements for users, improvement of
program documentation, and recoding to Limited understanding refers to how quickly a
improve software performance, software engineer can understand where to
maintainability, or other software attributes. make a change or correction in software that he
Preventive maintenance: modification of a or she did not develop. Research indicates that
software product after delivery to detect and about half of the total maintenance effort is
correct latent faults in the software product devoted to understanding the software to be
before they become operational faults. modified. Thus, the topic of software
comprehension is of great interest to software
IEEE 14764 classifies adaptive and perfective engineers. Comprehension is more difficult in
maintenance as maintenance enhancements. It text-oriented representationin source code,
also groups together the corrective and for examplewhere it is often difficult to trace
preventive maintenance categories into a the evolution of software through its releases/
correction category, as shown in Table 5.1. versions if changes are not documented and if
Table 5.1. Software Maintenance the developers are not available to explain it,
Categories which is often the case. Thus, software
engineers may initially have a limited
Correction Enhancement
understanding of the software; much has to be
Proactive Preventive Perfective done to remedy this.
2.1.2. Testing replicate or verify the problem;

[1*, c6s2.2.2] [2*, c9] develop options for implementing the
modification;
The cost of repeating full testing on a major document the MR/PR, the results, and the
piece of software is significant in terms of time execution options;
and money. In order to ensure that the requested obtain approval for the selected
problem reports are valid, the maintainer should modification option.
replicate or verify problems by running the
appropriate tests. Regression testing (the The severity of a problem is often used to
selective retesting of software or a component decide how and when it will be fixed. The
to verify that the modifications have not caused software engineer then identifies the affected
unintended effects) is an important testing components. Several potential solutions are
concept in maintenance. Additionally, finding provided, followed by a recommendation as to
time to test is often difficult. Coordinating tests the best course of action.
when different members of the maintenance Software designed with maintainability in
team are working on different problems at the mind greatly facilitates impact analysis. More
same time remains a challenge. When software information can be found in the Software
performs critical functions, it may be difficult to Configuration Management KA.
bring it offline to test. Tests cannot be executed 2.1.4. Maintainability
in the most meaningful placethe production [1*, c6s8] [2*, c12s5.5]
system. The Software Testing KA provides
additional information and references on this IEEE 14764 [1*, c3s4] defines maintainability
matter in its subtopic on regression testing. as the capability of the software product to be
modified. Modifications may include
2.1.3. ImpactAnalysis corrections, improvements, or adaptation of the
[1*, c5s2.5] [2*, c13s3] software to changes in environment as well as
changes in requirements and functional
Impact analysis describes how to conduct, specifications.
costeffectively, a complete analysis of the As a primary software quality characteristic,
impact of a change in existing software. maintainability should be specified, reviewed,
Maintainers must possess an intimate and controlled during software development
knowledge of the softwares structure and activities in order to reduce maintenance costs.
content. They use that knowledge to perform When done successfully, the softwares
impact analysis, which identifies all systems maintainability will improve. Maintainability is
and software products affected by a software often difficult to achieve because the
change request and develops an estimate of the subcharacteristics are often not an important
resources needed to accomplish the change. focus during the process of software
Additionally, the risk of making the change is development. The developers are, typically,
determined. The change request, sometimes more preoccupied with many other activities
called a modification request (MR) and often and frequently prone to disregard the
called a problem report (PR), must first be maintainers requirements. This in turn can, and
analyzed and translated into software terms. often does, result in a lack of software
Impact analysis is performed after a change documentation and test environments, which is
request enters the software configuration a leading cause of difficulties in program
management process. IEEE 14764 states the comprehension and subsequent impact analysis.
impact analysis tasks: The presence of systematic and mature
processes, techniques, and tools helps to
analyze MRs/PRs; enhance the maintainability of software.
2.2. ManagementIssues The software life cycle process is a set of

activities, methods, practices, and
2.2.1. Alignmentwith transformations that people use to develop and
OrganizationalObjectives maintain software and its associated products.
[2*, c4] At the process level, software maintenance
activities share much in common with software
Organizational objectives describe how to development (for example, software
demonstrate the return on investment of configuration management is a crucial activity
software maintenance activities. Initial software in both). Maintenance also requires several
development is usually project-based, with a activities that are not found in software
defined time scale and budget. The main development (see section 3.2 on unique
emphasis is to deliver a product that meets user activities for details). These activities present
needs on time and within budget. In contrast, challenges to management.
software maintenance often has the objective of
extending the life of software for as long as 2.2.4. OrganizationalAspectsof
possible. In addition, it may be driven by the Maintenance
need to meet user demand for software updates [1*, c7s2.3] [2*, c10]
and enhancements. In both cases, the return on
investment is much less clear, so that the view at Organizational aspects describe how to identify
the senior management level is often that of a which organization and/or function will be
major activity consuming significant resources responsible for the maintenance of software.
with no clear quantifiable benefit for the The team that develops the software is not
organization. necessarily assigned to maintain the software
2.2.2. Staffing once it is operational.
[2*, c4s5, c10s4] In deciding where the software maintenance
function will be located, software engineering
Staffing refers to how to attract and keep
organizations may, for example, stay with the
software maintenance staff. Maintenance is not
original developer or go to a permanent
often viewed as glamorous work. As a result,
maintenance-specific team (or maintainer).
software maintenance personnel are frequently
Having a permanent maintenance team has
viewed as second-class citizens, and morale
many benefits:
therefore suffers.
allows for specialization;
2.2.3. Process
creates communication channels;
[1*, c5] [2*, c5]
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-
bycase basis. What is important is the delegation
or assignment of the maintenance responsibility
to a single group or person, regardless of the
organizations structure.
2.2.5. Outsourcing
[3*]
Outsourcing and offshoring software Parametric cost modeling (mathematical

maintenance has become a major industry. models) has been applied to software
Organizations are outsourcing entire portfolios maintenance. Of significance is that historical
of software, including software maintenance. data from past maintenance are needed in order
More often, the outsourcing option is selected to use and calibrate the mathematical models.
for less mission-critical software, as Cost driver attributes affect the estimates.
organizations are unwilling to lose control of the
software used in their core business. One of the 2.3.3. Experience
major challenges for outsourcers is to determine [2*, c12s5.5]
the scope of the maintenance services required,
the terms of a service-level agreement, and the Experience, in the form of expert judgment, is
contractual details. Outsourcers will need to often used to estimate maintenance effort.
invest in a maintenance infrastructure, and the Clearly, the best approach to maintenance
help desk at the remote site should be staffed estimation is to combine historical data and
with native-language speakers. Outsourcing experience. The cost to conduct a modification
requires a significant initial investment and the (in terms of number of people and amount of
setup of a maintenance process that will require time) is then derived. Maintenance estimation
automation. historical data should be provided as a result of
a measurement program.
2.3. MaintenanceCostEstimation
2.4. SoftwareMaintenanceMeasurement
Software engineers must understand the [1*, c6s5] [2*, c12]
different categories of software maintenance,
discussed above, in order to address the Entities related to software maintenance, whose
question of estimating the cost of software attributes can be subjected to measurement,
maintenance. For planning purposes, cost include process, resource, and product [2*,
estimation is an important aspect of planning for c12s3.1].
software maintenance. There are several software measures that can
be derived from the attributes of the software,
2.3.1. CostEstimation the maintenance process, and personnel,
[2*, c7s2.4] including size, complexity, quality,
understandability, maintainability, and effort.
Section 2.1.3 describes how impact analysis Complexity measures of software can also be
identifies all systems and software products obtained using available commercial tools.
affected by a software change request and These measures constitute a good starting point
develops an estimate of the resources needed to for the maintainers measurement program.
accomplish that change. Discussion of software process and product
Maintenance cost estimates are affected by measurement is also presented in the Software
many technical and nontechnical factors. IEEE Engineering Process KA. The topic of a
14764 states that the two most popular software measurement program is described in
approaches to estimating resources for software the Software Engineering Management KA.
maintenance are the use of parametric models
and the use of experience [1*, c7s4.1]. A 2.4.1. SpecificMeasures
combination of these two can also be used. [2*, c12]
2.3.2. ParametricModels
[2*, c12s5.6] The maintainer must determine which measures
are appropriate for a specific organization based
on that organizations own context. The
software quality model suggests measures that process implementation,

are specific for software maintenance. Measures problem and modification analysis,
for subcharacteristics of maintainability include modification implementation,
the following [4*, p. 60]: maintenance review/acceptance,
migration, and software retirement.
Analyzability: measures of the maintainers
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 maintainers
effort associated with implementing a
specified modification.
Stability: measures of the unexpected
behavior of software, including that
encountered during testing.
Testability: measures of the maintainers
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 Figure 5.2. Software Maintenance Process

categories, for different applications provides
business information to users and their Other maintenance process models include:
organizations. It can also enable the comparison
of software maintenance profiles internally quick fix,
within an organization. spiral,
Osbornes, iterative enhancement, and
3.Maintenance Process reuse-oriented.
In addition to standard software engineering Recently, agile methodologies, which promote

processes and activities described in IEEE light processes, have been also adapted to
14764, there are a number of activities that are maintenance. This requirement emerges from
unique to maintainers. the everincreasing demand for fast turnaround
of maintenance services. Improvement to the
3.1. MaintenanceProcesses software maintenance process is supported by
[1*, c5] [2*, c5] [5, s5.5] specialized software maintenance capability
maturity models (see [6] and [7], which are
Maintenance processes provide needed activities briefly annotated in the Further Readings
and detailed inputs/outputs to those activities as section).
described in IEEE 14764. The maintenance
process activities of IEEE 14764 are shown in 3.2. MaintenanceActivities
Figure [1*, c5, c6s8.2, c7s3.3]
5.2. Software maintenance activities include
The maintenance process contains the activities 3.2.2. SupportingActivities

and tasks necessary to modify an existing [1*, c4s1, c5, c6s7] [2*, c9]
software product while preserving its integrity.
These activities and tasks are the responsibility Maintainers may also perform support activities,
of the maintainer. As already noted, many such as documentation, software configuration
maintenance activities are similar to those of management, verification and validation,
software development. Maintainers perform problem resolution, software quality assurance,
analysis, design, coding, testing, and reviews, and audits. Another important support
documentation. They must track requirements in activity consists of training the maintainers and
their activitiesjust as is done in development users.
and update documentation as baselines
change. IEEE 14764 recommends that when a 3.2.3. MaintenancePlanning
maintainer uses a development process, it must Activities
be tailored to meet specific needs [1*, c5s3.2.2]. [1*, c7s3]
However, for software maintenance, some
activities involve processes unique to software An important activity for software maintenance
maintenance. is planning, and maintainers must address the
issues associated with a number of planning
3.2.1. UniqueActivities perspectives, including
[1*, c3s10, c6s9, c7s2, c7s3] [2*, c6, c7]
business planning (organizational level),
There are a number of processes, activities, and maintenance planning (transition level),
practices that are unique to software release/version planning (software level),
maintenance: and individual software change request
planning (request level).
Program understanding: activities needed to
obtain a general knowledge of what a At the individual request level, planning is
software product does and how the parts carried out during the impact analysis (see
work together. section 2.1.3, Impact Analysis). The
Transition: a controlled and coordinated release/version planning activity requires that
sequence of activities during which the maintainer:
software is transferred progressively from
the developer to the maintainer. collect the dates of availability of individual
Modification request acceptance/rejection: requests,
modifications requesting work beyond a agree with users on the content of
certain size/effort/complexity may be subsequent releases/versions,
rejected by maintainers and rerouted to a identify potential conflicts and develop
developer. alternatives,
Maintenance help desk: an end-user and assess the risk of a given release and
maintenance coordinated support function develop a back-out plan in case problems
that triggers the assessment, prioritization, should arise, and
and costing of modification requests. inform all the stakeholders.
Impact analysis: a technique to identify
areas impacted by a potential change; Whereas software development projects can
Maintenance Service-Level Agreements typically last from some months to a few years,
(SLAs) and maintenance licenses and the maintenance phase usually lasts for many
contracts: contractual agreements that years. Making estimates of resources is a key
describe the services and quality objectives. element of maintenance planning. Software
maintenance planning should begin with the Management KA provides details of SCM and
decision to develop a new software product and discusses the process by which software change
should consider quality objectives. A concept requests are submitted, evaluated, and approved.
document should be developed, followed by a SCM for software maintenance is different from
maintenance plan. The maintenance concept for SCM for software development in the number of
each software product needs to be documented small changes that must be controlled on
in the plan [1*, c7s2] and should address the operational software. The SCM process is
implemented by developing and following a
scope of the software maintenance, software configuration management plan and
adaptation of the software maintenance operating procedures. Maintainers participate in
process, Configuration Control Boards to determine the
identification of the software maintenance content of the next release/version.
organization, and 3.2.5. SoftwareQuality
estimate of software maintenance costs. [1*, c6s5, c6s7, c6s8] [2*, c12s5.3]
The next step is to develop a corresponding It is not sufficient to simply hope that increased
software maintenance plan. This plan should be quality will result from the maintenance of
prepared during software development and software. Maintainers should have a software
should specify how users will request software quality program. It must be planned and
modifications or report problems. Software processes must be implemented to support the
maintenance planning is addressed in IEEE maintenance process. The activities and
14764. It provides guidelines for a maintenance techniques for Software Quality Assurance
plan. Finally, at the highest level, the (SQA), V&V, reviews, and audits must be
maintenance organization will have to conduct selected in concert with all the other processes
business planning activities (budgetary, to achieve the desired level of quality. It is also
financial, and human resources) just like all the recommended that the maintainer adapt the
other divisions of the organization. Management software development processes, techniques and
is discussed in the chapter Related Disciplines deliverables (for instance, testing
of Software Engineering. documentation), and test results. More details
can be found in the Software Quality KA.
3.2.4. SoftwareConfiguration
Management 4.Techniques for Maintenance
[1*, c5s1.2.3] [2*, c11]
This topic introduces some of the generally
IEEE 14764 describes software configuration accepted techniques used in software
management as a critical element of the maintenance.
maintenance process. Software configuration
management procedures should provide for the 4.1. ProgramComprehension
verification, validation, and audit of each step [2*, c6, c14s5]
required to identify, authorize, implement, and
release the software product. Programmers spend considerable time reading
It is not sufficient to simply track and understanding programs in order to
modification requests or problem reports. The implement changes. Code browsers are key
software product and any changes made to it tools for program comprehension and are used
must be controlled. This control is established to organize and present source code. Clear and
by implementing and enforcing an approved concise documentation can also aid in program
software configuration management (SCM) comprehension.
process. The Software Configuration
4.2. Reengineering During softwares life, it may have to be

[2*, c7] modified to run in different environments. In
order to migrate it to a new environment, the
Reengineering is defined as the examination and maintainer needs to determine the actions
alteration of software to reconstitute it in a new needed to accomplish the migration, and then
form, and includes the subsequent develop and document the steps required to
implementation of the new form. It is often not effect the migration in a migration plan that
undertaken to improve maintainability but to covers migration requirements, migration tools,
replace aging legacy software. Refactoring is a conversion of product and data, execution,
reengineering technique that aims at verification, and support. Migrating software
reorganizing a program without changing its can also entail a number of additional activities
behavior. It seeks to improve a program such as
structure and its maintainability. Refactoring
techniques can be used during minor changes. notification of intent: a statement of why the
4.3. ReverseEngineering old environment is no longer to be
[1*, c6s2] [2*, c7, c14s5] supported, followed by a description of the
new environment and its date of
Reverse engineering is the process of analyzing availability;
software to identify the softwares components parallel operations: make available the old
and their inter-relationships and to create and new environments so that the user
representations of the software in another form experiences a smooth transition to the new
or at higher levels of abstraction. Reverse environment;
engineering is passive; it does not change the notification of completion: when the
software or result in new software. Reverse scheduled migration is completed, a
engineering efforts produce call graphs and notification is sent to all concerned;
control flow graphs from source code. One type postoperation review: an assessment of
of reverse engineering is redocumentation. parallel operation and the impact of
Another type is design recovery. Finally, data changing to the new environment;
reverse engineering, where logical schemas are data archival: storing the old software data.
recovered from physical databases, has grown
in importance over the last few years. Tools are 4.5. Retirement
key for reverse engineering and related tasks [1*, c5s6]
such as redocumentation and design recovery.
Once software has reached the end of its useful
4.4. Migration life, it must be retired. An analysis should be
[1*, c5s5] performed to assist in making the retirement
decision. This analysis should be included in the
retirement plan, which covers retirement
requirements, 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 cross-referencers, which generate indices of
particularly important in software maintenance program components; and
where existing software is being modified. dependency analyzers, which help
Examples regarding program comprehension maintainers analyze and understand the
include interrelationships between components of a
program slicers, which select only parts of a program.
program affected by a change;
static analyzers, which allow general Reverse engineering tools assist the process
viewing and summaries of a program by working backwards from an existing product
content; to create artifacts such as specification and
dynamic analyzers, which allow the design descriptions, which can then be
maintainer to trace the execution path of a transformed to generate a new product from an
program; old one. Maintainers also use software test,
data flow analyzers, which allow the software configuration management, software
maintainer to track all possible data flows of documentation, and software measurement
a program; tools.
Sneed [3*]
2008
Grubb 2006
IEEE/ISO/IEC 14764 and Takang 2003
[2*]
[1*]
1. Software Maintenance
Fundamentals
1.1. Definitions and Terminology c3 c1s2, c2s2
1.2. Nature of Maintenance c1s3
1.3. Need for Maintenance c1s5
1.4. Majority of Maintenance Costs c4s3, c5s5.2
1.5. Evolution of Software c3s5
1.6. Categories of Maintenance c3, c6s2 c3s3.1, c4s3
2. Key Issues in Software

Maintenance
2.1. Technical Issues
2.1.1. Limited Understanding c6
2.1.2. Testing c6s2.2.2 c9
2.1.3. Impact Analysis c5s2.5 c13s3
2.1.4. Maintainability c6s8, c3s4 c12s5.5
2.2. Management Issues
2.2.1. Alignment with
c4
Organizational objectives
2.2.2. Staffing c4s5, c10s4
2.2.3. Process c5 c5
2.2.4. Organizational Aspects of
c7s.2.3 c10
Maintenance
2.2.5. Outsourcing/Offshoring all
2.3. Maintenance Cost Estimation
2.3.1. Cost Estimation c7s4.1 c7s2.4
Sneed [3*]
2008
Grubb 2006
IEEE/ISO/IEC 14764 and Takang 2003
[2*]
[1*]
2.3.2. Parametric Models c12s5.6

2.3.3. Experience c12s5.5
2.4. Software Maintenance
c6s5 c12, c12s3.1
Measurement
2.4.1. Specific Measures c12

3. Maintenance Process
3.1. Maintenance Processes c5 c5
c5, c5s3.2.2,
3.2. Maintenance Activities
c6s8.2, c7s3.3
c3s10, c6s9, c7s2,
3.2.1. Unique Activities c6,c7
c7s3
3.2.2. Supporting Activities c4s1, c5, c6s7 c9
3.2.3. Maintenance Planning
c7s2, c7s.3
Activities
3.2.4. Software Configuration
c5s1.2.3 c11
Management
3.2.5. Software Quality c6s5, c6s7, c6s8 c12s5.3
4. Techniques for Maintenance
4.1. Program Comprehension c6,c14s5
4.2. Reengineering c7
4.3. Reverse Engineering c6s2 c7, c14s5
4.4. Migration c5s5
4.5. Retirement c5s6
5. Software Maintenance Tools c6s4 c14
FURTHER READINGS M. Kajko-Mattsson, Towards a Business
Maintenance Model, IEEE Intl Conf.
A. April and A. Abran, SoftwareMaintenance Software Maintenance [7].
Management:EvaluationandContinuous
Improvement [6]. This paper presents an overview of the
Corrective Maintenance Maturity Model
This book explores the domain of small (CM3). In contrast to other process models,
software maintenance processes (S3M). It CM3 is a specialized model, entirely dedicated
provides roadmaps for improving software to corrective maintenance of software. It views
maintenance processes in organizations. It maintenance in terms of the activities to be
describes a software maintenance specific performed and their order, in terms of the
maturity model organized by levels which allow information used by these activities, goals, rules
for benchmarking and continuous improvement. and motivations for their execution, and
Goals for each key practice area are provided, organizational levels and roles involved at
and the process model presented is fully aligned various stages of a typical corrective
with the architecture and framework of maintenance process.
international standards ISO12207, ISO14764 REFERENCES
and ISO15504 and popular maturity models like
ITIL, CoBIT, CMMI and CM3. [1*] IEEEStd.14764-2006(a.k.a.ISO/IEC
14764:2006)StandardforSoftware
EngineeringSoftwareLifeCycle [5] ISO/IEC/IEEE24765:2010Systemsand

ProcessesMaintenance, IEEE, 2006. SoftwareEngineeringVocabulary, ISO/
IEC/IEEE, 2010.
[2*] P. Grubb and A.A. Takang, Software
Maintenance:ConceptsandPractice, 2nd [6] A. April and A. Abran, Software
ed., World Scientific Publishing, 2003. MaintenanceManagement:Evaluationand
ContinuousImprovement, Wiley-IEEE
[3*] H.M. Sneed, Offering Software Computer Society Press, 2008.
Maintenance as an Offshore Service, Proc.
IEEEIntlConf.SoftwareMaintenance [7] M. Kajko-Mattsson, Towards a Business
(ICSM 08), IEEE, 2008, pp. 15. Maintenance Model, Proc.IntlConf.
SoftwareMaintenance, IEEE, 2001, pp.
[4*] J.W. Moore, TheRoadMaptoSoftware 500509.
Engineering:AStandards-BasedGuide,
Wiley-IEEE Computer Society Press, 2006.
CHAPTER 6
SOFTWARE CONFIGURATION MANAGEMENT

ACRONYMS Specification
CCB Configuration Control Board
INTRODUCTION
CM Configuration Management
FCA Functional Configuration Audit A system can be defined as the combination of
interacting elements organized to achieve one or
PCA Physical Configuration Audit
more stated purposes [1]. The configuration of a
Software Configuration Control system is the functional and physical
SCCB characteristics of hardware or software as set
Board
forth in technical documentation or achieved in
SCI Software Configuration Item
a product [1]; it can also be thought of as a
Software Configuration collection of specific versions of hardware,
SCM
Management firmware, or software items combined
Software Configuration according to specific build procedures to serve a
SCMP particular purpose. Configuration management
Management Plan
(CM), then, is the discipline of identifying the
SCR Software Change Request
configuration of a system at distinct points in
Software Configuration Status time for the purpose of systematically
SCSA
Accounting controlling changes to the configuration and
SDD Software Design Document maintaining the integrity and traceability of the
Software Engineering Institutes configuration throughout the system life cycle.
SEI/ It is formally defined as
Capability Maturity Model
CMMI
Integration
A discipline applying technical and
SQA Software Quality Assurance administrative direction and surveillance
SRS Software Requirement to: identify and document the functional
and physical characteristics of a there are some differences in implementation

configuration item, control changes to between hardware CM and software CM.
those characteristics, record and report SCM is closely related to the software quality
change processing and implementation assurance (SQA) activity. As defined in the
status, and verify compliance with Software Quality knowledge area (KA), SQA
specified requirements. [1] processes provide assurance that the software
products and processes in the project life cycle
Software configuration management (SCM) is conform to their specified requirements by
a supporting-software life cycle process that planning, enacting, and performing a set of
benefits project management, development and activities to provide adequate confidence that
maintenance activities, quality assurance quality is being built into the software. SCM
activities, as well as the customers and users of activities help in accomplishing these SQA
the end product. goals. In some project contexts, specific SQA
The concepts of configuration management requirements prescribe certain SCM activities.
apply to all items to be controlled, although
6-1
Figure 6.1. Breakdown of Topics for the Software Configuration Management KA

The SCM activities are management and produced and used throughout the software
planning of the SCM process, software engineering process.
configuration identification, software
configuration control, software configuration BREAKDOWN OF TOPICS FOR
status accounting, software configuration SOFTWARE CONFIGURATION
auditing, and software release management and MANAGEMENT
delivery.
The Software Configuration Management KA The breakdown of topics for the Software
is related to all the other KAs, since the object
Configuration Management KA is shown in
of configuration management is the artifact
Figure 6.1. 1. Management of the SCM assurance program. Managing nonconforming

items is usually the responsibility of the quality
Process
assurance activity; however, SCM might assist
SCM controls the evolution and integrity of a with tracking and reporting on software
product by identifying its elements; managing configuration items falling into this category.
and controlling change; and verifying, Perhaps the closest relationship is with the
recording, and reporting on configuration software development and maintenance
information. From the software engineers organizations. It is within this context that many
perspective, SCM facilitates development and of the software configuration control tasks are
change implementation activities. A successful conducted. Frequently, the same tools support
SCM implementation requires careful planning development, maintenance, and SCM purposes.
and management. This, in turn, requires an
understanding of the organizational context for, 1.2. ConstraintsandGuidancefortheSCM
and the constraints placed on, the design and Process
implementation of the SCM process. [2*, c6, ann. D, ann. E] [3*, c2, c5]
[5*, c19s2.2]
1.1. OrganizationalContextforSCM
[2*, c6, ann. D] [3*, introduction] [4*, c29] Constraints affecting, and guidance for, the
SCM process come from a number of sources.
To plan an SCM process for a project, it is Policies and procedures set forth at corporate or
necessary to understand the organizational other organizational levels might influence or
context and the relationships among prescribe the design and implementation of the
organizational elements. SCM interacts with SCM process for a given project. In addition,
several other activities or organizational the contract between the acquirer and the
elements. supplier might contain provisions affecting the
The organizational elements responsible for SCM process. For example, certain
the software engineering supporting processes configuration audits might be required, or it
may be structured in various ways. Although the might be specified that certain items be placed
responsibility for performing certain SCM tasks under CM. When software products to be
might be assigned to other parts of the developed have the potential to affect public
organization (such as the development safety, external regulatory bodies may impose
organization), the overall responsibility for constraints. Finally, the particular software life
SCM often rests with a distinct organizational cycle process chosen for a software project and
element or designated individual. the level of formalism selected to implement the
Software is frequently developed as part of a software affect the design and implementation
larger system containing hardware and firmware of the SCM process.
elements. In this case, SCM activities take place Guidance for designing and implementing an
in parallel with hardware and firmware CM SCM process can also be obtained from best
activities and must be consistent with system- practice, as reflected in the standards on
level CM. Note that firmware contains hardware software engineering issued by the various
and software; therefore, both hardware and standards organizations (see Appendix B on
software CM concepts are applicable. standards).
SCM might interface with an organizations
quality assurance activity on issues such as 1.3. PlanningforSCM
records management and nonconforming items. [2*, c6, ann. D, ann. E] [3*, c23] [4*, c29]
Regarding the former, some items under SCM
The planning of an SCM process for a given
control might also be project records subject to
project should be consistent with the
provisions of the organizations quality
organizational context, applicable constraints, or by organizational element. The overall

commonly accepted guidance, and the nature of authority and reporting channels for SCM
the project (for example, size, safety criticality, should also be identified, although this might be
and security). The major activities covered are accomplished at the project management or
software configuration identification, software quality assurance planning stage.
configuration control, software configuration
status accounting, software configuration 1.3.2. SCMResourcesandSchedules
auditing, and software release management and [2*, ann. Ds8] [3*, c23]
delivery. In addition, issues such as organization
and responsibilities, resources and schedules, Planning for SCM identifies the staff and tools
tool selection and implementation, vendor and involved in carrying out SCM activities and
subcontractor control, and interface control are tasks. It addresses scheduling questions by
typically considered. The results of the planning establishing necessary sequences of SCM tasks
activity are recorded in an SCM Plan (SCMP), and identifying their relationships to the project
which is typically subject to SQA review and schedules and milestones established at the
audit. project management planning stage. Any
training requirements necessary for
Branching and merging strategies should be
implementing the plans and training new staff
carefully planned and communicated, since they
members are also specified.
impact many SCM activities. From an SCM
standpoint, a branch is defined as a set of
1.3.3. ToolSelectionandImplementation
evolving source file versions [1]. Merging
[3*, c26s2, c26s6] [4*, c29s5]
consists in combining different changes to the
same file [1]. This typically occurs when more
As for any area of software engineering, the
than one person changes a configuration item.
selection and implementation of SCM tools
There are many branching and merging
should be carefully planned. The following
strategies in common use (see the Further
questions should be considered:
Readings section for additional discussion).
The software development life cycle model
Organization: what motivates tool
(see Software Life Cycle Models in the
acquisition from an organizational
Software Engineering Process KA) also impacts
perspective?
SCM activities, and SCM planning should take
Tools: can we use commercial tools or
this into account. For instance, continuous
develop them ourselves?
integration is a common practice in many
Environment: what are the constraints
software development approaches. It is typically
imposed by the organization and its
characterized by frequent build-test-deploy
technical context?
cycles. SCM activities must be planned
Legacy: how will projects use (or not) the
accordingly.
new tools?
1.3.1. SCMOrganizationandResponsibilities Financing: who will pay for the tools
[2*, ann. Ds5, ann. Ds6] [3*, c10-11] acquisition, maintenance, training, and
[4*, introduction, c29] customization?
Scope: how will the new tools be deployed
To prevent confusion about who will perform for instance, through the entire
given SCM activities or tasks, organizational organization or only on specific projects?
roles to be involved in the SCM process need to Ownership: who is responsible for the
be clearly identified. Specific responsibilities introduction of new tools?
for given SCM activities or tasks also need to be Future: what is the plan for the tools use in
assigned to organizational entities, either by title the future?
Change: how adaptable are the tools?
Branching and merging: are the tools When a software item will interface with
capabilities compatible with the planned another software or hardware item, a change to
branching and merging strategies? either item can affect the other. Planning for the
Integration: do the various SCM tools SCM process considers how the interfacing
integrate among themselves? With other items will be identified and how changes to the
tools in use in the organization? items will be managed and communicated. The
Migration: can the repository maintained by SCM role may be part of a larger, system-level
the version control tool be ported to another process for interface specification and control; it
version control tool while maintaining may involve interface specifications, interface
complete history of the configuration items control plans, and interface control documents.
it contains? In this case, SCM planning for interface control
takes place within the context of the systemlevel
SCM typically requires a set of tools, as process.
opposed to a single tool. Such tool sets are
sometimes referred to as workbenches. In such a 1.4. SCMPlan
context, another important consideration in [2*, ann. D] [3*, c23] [4*, c29s1]
planning for tool selection is determining if the
SCM workbench will be open (in other words, The results of SCM planning for a given project
tools from different suppliers will be used in are recorded in a software configuration
different activities of the SCM process) or management plan (SCMP), a living document
integrated (where elements of the workbench which serves as a reference for the SCM
are designed to work together). process. It is maintained (that is, updated and
The size of the organization and the type of approved) as necessary during the software life
projects involved may also impact tool selection cycle. In implementing the SCMP, it is typically
(see topic 7, Software Configuration necessary to develop a number of more detailed,
Management Tools). subordinate procedures defining how specific
requirements will be carried out during day-to-
1.3.4. Vendor/SubcontractorControl day activities for example, which branching
[2*, c13] [3*, c13s9, c14s2] strategies will be used and how frequently
builds occur and automated tests of all kinds are
A software project might acquire or make use of run.
purchased software products, such as compilers Guidance on the creation and maintenance of
or other tools. SCM planning considers if and an SCMP, based on the information produced by
how these items will be taken under the planning activity, is available from a number
configuration control (for example, integrated of sources, such as [2*]. This reference provides
into the project libraries) and how changes or requirements for the information to be contained
updates will be evaluated and managed. in an SCMP; it also defines and describes six
categories of SCM information to be included in
Similar considerations apply to subcontracted
an SCMP:
software. When using subcontracted software,
both the SCM requirements to be imposed on
Introduction (purpose, scope, terms used)
the subcontractors SCM process as part of the
SCM Management (organization,
subcontract and the means for monitoring
responsibilities, authorities, applicable
compliance need to be established. The latter
policies, directives, and procedures)
includes consideration of what SCM
SCM Activities (configuration
information must be available for effective
identification, configuration control, and so
compliance monitoring.
on)
1.3.5. InterfaceControl
SCM Schedules (coordination with other
[2*, c12] [3*, c24s4]
project activities)
SCM Resources (tools, physical resources, engineer to adapt procedures. Other tools
and human resources) enforce process, leaving the software engineer
SCMP Maintenance. with less flexibility. Surveillance requirements
and the level of flexibility to be provided to the
1.5. SurveillanceofSoftwareConfiguration software engineer are important considerations
Management in tool selection.
[3*, c11s3]
1.5.1. SCMMeasuresandMeasurement
After the SCM process has been implemented, [3*, c9s2, c25s2s3]
some degree of surveillance may be necessary
to ensure that the provisions of the SCMP are SCM measures can be designed to provide
properly carried out. There are likely to be specific information on the evolving product or
specific SQA requirements for ensuring to provide insight into the functioning of the
compliance with specified SCM processes and SCM process. A related goal of monitoring the
procedures. The person responsible for SCM SCM process is to discover opportunities for
ensures that those with the assigned process improvement. Measurements of SCM
responsibility perform the defined SCM tasks processes provide a good means for monitoring
correctly. The software quality assurance the effectiveness of SCM activities on an
authority, as part of a compliance auditing ongoing basis. These measurements are useful
activity, might also perform this surveillance. in characterizing the current state of the process
The use of integrated SCM tools with process as well as in providing a basis for making
control capability can make the surveillance task comparisons over time. Analysis of the
easier. Some tools facilitate process compliance measurements may produce
while providing flexibility for the software
Software Configuration Management 6-7
insights leading to process changes and One of the first steps in controlling change is
corresponding updates to the SCMP. identifying the software items to be controlled.
Software libraries and the various SCM tool This involves understanding the software config
capabilities provide sources for extracting uration within the context of the system configu
information about the characteristics of the SCM ration, selecting software configuration items,
process (as well as providing project and developing a strategy for labeling software items
management information). For example, and describing their relationships, and identifying
information about the time required to accomplish both the baselines to be used and the procedure for
various types of changes would be useful in an a baselines acquisition of the items.
evaluation of the criteria for determining what
levels of authority are optimal for authorizing 2.1.1. SoftwareConfiguration
certain types of changes and for estimating future [1, c3]
changes.
Care must be taken to keep the focus of the Software configuration is the functional and
surveillance on the insights that can be gained from physical characteristics of hardware or software as
the measurements, not on the measurements set forth in technical documentation or achieved in
themselves. Discussion of software process and a product. It can be viewed as part of an overall
product measurement is presented in the Software system configuration.
Engineering Process KA. Software measurement
programs are described in the Software 2.1.2. SoftwareConfigurationItem
Engineering Management KA. [4*, c29s1.1]
1.5.2. In-ProcessAuditsofSCM A configuration item (CI) is an item or aggregation

[3*, c1s1] of hardware or software or both that is designed to
be managed as a single entity. A software
Audits can be carried out during the software configuration item (SCI) is a software entity that
engineering process to investigate the current status has been established as a configuration item [1].
of specific elements of the configuration or to The SCM typically controls a variety of items in
assess the implementation of the SCM process. In- addition to the code itself. Software items with
process auditing of SCM provides a more formal potential to become SCIs include plans,
mechanism for monitoring selected aspects of the specifications and design documentation, testing
process and may be coordinated with the SQA materials, software tools, source and executable
function (see topic 5, Software Configuration code, code libraries, data and data dictionaries, and
Auditing). documentation for installation, maintenance,
operations, and software use.
2. Software Configuration Identification Selecting SCIs is an important process in which a
[2*, c8] [4*, c29s1.1] balance must be achieved between providing
adequate visibility for project control purposes and
Software configuration identification identifies providing a manageable number of controlled
items to be controlled, establishes identification items.
schemes for the items and their versions, and
establishes the tools and techniques to be used in 2.1.3. SoftwareConfigurationItem
acquiring and managing controlled items. These Relationships
activities provide the basis for the other SCM [3*, c7s4]
activities.
2.1. IdentifyingItemstoBeControlled
[2*, c8s2.2] [4*, c29s1.1]
-
-
Structural relationships among the selected SCIs, formally designated and fixed at a specific time
and their constituent parts, affect other SCM during the configuration items life cycle. The term
activities or tasks, such as software building or is also used to refer to a particular version of a
software
configuration
item that has
been agreed
on. In either
case, the
baseline can
only be
changed
through
formal
change
control
procedures. A
baseline,
together with
all approved
changes to the
Figure 6.2. Acquisition of Items baseline,
analyzing the impact of proposed changes. Proper represents the current approved configuration.
tracking of these relationships is also important for Commonly used baselines include functional,
supporting traceability. The design of the allocated, developmental, and product baselines.
identification scheme for SCIs should consider the The functional baseline corresponds to the
need to map identified items to the software reviewed system requirements. The allocated
structure, as well as the need to support the baseline corresponds to the reviewed software
evolution of the software items and their requirements specification and software interface
relationships. requirements specification. The developmental
baseline represents the evolving software
2.1.4. SoftwareVersion configuration at selected times during the software
[1, c3] [4*, c29s3] life cycle. Change authority for this baseline
typically rests primarily with the development
Software items evolve as a software project organization but may be shared with other
proceeds. A version of a software item is an organizations (for example, SCM or Test). The
identified instance of an item. It can be thought of product baseline corresponds to the completed
as a state of an evolving item. A variant is a version software product delivered for system integration.
of a program resulting from the application of The baselines to be used for a given project, along
software diversity. with the associated levels of authority needed for
change approval, are typically identified in the
2.1.5. Baseline SCMP.
[1, c3]
2.1.6. AcquiringSoftwareConfigurationItems
A software baseline is a formally approved version [3*, c18]
of a configuration item (regardless of media) that is
Software configuration items are placed under control, access is more restricted and SCM is the
SCM control at different times; that is, they are primary user.
incorporated into a particular baseline at a These libraries are also an important source of
particular point in the software life cycle. The information for measurements of work and
triggering event is the completion of some form of progress.
formal acceptance task, such as a formal review.
Figure 6.2 characterizes the growth of baselined 3. Software Configuration Control
items as the life cycle proceeds. This figure is [2*, c9] [4*, c29s2]
based on the waterfall model for purposes of
illustration only; the subscripts used in the figure Software configuration control is concerned with
indicate versions of the evolving items. The managing changes during the software life cycle. It
software change request (SCR) is described in covers the process for determining what changes to
section 3.1. make, the authority for approv ing certain changes,
In acquiring an SCI, its origin and initial integrity support for the implementa tion of those changes,
must be established. Following the acquisition of an and the concept of formal deviations from project
SCI, changes to the item must be formally requirements as well as waivers of them.
approved as appropriate for the SCI and the Information derived from these activities is useful
baseline involved, as defined in the SCMP. in measuring change traffic and breakage as well as
Following approval, the item is incorporated into aspects of rework.
the software baseline according to the appropriate
procedure. 3.1. Requesting,Evaluating,andApproving
SoftwareChanges
2.2. SoftwareLibrary [2*, c9s2.4] [4*, c29s2]
[3*, c1s3] [4*, c29s1.2]
The first step in managing changes to controlled
A software library is a controlled collection of items is determining what changes to make. The
software and related documentation designed to aid software change request process (see a typical flow
in software development, use, or maintenance [1]. of a change request process in Figure 6.3) provides
It is also instrumental in software release formal procedures for submitting and recording
management and delivery activities. Several types change requests, evaluating the potential cost and
of libraries might be used, each corresponding to impact of a proposed change, and accepting,
the software items particular level of maturity. For modifying, deferring, or rejecting the proposed
example, a working library could support coding change. A change request (CR) is a request to
and a project support library could support testing, expand or reduce the project scope; modify
while a master library could be used for finished policies, processes, plans, or procedures; modify
products. An appropriate level of SCM control costs or budgets; or revise schedules [1]. Requests
(associated baseline and level of authority for for changes to software configuration items may be
change) is associated with each library. Security, in originated by anyone at any point in the software
terms of access control and the backup facilities, is life cycle and may include a suggested solution and
a key aspect of library management. requested priority. One source of a CR is the
The tool(s) used for each library must support the initiation of corrective action in response to
SCM control needs for that libraryboth in terms problem reports. Regardless of the source, the type
of controlling SCIs and controlling access to the of change (for example, defect or enhancement) is
library. At the working library level, this is a code usually recorded on the Software CR (SCR).
management capability serving developers, This provides an opportunity for tracking defects
maintainers, and SCM. It is focused on managing and collecting change activity measurements by
the versions of software items while supporting the change type. Once an SCR is received, a technical
activities of multiple developers. At higher levels of evaluation (also known as an impact analysis) is
-
-
performed to determine the extent of the authority of a CCB is strictly software, it is known
modifications that would be necessary should the as a Software Configuration Control Board
change request be accepted. A good understanding (SCCB). The activities of the CCB are typically
of the relationships among software (and, possibly, subject to software quality audit or review.
hardware) items is important for this task. Finally,
an established authoritycommensurate with the 3.1.2. SoftwareChangeRequestProcess
affected baseline, the SCI involved, and the nature [3*, c1s4, c8s4]
of the changewill evaluate the technical and
managerial aspects of the change request and either An effective software change request (SCR)
accept, modify, reject, or defer the proposed process requires the use of supporting tools and
change. procedures for originating change requests,
enforcing the
flow of the
change
process,
capturing
CCB
decisions, and
reporting
change
process
information.
A link
between this
tool
capability and
the problem-
Figure 6.3. Flow of a Change Control Process reporting
3.1.1. SoftwareConfigurationControlBoard system can
[2*, c9s2.2] [3*, c11s1] [4*, c29s2] facilitate the tracking of solutions for reported
problems.
The authority for accepting or rejecting proposed
changes rests with an entity typically known as a 3.2. ImplementingSoftwareChanges
Configuration Control Board (CCB). In smaller [4*, c29]
projects, this authority may actually reside with the
leader or an assigned individual rather than a Approved SCRs are implemented using the defined
multiperson board. There can be multiple levels of software procedures in accordance with the
change authority depending on a variety of criteria applicable schedule requirements. Since a number
such as the criticality of the item involved, the of approved SCRs might be implemented
nature of the change (for example, impact on simultaneously, it is necessary to provide a means
budget and schedule), or the projects current point for tracking which SCRs are incorporated into
in the life cycle. The composition of the CCBs used particular software versions and baselines. As part
for a given system varies depending on these of the closure of the change process, completed
criteria (an SCM representative would always be changes may undergo configuration audits and
present). All stakeholders, appropriate to the level software quality verificationthis includes
of the CCB, are represented. When the scope of ensuring that only approved changes have been
made. The software change request process 4. Software Configuration Status Accounting
described above will typically document the SCM [2*, c10]
(and other) approval information for the change.
Changes may be supported by source code Software configuration status accounting (SCSA) is
version control tools. These tools allow a team of an element of configuration management consisting
software engineers, or a single software engineer, to of the recording and reporting of information
track and document changes to the source code. needed to manage a configuration effectively.
These tools provide a single repository for storing
the source code, can prevent more than one 4.1. SoftwareConfigurationStatusInformation
software engineer from editing the same module at [2*, c10s2.1]
the same time, and record all changes made to the
source code. Software engineers check modules out The SCSA activity designs and operates a system
of the repository, make changes, document the for the capture and reporting of necessary
changes, and then save the edited modules in the information as the life cycle proceeds. As in any
repository. If needed, changes can also be information system, the configuration status infor
mation to be managed for the evolving configura
discarded, restoring a previous baseline. More
tions must be identified, collected, and maintained.
powerful tools can support parallel development
Various information and measurements are needed
and geographically distributed environments. These
to support the SCM process and to meet the
tools may be manifested as separate, specialized
configuration status reporting needs of
applications under the control of an independent
management, software engineering, and other
SCM group. They may also appear as an integrated
related activities. The types of information
part of the software engineering environment.
available include the approved configuration
Finally, they may be as elementary as a
identification as well as the identification and
rudimentary change control system provided with
current implementation status of changes,
an operating system. deviations, and waivers.
Some form of automated tool support is
3.3. DeviationsandWaivers
necessary to accomplish the SCSA data collection
[1, c3]
and reporting tasks; this could be a database
capability, a stand-alone tool, or a capability of a
The constraints imposed on a software engineering
larger, integrated tool environment.
effort or the specifications produced during the
development activities might contain provisions
4.2. SoftwareConfigurationStatusReporting
that cannot be satisfied at the designated point in
[2*, c10s2.4] [3*, c1s5, c9s1, c17]
the life cycle. A deviation is a written authorization,
granted prior to the manufacture of an item, to Reported information can be used by various
depart from a particular performance or design organizational and project elementsincluding the
requirement for a specific number of units or a development team, the maintenance team, project
specific period of time. A waiver is a written management, and software quality activities.
authorization to accept a configuration item or Reporting can take the form of ad hoc queries to
other designated item that is found, during answer specific questions or the periodic
production or after having been submitted for production of predesigned reports. Some
inspection, to depart from specified requirements information produced by the status accounting
but is nevertheless considered suitable for use as-is activity during the course of the life cycle might
or after rework by an approved method. In these become quality assurance records.
cases, a formal process is used for gaining approval
In addition to reporting the current status of the
for deviations from, or waivers of, the provisions. configuration, the information obtained by the
SCSA can serve as a basis of various
measurements. Examples include the number of
-
-
change requests per SCI and the average time reference documentation is consistent with the as-
needed to implement a change request. built software product.
5. Software Configuration Auditing 5.3. In-ProcessAuditsofaSoftwareBaseline

[2*, c11] [2*, c11s2.3]
A software audit is an independent examination of As mentioned above, audits can be carried out
a work product or set of work products to assess during the development process to investigate the
compliance with specifications, standards, current status of specific elements of the
contractual agreements, or other criteria [1]. Audits configuration. In this case, an audit could be
are conducted according to a well-defined process applied to sampled baseline items to ensure that
consisting of various auditor roles and performance is consistent with specifications or to
responsibilities. Consequently, each audit must be ensure that evolving documentation continues to be
carefully planned. An audit can require a number of consistent with the developing baseline item.
individuals to perform a variety of tasks over a
fairly short period of time. Tools to support the 6. Software Release Management and Delivery
planning and conduct of an audit can greatly [2*, c14] [3*, c8s2]
facilitate the process.
Software configuration auditing determines the In this context, release refers to the distribution of
extent to which an item satisfies the required a software configuration item outside the
functional and physical characteristics. Informal development activity; this includes internal releases
audits of this type can be conducted at key points in as well as distribution to customers. When different
the life cycle. Two types of formal audits might be versions of a software item are available for
required by the governing contract (for example, in delivery (such as versions for different platforms or
contracts covering critical software): the Functional versions with varying capabilities), it is frequently
Configuration Audit (FCA) and the Physical necessary to recreate specific versions and package
Configuration Audit (PCA). Successful completion the correct materials for delivery of the version.
of these audits can be a prerequisite for the The software library is a key element in
establishment of the product baseline. accomplishing release and delivery tasks.
5.1. SoftwareFunctionalConfigurationAudit 6.1. SoftwareBuilding

[2*, c11s2.1] [4*, c29s4]
The purpose of the software FCA is to ensure that

the audited software item is consistent with its
governing specifications. The output of the
software verification and validation activities (see
Verification and Validation in the Software Quality
KA) is a key input to this audit.
5.2. SoftwarePhysicalConfigurationAudit
[2*, c11s2.2]
The purpose of the software physical configuration

audit (PCA) is to ensure that the design and
Software building is the activity of combining the case, supporting tools and associated build
correct versions of software configuration items, instructions need to be under SCM control to
using the appropriate configuration data, into an ensure availability of the correct versions of the
executable program for delivery to a customer or tools.
other recipient, such as the testing activity. For A tool capability is useful for selecting the
systems with hardware or firmware, the executable correct versions of software items for a given target
program is delivered to the system-building environment and for automating the process of
activity. Build instructions ensure that the proper building the software from the selected versions
build steps are taken in the correct sequence. In and appropriate configuration data. For projects
addition to building software for new releases, it is with parallel or distributed development
usually also necessary for SCM to have the environments, this tool capability is necessary.
capability to reproduce previous releases for Most software engineering environments provide
recovery, testing, maintenance, or additional release this capability. These tools vary in complexity from
purposes. requiring the software engineer to learn a
Software is built using particular versions of specialized scripting language to graphics-oriented
supporting tools, such as compilers (see Compiler approaches that hide much of the complexity of an
Basics in the Computing Foundations KA). It might intelligent build facility.
be necessary to rebuild an exact copy of a The build process and products are often subject
previously built software configuration item. In this to software quality verification. Outputs of
the build process might be needed for future maintain information on various target platforms
reference and may become quality assurance and on various customer environments.
records.
7. Software Configuration Management Tools
6.2. SoftwareReleaseManagement [3*, c26s1] [4*, c8s2]
[4*, c29s3.2]
When discussing software configuration
Software release management encompasses the management tools, it is helpful to classify them.
identification, packaging, and delivery of the SCM tools can be divided into three classes in
elements of a productfor example, an terms of the scope at which they provide
executable program, documentation, release support: individual support, project-related
notes, and configuration data. Given that support, and companywide-process support.
product changes can occur on a continuing Individual support tools are appropriate and
basis, one concern for release management is typically sufficient for small organizations or
determining when to issue a release. The development groups without variants of their
severity of the problems addressed by the software products or other complex SCM
release and measurements of the fault densities requirements. They include:
of prior releases affect this decision. The
packaging task must identify which product Version control tools: track, document, and
items are to be delivered and then select the store individual configuration items such as
correct variants of those items, given the source code and external documentation.
intended application of the product. The Build handling tools: in their simplest form,
information documenting the physical contents such tools compile and link an executable
of a release is known as a version description version of the software. More advanced
document. The release notes typically describe building tools extract the latest version from
new capabilities, known problems, and platform the version control software, perform
requirements necessary for proper product quality checks, run regression tests, and
operation. The package to be released also produce various forms of reports, among
contains installation or upgrading instructions. other tasks.
The latter can be complicated by the fact that Change control tools: mainly support the
some current users might have versions that are control of change requests and events
several releases old. In some cases, release notification (for example, change request
management might be required in order to track status changes, milestones reached).
distribution of the product to various customers
or target systemsfor example, in a case where Project-related support tools mainly support
the supplier was required to notify a customer of workspace management for development teams
newly reported problems. Finally, a mechanism and integrators; they are typically able to
to ensure the integrity of the released item can support distributed development environments.
be implementedfor example by releasing a Such tools are appropriate for medium to large
digital signature with it. organizations with variants of their software
A tool capability is needed for supporting products and parallel development but no
these release management functions. It is useful certification requirements.
to have a connection with the tool capability Companywide-processsupporttools can
supporting the change request process in order typically automate portions of a companywide
to map release contents to the SCRs that have process, providing support for workflow
been received. This tool capability might also managements, roles, and responsibilities. They
are able to handle many items, data, and life by supporting a more formal development
cycles. Such tools add to project-related support process, including certification requirements.
Hass 2003
[3*] Moore [5*]
2006
IEEE 828-2012
[2*] Sommerville 201
[4*]
1. Management of the SCM

Process
1.1. Organizational Context for
c6, ann.D introduction c29
SCM
1.2. Constraints and Guidance c6, ann.D,
c2 c19s2.2 c29 intro
for the SCM Process ann.E
c6, ann.D,
1.3. Planning for SCM c23 c29
ann.E
1.3.1. SCM Organization
and ann.Ds56 c1011 c29 intro
Responsibilities
1.3.2. SCM Resources and
ann.Ds8 c23
Schedules
1.3.3. Tool Selection and
c26s2; s6 c29s5
Implementation
1.3.4. Vendor/Subcontractor
c13 c13s9c14s2
Control
1.3.5. Interface Control c12 c24s4
1.4. SCM Plan ann.D c23 c29s1
1.5. Surveillance of Software
c11s3
Configuration Management
1.5.1. SCM Measures and c9s2; c25s2
Measurement s3
1.5.2. In-Process Audits of
c1s1
SCM
2. Software Configuration
c29s1.1
Identification
2.1. Identifying Items to Be

c8s2.2 c29s1.1
Controlled
2.1.1. Software
Configuration
c29s1.1
Item
c7s4
Item Relationships
2.1.4. Software Version c29s3
Hass 2003
[3*] Moore [5*]
2006
IEEE 828-2012
[4*]
2.1.5. Baseline
2.1.6. Acquiring Software
c18
Configuration Items
2.2. Software Library c1s3 c29s1.2
c9 c29s2
Control
3.1. Requesting, Evaluating, and
c9s2.4 c29s2
Approving Software Changes
3.1.1. Software
Configuration c9s2.2 c11s1 c29s2
Control Board
3.1.2. Software Change
c1s4, c8s4
Request Process
3.2. Implementing Software
c29
Changes
3.3. Deviations and Waivers
c10
Status Accounting
4.1. Software Configuration
c10s2.1
Status Information
4.2. Software Configuration c1s5, c9s1,

c10s2.4
Status Reporting c17
c11
Auditing
5.1. Software Functional
c11s2.1
Configuration Audit
5.2. Software Physical
c11s2.2
Configuration Audit
5.3. In-Process Audits of a
c11s2.3
Software Baseline
6. Software Release
c14 c8s2 c29s3
Management and Delivery
6.1. Software Building c29s4
6.2. Software Release
c29s3.2
Management
c26s1
Management Tools
FURTHER READINGS [2*] IEEEStd.828-2012,Standardfor
ConfigurationManagementinSystemsand
Stephen P. Berczuk and Brad Appleton, SoftwareEngineering, IEEE, 2012.
SoftwareConfigurationManagement
Patterns:EffectiveTeamwork,Practical [3*] A.M.J. Hass, ConfigurationManagement
Integration [6]. PrinciplesandPractices, 1st ed.,
This book expresses useful SCM practices and
strategies as patterns. The patterns can be [4*] I. Sommerville, SoftwareEngineering, 9th
implemented using various tools, but they are ed., Addison-Wesley, 2011.
expressed in a tool-agnostic fashion.
[5*] J.W. Moore, TheRoadMaptoSoftware
CMMI for Development, Version 1.3, pp. Engineering:AStandards-BasedGuide,
137147 [7]. Wiley-IEEE Computer Society Press, 2006.
This model presents a collection of best [6] S.P. Berczuk and B. Appleton, Software
practices to help software development ConfigurationManagementPatterns:
organizations improve their processes. At EffectiveTeamwork,PracticalIntegration,
maturity level 2, it suggests configuration Addison-Wesley Professional, 2003.
management activities.
REFERENCES [7] CMMI Product Team, CMMI for
Development, Version 1.3, Software
[1] ISO/IEC/IEEE24765:2010Systemsand Engineering Institute, 2010; http://
SoftwareEngineeringVocabulary, ISO/ resources.sei.cmu.edu/library/asset-view.
IEC/IEEE, 2010. cfm?assetID=9661.
CHAPTER 7
SOFTWARE ENGINEERING MANAGEMENT

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

Other aspects of organizational management management of software engineering projects
exert an impact on software engineering (for across an organization (for example,
example, organizational policies and procedures establishing a consistent basis by which to
that provide the framework in which software analyze past project performance and implement
engineering projects are undertaken). These improvements).
policies and procedures may need to be adjusted Another important aspect of organizational
by the requirements for effective software management is personnel management policies
development and maintenance. In addition, a and procedures for hiring, training, and
number of policies specific to software mentoring personnel for career development,
engineering may need to be in place or not only at the project level, but also to the
established for effective management of longer-term success of an organization.
software engineering at the organizational level. Software engineering personnel may present
For example, policies are usually necessary to unique training or personnel management
establish specific organization-wide processes challenges (for example, maintaining currency
or procedures for software engineering tasks in a context where the underlying technology
such as software design, software construction, undergoes rapid and continuous change).
estimating, monitoring, and reporting. Such Communication management is also often
policies are important for effective long-term mentioned as an overlooked but important
aspect of the performance of individuals in a This Software Engineering Management KA

field where precise understanding of user needs, consists of the software project management
software requirements, and software designs is processes in the first five topics in Figure 7.1
necessary. Furthermore, portfolio management, (Initiation and Scope Definition, Software
which provides an overall view, not only of Project Planning, Software Project Enactment,
software currently under development in various Review and Evaluation, Closure), plus Software
projects and programs (integrated projects), but Engineering Measurement in the sixth topic and
also of software planned and currently in use in Software Engineering Management Tools in the
an organization, is desirable. Also, software seventh topic. While project management and
reuse is a key factor in maintaining and measurement management are often regarded as
improving productivity and competitiveness. being separate, and indeed each does possess
Effective reuse requires a strategic vision that many unique attributes, the close relationship
reflects the advantages and disadvantages of has led to combined treatment in this KA.
reuse. Unfortunately, a common perception of the
In addition to understanding the aspects of software industry is that software products are
management that are uniquely influenced by delivered late, over budget, of poor quality, and
software projects, software engineers should with incomplete functionality. Measurement-
have some knowledge of the more general informed managementa basic principle of any
aspects of management that are discussed in this true engineering discipline (see Measurement in
KA (even in the first few years after the Engineering Foundations KA)can help
graduation). improve the perception and the reality. In
Attributes of organizational culture and essence, management without measurement
behavior, plus management of other functional (qualitative and quantitative) suggests a lack of
areas of the enterprise, have an influence, albeit discipline, and measurement without
indirectly, on an organizations software management suggests a lack of purpose or
engineering processes. context. Effective management requires a
Extensive information concerning software combination of both measurement and
project management can be found in the Guide experience.
totheProjectManagementBodyofKnowledge The following working definitions are
(PMBOK Guide) and the SoftwareExtension adopted here:
tothePMBOK Guide (SWX) [1] [2]. Each of
these guides includes ten project management Management is a system of processes and
KAs: project integration management, project controls required to achieve the strategic
scope management, project time management, objectives set by the organization.
project cost management, project quality Measurement refers to the assignment of
management, project human resource values and labels to software engineering
management, project communications work products, processes, and resources
management, project risk management, project plus the models that are derived from them,
procurement management, and project whether these models are developed using
stakeholder management. Each KA has direct statistical or other techniques [3* , c7, c8].
relevance to this Software Engineering
Management KA. The software engineering project
Additional information is also provided in the management sections in this KA make extensive
other references and further readings for this use of the software engineering measurement
KA. section.
This KA is closely related to others in the software development project is being managed,
SWEBOK Guide, and reading the following KA independent of the software development life
descriptions in conjunction with this one will be cycle model (see Software Life Cycle Models in
particularly helpful: the Software Engineering Process KA) that has
been chosen for a specific project. There is no
The Engineering Foundations KA describes intent in this breakdown to recommend a
some general concepts of measurement that specific life cycle model. The breakdown
are directly applicable to the Software implies only what happens and does not imply
Engineering Measurement section of this when, how, or how many times each activity
KA. In addition, the concepts and occurs. The seven topics are:
techniques presented in the Statistical
Analysis section of the Engineering Initiation and Scope Definition, which deal
Foundations KA apply directly to many with the decision to embark on a software
topics in this KA. engineering project;
The Software Requirements KA describes Software Project Planning, which addresses
some of the activities that should be the activities undertaken to prepare for a
performed during the Initiation and Scope successful software engineering project
definition phase of the project. from the management perspective;
The Software Configuration Management Software Project Enactment, which deals
KA deals with identification, control, status with generally accepted software
accounting, and auditing of software engineering management activities that
configurations along with software release occur during the execution of a software
management and delivery and software engineering project;
configuration management tools. Review and Evaluation, which deal with
The Software Engineering Process KA ensuring that technical, schedule, cost, and
describes software life cycle models and the quality engineering activities are
relationships between processes and work satisfactory; Closure, which addresses the
products. activities accomplished to complete a
The Software Quality KA emphasizes project;
quality as a goal of management and as an Software Engineering Measurement, which
aim of many software engineering activities. deals with the effective development and
The Software Engineering Economics KA implementation of measurement programs
discusses how to make software-related in software engineering organizations;
decisions in a business context. Software Engineering Management Tools,
which describes the selection and use of
SOFTWARE ENGINEERING tools for managing a software engineering
MANAGEMENT project. 1. Initiation and Scope Definition
Because most software development life cycle The focus of these activities is on effective
models require similar activities that may be determination of software requirements using
executed in different ways, the breakdown of various elicitation methods and the assessment
topics is activity-based. That breakdown is of project feasibility from a variety of
shown in Figure 7.1. The elements of the top- standpoints. Once project feasibility has been
level breakdown shown in that figure are the established, the remaining tasks within this
activities that are usually performed when a section are the specification of requirements and
selection of the processes for revision and revised (for example, change management
review of requirements. procedures, iterative cycle retrospectives). This
clearly implies that scope and requirements will
1.1. DeterminationandNegotiationof not be set in stone but can and should be
Requirements revisited at predetermined points as the project
[3*, c3] unfolds (for example, at the time when backlog
priorities are created or at milestone reviews). If
Determining and negotiating requirements set changes are accepted, then some form of
the visible boundaries for the set of tasks being traceability analysis and risk analysis should be
undertaken (see the Software Requirements used to ascertain the impact of those changes
KA). Activities include requirements elicitation, (see section 2.5, Risk Management, and
analysis, specification, and validation. Methods Software Configuration Control in the Software
and techniques should be selected and applied, Configuration Management KA).
taking into account the various stakeholder A managed-change approach can also form
perspectives. This leads to the determination of the basis for evaluation of success during
project scope in order to meet objectives and closure of an incremental cycle or an entire
satisfy constraints. project, based on changes that have occurred
along the way (see topic 5, Closure).
1.2. FeasibilityAnalysis
[4*, c4] 2.Software Project Planning
The purpose of feasibility analysis is to develop The first step in software project planning
a clear description of project objectives and should be selection of an appropriate software
evaluate alternative approaches in order to development life cycle model and perhaps
determine whether the proposed project is the tailoring it based on project scope, software
best alternative given the constraints of requirements, and a risk assessment. Other
technology, resources, finances, and factors to be considered include the nature of
social/political considerations. An initial project the application domain, functional and technical
and product scope statement, project complexity, and software quality requirements
deliverables, project duration constraints, and an (see Software Quality Requirements in the
estimate of resources needed should be Software Quality KA).
prepared. In all SDLCs, risk assessment should be an
Resources include a sufficient number of element of initial project planning, and the risk
people who have the needed skills, facilities, profile of the project should be discussed and
infrastructure, and support (either internally or accepted by all relevant stakeholders. Software
externally). Feasibility analysis often requires quality management processes (see Software
approximate estimations of effort and cost based Quality Management Processes in the Software
on appropriate methods (see section 2.3, Effort, Quality KA) should be determined as part of the
Schedule, and Cost Estimation). planning process and result in procedures and
1.3. ProcessfortheReviewand responsibilities for software quality assurance,
RevisionofRequirements verification and validation, reviews, and audits
[3*, c3] (see the Software Quality KA). Processes and
responsibilities for ongoing review and revision
Given the inevitability of change, stakeholders of the project plan and related plans should also
should agree on the means by which be clearly stated and agreed upon.
requirements and scope are to be reviewed and 2.1. ProcessPlanning
[3*, c3, c4, c5] [5*, c1] The work product(s) of each project activity (for
example, software architecture design
Software development life cycle (SDLC) documents, inspection reports, tested software)
models span a continuum from predictive to should be identified and characterized.
adaptive (see Software Life Cycle Models in the Opportunities to reuse software components
Software Engineering Process KA). Predictive from previous projects or to utilize off-the-shelf
SDLCs are characterized by development of software products should be evaluated.
detailed software requirements, detailed project Procurement of software and use of third parties
planning, and minimal planning for iteration to develop deliverables should be planned and
among development phases. Adaptive SDLCs suppliers selected (see section 3.2, Software
are designed to accommodate emergent Acquisition and Supplier Contract
software requirements and iterative adjustment Management).
of plans. A highly predictive SDLC executes the
first five processes listed in Figure 7.1 in a 2.3. Effort,Schedule,andCostEstimation
linear sequence with revisions to earlier phases [3*, c6]
only as necessary. Adaptive SDLCs are
characterized by iterative development cycles. The estimated range of effort required for a
SDLCs in the mid-range of the SDLC project, or parts of a project, can be determined
continuum produce increments of functionality using a calibrated estimation model based on
on either a preplanned schedule (on the historical size and effort data (when available)
predictive side of the continuum) or as the and other relevant methods such as expert
products of frequently updated development judgment and analogy. Task dependencies can
cycles (on the adaptive side of the continuum). be established and potential opportunities for
Well-known SDLCs include the waterfall, completing tasks concurrently and sequentially
incremental, and spiral models plus various can be identified and documented using a Gantt
forms of agile software development [2] [3*, chart, for example. For predictive SDLC
c2]. projects, the expected schedule of tasks with
Relevant methods (see the Software projected start times, durations, and end times is
Engineering Models and Methods KA) and tools typically produced during planning. For
should be selected as part of planning. adaptive SDLC projects, an overall estimate of
Automated tools that will be used throughout effort and schedule is typically developed from
the project should also be planned for and the initial understanding of the requirements, or,
acquired. Tools may include tools for project alternatively, constraints on overall effort and
scheduling, software requirements, software schedule may be specified and used to
design, software construction, software determine an initial estimate of the number of
maintenance, software configuration iterative cycles and estimates of effort and other
management, software engineering process, resources allocated to each cycle.
software quality, and others. While many of Resource requirements (for example, people
these tools should be selected based primarily and tools) can be translated into cost estimates.
on the technical considerations discussed in Initial estimation of effort, schedule, and cost is
other KAs, some of them are closely related to an iterative activity that should be negotiated
the management considerations discussed in this and revised among affected stakeholders until
chapter. consensus is reached on resources and time
available for project completion.
2.2. DetermineDeliverables
[3*, c4, c5, c6] 2.4. ResourceAllocation
[3*, c5, c10, c11] management of a software project. Particular

attention should be paid to the management of
Equipment, facilities, and people should be risks related to software quality requirements
allocated to the identified tasks, including the such as safety or security (see the Software
allocation of responsibilities for completion of Quality KA). Risk management should be done
various elements of a project and the overall not only at the beginning of a project, but also at
project. A matrix that shows who is responsible periodic intervals throughout the project life
for, accountable for, consulted about, and cycle.
informed about each of the tasks can be used.
Resource allocation is based on, and constrained 2.6. QualityManagement
by, the availability of resources and their [3*, c4] [4*, c24]
optimal use, as well as by issues relating to
personnel (for example, productivity of Software quality requirements should be
individuals and teams, team dynamics, and team identified, perhaps in both quantitative and
structures). qualitative terms, for a software project and the
associated work products. Thresholds for
2.5. RiskManagement acceptable quality measurements should be set
[3*, c9] [5*, c5] for each software quality requirement based on
stakeholder needs and expectations. Procedures
Risk and uncertainty are related but distinct concerned with ongoing Software Quality
concepts. Uncertainty results from lack of Assurance (SQA) and quality improvement
information. Risk is characterized by the throughout the development process, and for
probability of an event that will result in a verification and validation of the deliverable
negative impact plus a characterization of the software product, should also be specified
negative impact on a project. Risk is often the during quality planning (for example, technical
result of uncertainty. The converse of risk is reviews and inspections or demonstrations of
opportunity, which is characterized by the completed functionality; see the Software
probability that an event having a positive Quality KA).
outcome might occur.
Risk management entails identification of risk 2.7.PlanManagement
factors and analysis of the probability and [3*, c4]
potential impact of each risk factor,
prioritization of risk factors, and development of For software projects, where change is an
risk mitigation strategies to reduce the expectation, plans should be managed.
probability and minimize the negative impact if Managing the project plan should thus be
a risk factor becomes a problem. Risk planned. Plans and processes selected for
assessment methods (for example, expert software development should be systematically
judgment, historical data, decision trees, and monitored, reviewed, reported, and, when
process simulations) can sometimes be used in appropriate, revised. Plans associated with
order to identify and evaluate risk factors. supporting processes (for example,
Project abandonment conditions can also be documentation, software configuration
determined at this point in discussion with all management, and problem resolution) also
relevant stakeholders. Software-unique aspects should be managed. Reporting, monitoring, and
of risk, such as software engineers tendency to controlling a project should fit within the
add unneeded features, or the risks related to selected SDLC and the realities of the project;
softwares intangible nature, can influence risk
plans should account for the various artifacts what the supplier or suppliers are providing and
that will be used to manage the project. what the acquirer is paying for, plus what will
be delivered to and owned by the acquirer. For
3.Software Project Enactment software being developed by suppliers (both
internal to or external to the software
During software project enactment (also known development organization), agreements
as project execution) plans are implemented and commonly indicate software quality
the processes embodied in the plans are enacted. requirements for acceptance of the delivered
Throughout, there should be a focus on software.
adherence to the selected SDLC processes, with After the agreement has been put in place,
an overriding expectation that adherence will execution of the project in compliance with the
lead to the successful satisfaction of stakeholder terms of the agreement should be managed (see
requirements and achievement of the projects chapter 12 of SWX, Software Procurement
objectives. Fundamental to enactment are the Management, for more information on this topic
ongoing management activities of monitoring, [2]).
controlling, and reporting.
3.3. ImplementationofMeasurementProcess
3.1. ImplementationofPlans [3*, c7]
[4*, c2]
The measurement process should be enacted
Project activities should be undertaken in during the software project to ensure that
accordance with the project plan and supporting relevant and useful data are collected (see
plans. Resources (for example, personnel, sections 6.2, Plan the Measurement Process, and
technology, and funding) are utilized and work 6.3, Perform the Measurement Process).
products (for example, software design,
software code, and software test cases) are 3.4. MonitorProcess
generated. [3*, c8]
3.2. SoftwareAcquisitionandSupplier Adherence to the project plan and related plans

ContractManagement should be assessed continually and at
[3*, c3, c4] predetermined intervals. Also, outputs and
completion criteria for each task should be
Software acquisition and supplier contract assessed. Deliverables should be evaluated in
management is concerned with issues involved terms of their required characteristics (for
in contracting with customers of the software example, via inspections or by demonstrating
development organization who acquire the working functionality). Effort expenditure,
deliverable work products and with suppliers schedule adherence, and costs to date should be
who supply products or services to the software analyzed, and resource usage examined. The
engineering organization. project risk profile (see section 2.5, Risk
This may involve selection of appropriate Management) should be revisited, and
kinds of contracts, such as fixed price, time and adherence to software quality requirements
materials, cost plus fixed fee, or cost plus evaluated (see Software Quality Requirements
incentive fee. Agreements with customers and in the Software Quality KA).
suppliers typically specify the scope of work Measurement data should be analyzed (see
and the deliverables and include clauses such as Statistical Analysis in the Engineering
penalties for late delivery or nondelivery and Foundations KA). Variance analysis based on
intellectual property agreements that specify
the deviation of actual from expected outcomes At specified and agreed-upon times, progress to
and values should be determined. This may date should be reportedboth within the
include cost overruns, schedule slippage, or organization (for example, to a project steering
other similar measures. Outlier identification committee) and to external stakeholders (for
and analysis of quality and other measurement example, clients or users). Reports should focus
data should be performed (for example, defect on the information needs of the target audience
analysis; see Software Quality Measurement in as opposed to the detailed status reporting
the Software Quality KA). Risk exposures within the project team.
should be recalculated (see section 2.5, Risk
Management). These activities can enable 4.Review and Evaluation
problem detection and exception identification
based on thresholds that have been exceeded. At prespecified times and as needed, overall
Outcomes should be reported when thresholds progress towards achievement of the stated
have been exceeded, or as necessary. objectives and satisfaction of stakeholder (user
and customer) requirements should be
3.5. ControlProcess evaluated. Similarly, assessments of the
[3*, c7, c8] effectiveness of the software process, the
personnel involved, and the tools and methods
The outcomes of project monitoring activities employed should also be undertaken regularly
provide the basis on which decisions can be and as determined by circumstances.
made. Where appropriate, and when the
probability and impact of risk factors are 4.1. DeterminingSatisfactionof
understood, changes can be made to the project. Requirements
This may take the form of corrective action (for [4*, c8]
example, retesting certain software
components); it may involve incorporating Because achieving stakeholder satisfaction is a
additional actions (for example, deciding to use principal goal of the software engineering
prototyping to assist in software requirements manager, progress towards this goal should be
validation; see Prototyping in the Software assessed periodically. Progress should be
Requirements KA); and/or it may entail revision assessed on achievement of major project
of the project plan and other project documents milestones (for example, completion of software
(for example, the software requirements design architecture or completion of a software
specification) to accommodate unanticipated technical review), or upon completion of an
events and their implications. iterative development cycle that results in a
In some instances, the control process may product increment. Variances from software
lead to abandonment of the project. In all cases, requirements should be identified and
software configuration control and software appropriate actions should be taken.
configuration management procedures should be As in the control process activity above (see
adhered to (see the Software Configuration section 3.5, Control Process), software
Management KA), decisions should be configuration control and software configuration
documented and communicated to all relevant management procedures should be followed (see
parties, plans should be revisited and revised the Software Configuration Management KA),
when necessary, and relevant data recorded (see decisions documented and communicated to all
section 6.3, Perform the Measurement Process). relevant parties, plans revisited and revised
where necessary, and relevant data recorded (see
3.6. Reporting section 6.3, Perform the Measurement Process).
[3*, c11]
4.2. ReviewingandEvaluating After closure has been confirmed, archiving of

Performance project materials should be accomplished in
[3*, c8, c10] accordance with stakeholder agreed-upon
methods, location, and durationpossibly
Periodic performance reviews for project including destruction of sensitive information,
personnel can provide insights as to the software, and the medium on which copies are
likelihood of adherence to plans and processes resident. The organizations measurement
as well as possible areas of difficulty (for database should be updated with relevant
example, team member conflicts). The various project data. A project, phase, or iteration
methods, tools, and techniques employed should retrospective analysis should be undertaken so
be evaluated for their effectiveness and that issues, problems, risks, and opportunities
appropriateness, and the process being used by encountered can be analyzed (see topic 4,
the project should also be systematically and Review and Evaluation). Lessons learned
periodically assessed for relevance, utility, and should be drawn from the project and fed into
efficacy in the project context. Where organizational learning and improvement
appropriate, changes should be made and endeavors.
managed.
6.Software Engineering Measurement
5.Closure
The importance of measurement and its role in
An entire project, a major phase of a project, or better management and engineering practices is
an iterative development cycle reaches closure widely acknowledged (see Measurement in the
when all the plans and processes have been Engineering Foundations KA). Effective
enacted and completed. The criteria for project, measurement has become one of the
phase, or iteration success should be evaluated. cornerstones of organizational maturity.
Once closure is established, archival, Measurement can be applied to organizations,
retrospective, and process improvement projects, processes, and work products. In this
activities can be performed. section the focus is on the application of
measurement at the levels of projects, processes,
5.1. DeterminingClosure and work products.
[1, s3.7, s4.6] This section follows the IEEE 15939:2008
standard [6], which describes a process to define
Closure occurs when the specified tasks for a the activities and tasks necessary to implement a
project, a phase, or an iteration have been software measurement process. The standard
completed and satisfactory achievement of the also includes a measurement information model.
completion criteria has been confirmed.
Software requirements can be confirmed as 6.1. EstablishandSustain
satisfied or not, and the degree of achieving the MeasurementCommitment
objectives can be determined. Closure processes [7*, c1, c2]6
should involve relevant stakeholders and result
in documentation Requirements for measurement. Each
of relevant stakeholders acceptance; any known measurement endeavor should be guided by
problems should be documented.
5.2. ClosureActivities 6 Please note that these two chapters can be
[2, s3.7, s4.8] downloaded free of charge from
www.psmsc.com/ PSMBook.asp.
organizational objectives and driven by a set domains, technology, organizational

of measurement requirements established interfaces, and organizational structure.
by the organization and the project (for Identify information needs. Information
example, an organizational objective might needs are based on the goals, constraints,
be first-to-market with new products). risks, and problems of the organizational
Scope of measurement. The organizational unit. They may be derived from business,
unit to which each measurement organizational, regulatory, and/or product
requirement is to be applied should be objectives. They should be identified and
established. This may consist of a functional prioritized. Then a subset of objectives to be
area, a single project, a single site, or an addressed can be selected, documented,
entire enterprise. The temporal scope of the communicated, and reviewed by
measurement effort should also be stakeholders.
considered because time series of some Select measures. Candidate measures
measurements may be required; for should be selected, with clear links to the
example, to calibrate estimation models (see information needs. Measures should be
section 2.3, Effort, Schedule, and Cost selected based on the priorities of the
Estimation). information needs and other criteria such as
Team commitment to measurement. The cost of collection, degree of process
commitment should be formally established, disruption during collection, ease of
communicated, and supported by resources obtaining accurate, consistent data, and ease
(see next item). of analysis and reporting. Because internal
Resources for measurement. An quality characteristics (see Models and
organizations commitment to measurement Quality Characteristics in the Software
is an essential factor for success, as Quality KA) are often not contained in the
evidenced by the assignment of resources contractually binding software
for implementing the measurement process. requirements, it is important to consider
Assigning resources includes allocation of measuring the internal quality of the
responsibility for the various tasks of the software to provide an early indicator of
measurement process (such as analyst and potential issues that may impact external
librarian). Adequate funding, training, tools, stakeholders.
and support to conduct the process should Define data collection, analysis, and
also be allocated. reporting procedures. This encompasses
collection procedures and schedules,
storage, verification, analysis, reporting,
6.2. PlantheMeasurementProcess and configuration management of data.
[7*, c1, c2] Select criteria for evaluating the information
products. Criteria for evaluation are
Characterize the organizational unit. The influenced by the technical and business
organizational unit provides the context for objectives of the organizational unit.
measurement, so the organizational context Information products include those
should be made explicit, including the associated with the product being produced,
constraints that the organization imposes on as well as those associated with the
the measurement process. The processes being used to manage and
characterization can be stated in terms of measure the project.
organizational processes, application Provide resources for measurement tasks.
The measurement plan should be reviewed
and approved by the appropriate should be considered. In addition, the

stakeholders to include all data collection measurement procedures should be
procedures; storage, analysis, and reporting communicated to those providing the data.
procedures; evaluation criteria; schedules; Training and support may also need to be
and responsibilities. Criteria for reviewing provided. Data analysis and reporting
these artifacts should have been established procedures are typically integrated into
at the organizational-unit level or higher and organizational and/ or project processes in a
should be used as the basis for these similar manner.
reviews. Such criteria should take into Collect data. Data should be collected,
consideration previous experience, verified, and stored. Collection can
availability of resources, and potential sometimes be automated by using software
disruptions to projects when changes from engineering management tools (see topic 7,
current practices are proposed. Approval Software Engineering Management Tools)
demonstrates commitment to the to analyze data and develop reports. Data
measurement process. may be aggregated, transformed, or recoded
Identify resources to be made available for as part of the analysis process, using a
implementing the planned and approved degree of rigor appropriate to the nature of
measurement tasks. Resource availability the data and the information needs. The
may be staged in cases where changes are to results of this analysis are typically
be piloted before widespread deployment. indicators such as graphs, numbers, or other
Consideration should be paid to the indications that will be interpreted, resulting
resources necessary for successful in conclusions and recommendations to be
deployment of new procedures or measures. presented to stakeholders (see Statistical
Acquire and deploy supporting Analysis in the Engineering Foundations
technologies. This includes evaluation of KA). The results and conclusions are
available supporting technologies, selection usually reviewed, using a process defined
of the most appropriate technologies, by the organization (which may be formal
acquisition of those technologies, and or informal). Data providers and
deployment of those technologies. measurement users should participate in
reviewing the data to ensure that they are
6.3. PerformtheMeasurementProcess meaningful and accurate and that they can
[7*, c1, c2] result in reasonable actions.
Communicate results. Information products
Integrate measurement procedures with should be documented and communicated
relevant software processes. The to users and stakeholders.
measurement procedures, such as data
collection, should be integrated into the 6.4. EvaluateMeasurement
software processes they are measuring. This [7*, c1, c2]
may involve changing current software
processes to accommodate data collection Evaluate information products and the
or generation activities. It may also involve measurement process against specified
analysis of current software processes to evaluation criteria and determine strengths
minimize additional effort and evaluation of and weaknesses of the information products
the effect on employees to ensure that the or process, respectively. Evaluation may be
measurement procedures will be accepted. performed by an internal process or an
Morale issues and other human factors external audit; it should include feedback
from measurement users. Lessons learned scheduling tools that analyze the tasks within a
should be recorded in an appropriate work breakdown structure, their estimated
database. durations, their precedence relationships, and
Identify potential improvements. Such the resources assigned to each task to produce a
improvements may be changes in the format schedule in the form of a Gantt chart.
of indicators, changes in units measured, or Tracking tools can be used to track project
reclassification of measurement categories. milestones, regularly scheduled project status
The costs and benefits of potential meetings, scheduled iteration cycles, product
improvements should be determined and demonstrations, and/or action items.
appropriate improvement actions should be Risk Management Tools. Risk management
reported. tools (see section 2.5, Risk Management) can be
Communicate proposed improvements to used to track risk identification, estimation, and
the measurement process owner and monitoring. These tools include the use of
stakeholders for review and approval. Also, approaches such as simulation or decision trees
lack of potential improvements should be to analyze the effect of costs versus payoffs and
communicated if the analysis fails to subjective estimates of the probabilities of risk
identify any improvements. events. Monte Carlo simulation tools can be
used to produce probability distributions of
7. Software Engineering Management Tools effort, schedule, and risk by combining multiple
[3*, c5, c6, c7] input probability distributions in an algorithmic
manner.
Software engineering management tools are CommunicationsTools.Communication tools
often used to provide visibility and control of can assist in providing timely and consistent
software engineering management processes. information to relevant stakeholders involved in
Some tools are automated while others are a project. These tools can include things like
manually implemented. There has been a recent email notifications and broadcasts to team
trend towards the use of integrated suites of members and stakeholders. They also include
software engineering tools that are used communication of minutes from regularly
throughout a project to plan, collect and record, scheduled project meetings, daily stand-up
monitor and control, and report project and meetings, plus charts showing progress,
product information. Tools can be divided into backlogs, and maintenance request resolutions.
the following categories: Measurement Tools. Measurement tools
ProjectPlanningandTrackingTools. Project support activities related to the software
planning and tracking tools can be used to measurement program (see topic 6, Software
estimate project effort and cost and to prepare Engineering Measurement). There are few
project schedules. Some projects use automated completely automated tools in this category.
estimation tools that accept as input the Measurement tools used to gather, analyze, and
estimated size and other characteristics of a report project measurement data may be based
software product and produce estimates of the on spreadsheets developed by project team
required total effort, schedule, and cost. members or organizational employees.
Planning tools also include automated
Fairley [3*]
2009
Sommerville 2011 McGarry et al. 20
[4*]
Boehm and Turner 2003
[7*]
[5*]
1. Initiation and Scope

Definition
1.1. Determination and
c3
Negotiation of Requirements
1.2. Feasibility Analysis c4
1.3. Process for the Review and
c3
Revision of Requirements
2. Software Project Planning
2.1. Process Planning c2, c3, c4, c5 c1
2.2. Determine Deliverables c4, c5, c6
2.3. Effort, Schedule, and Cost
c6
Estimation
2.4. Resource Allocation c5, c10, c11
2.5. Risk Management c9 c5
2.6. Quality Management c4 c24
2.7. Plan Management c4
3. Software Project Enactment
3.1. Implementation of Plans c2
3.2. Software Acquisition and
c3, c4
Supplier Contract Management
3.3. Implementation of
c7
Measurement Process
3.4. Monitor Process c8
3.5. Control Process c7, c8
3.6. Reporting c11
4. Review and Evaluation

4.1. Determining Satisfaction
of
Requirements
4.2. Reviewing and Evaluating
c8, c10
Performance
Fairley [3*]
2009
Sommerville 2011 McGarry et al. 20
[4*]
Boehm and Turner 2003
[7*]
[5*]
5. Closure
5.1. Determining Closure
5.2. Closure Activities
6. Software Engineering
Measurement
6.1. Establish and Sustain
c1, c2
Measurement Commitment
6.2. Plan the Measurement
c1, c2
Process
6.3. Perform the Measurement
c1, c2
Process
6.4. Evaluate Measurement c1, c2
7. Software Engineering
c5, c6, c7
Management Tools
FURTHER READINGS The PMBOK Guide provides guidelines for
managing individual projects and defines
AGuidetotheProjectManagementBodyof project management-related concepts. It also
Knowledge(PMBOKGuide) [1]. 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 [2] Project Management Institute and IEEE
project management profession. Computer Society, SoftwareExtensiontothe
PMBOKGuideFifthEdition, Project
SoftwareExtensiontotheGuidetothe Management Institute, 2013.
ProjectManagementBodyofKnowledge
(PMBOKGuide) [2]. [3*] R.E. Fairley, ManagingandLeading
SoftwareProjects, Wiley-IEEE Computer
SWX provides adaptations and extensions to the Society Press, 2009.
generic practices of project management
documented in the PMBOKGuide for [4*] I. Sommerville, SoftwareEngineering, 9th
managing software projects. The primary ed., Addison-Wesley, 2011.
contribution of this extension to the PMBOK
Guide is a description of processes that are [5*] B. Boehm and R. Turner, BalancingAgility
applicable for managing adaptive life cycle andDiscipline:AGuideforthePerplexed,
software projects. Addison-Wesley, 2003.
IEEEStandardAdoptionofISO/IEC15939 [6]. [6] IEEEStd.15939-2008StandardAdoptionof

ISO/IEC15939:2007SystemsandSoftware
This international standard identifies a process EngineeringMeasurementProcess, IEEE,
that supports defining a suitable set of measures 2008.
to address specific information needs. It
identifies the activities and tasks that are [7*] J. McGarry et al., PracticalSoftware
necessary to successfully identify, define, select, Measurement:ObjectiveInformation
apply, and improve measurement within an forDecisionMakers, Addison-Wesley
overall project or organizational measurement Professional, 2001.
structure.
[8] J. McDonald, ManagingtheDevelopmentof
J. McDonald, ManagingtheDevelopmentof SoftwareIntensiveSystems, John Wiley and
SoftwareIntensiveSystems, Wiley, 2010 [8]. Sons, Inc., 2010.
This textbook provides an introduction to

project management for beginning software and
hardware developers plus unique advanced
material for experienced project managers. Case
studies are included for planning and managing
verification and validation for large software
projects, complex software, and hardware
systems, as well as inspection results and testing
metrics to monitor project status.
REFERENCES
[1] Project Management Institute, AGuideto

the
ProjectManagementBodyofKnowledge
(PMBOK(R)Guide), 5th ed., Project
Management Institute, 2013.
CHAPTER 8 SOFTWARE ENGINEERING
PROCESS
ACRONYMS engineering processes. For readability,

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

concerned with software process definition, measurement, and software engineering process
software life cycles, software process tools.
8-1
Figure 8.1. Breakdown of Topics for the Software Engineering Process KA
1. Software Process Definition also include its entry and exit criteria and
[1*, p177] [2*, p295] [3*, p2829, p36, c5] decomposition of the work activities into tasks,
which are the smallest units of work subject to
This topic is concerned with a definition of management accountability. A process input
software process, software process may be a triggering event or the output of
management, and software process another process. Entry criteria should be
infrastructure. satisfied before a process can commence. All
As stated above, a software process is a set of specified conditions should be satisfied before a
interrelated activities and tasks that transform process can be successfully concluded,
input work products into output work products. including the acceptance criteria for the output
At minimum, the description of a software work product or work products.
process includes required inputs, transforming
work activities, and outputs generated. As
illustrated in Figure 8.2, a software process may
In addition, a software process may include

interleaved technical, collaborative, and
administrative 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 procedures; a procedure may be
specified as an ordered set of steps or,
alternatively, as a checklist of the work to be
Figure 8.2. Elements of accomplished in performing a task.
a Software Process
A software process may include subprocesses. It must be emphasized that there is no best
For example, software requirements validation software process or set of software processes.
is a process used to determine whether the Software processes must be selected, adapted,
requirements will provide an adequate basis for and applied as appropriate for each project and
software development; it is a subprocess of the each organizational context. No ideal process, or
software requirements process. Inputs for set of processes, exists.
requirements validation are typically a software
requirements specification and the resources 1.1. SoftwareProcessManagement
needed to perform validation (personnel, [3*, s26.1] [4*, p453454]
validation tools, sufficient time). The tasks of
the requirements validation activity might Two objectives of software process management
include requirements reviews, prototyping, and are to realize the efficiency and effectiveness
model validation. These tasks involve work that result from a systematic approach to
assignments for individuals and teams. The accomplishing software processes and
output of requirements validation is typically a producing work productsbe it at the
validated software requirements specification individual, project, or organizational leveland
that provides inputs to the software design and to introduce new or improved processes.
software testing processes. Requirements Processes are changed with the expectation
validation and other subprocesses of the that a new or modified process will improve the
software requirements process are often efficiency and/or effectiveness of the process
interleaved and iterated in various ways; the and the quality of the resulting work products.
software requirements process and its Changing to a new process, improving an
subprocesses may be entered and exited existing process, organizational change, and
multiple times during software development or infrastructure change (technology insertion or
modification. changes in tools) are closely related, as all are
Complete definition of a software process usually initiated with the goal of improving the
may also include the roles and competencies, IT cost, development schedule, or quality of the
support, software engineering techniques and software products. Process change has impacts
tools, and work environment needed to perform not only for the software product; they often
the process, as well as the approaches and lead to organizational change. Changing a
measures (Key Performance Indicators) used to process or introducing a new process can have
determine the efficiency and effectiveness of ripple effects throughout an organization. For
performing the process.
example, changes in IT infrastructure tools and oversee implementation and improvement of the
technology often require process changes. software processes.
Existing processes may be modified when A common misperception is that establishing
other new processes are deployed for the first a software process infrastructure and
time (for example, introducing an inspection implementing repeatable software processes will
activity within a software development project add time and cost to software development and
will likely impact the software testing process maintenance. There is a cost associated with
see Reviews and Audits in the Software Quality introducing or improving a software process;
KA and in the Software Testing KA). These however, experience has shown that
situations can also be termed process implementing systematic improvement of
evolution. If the modifications are extensive, software processes tends to result in lower cost
then changes in the organizational culture and through improved efficiency, avoidance of
business model will likely be necessary to rework, and more reliable and affordable
accommodate the process changes. software. Process performance thus influences
1.2. SoftwareProcessInfrastructure software product quality.
[2*, p183, p186] [4*, p437438]
2. Software Life Cycles
Establishing, implementing, and managing [1*, c2] [2*, p190]
software processes and software life cycle
models often occurs at the level of individual This topic addresses categories of software
software projects. However, systematic processes, software life cycle models, software
application of software processes and software process adaptation, and practical considerations.
life cycle models across an organization can A software development life cycle (SDLC)
provide benefits to all software work within the includes the software processes used to specify
organization, although it requires commitment and transform software requirements into a
at the organizational level. A software process deliverable software product. A software
infrastructure can provide process definitions, product life cycle (SPLC) includes a software
policies for interpreting and applying the development life cycle plus additional software
processes, and descriptions of the procedures to processes that provide for deployment,
be used to implement the processes. maintenance, support, evolution, retirement, and
Additionally, a software process infrastructure all other inceptionto-retirement processes for a
may provide funding, tools, training, and staff software product, including the software
members who have been assigned configuration management and software quality
responsibilities for establishing and maintaining assurance processes that are applied throughout
the software process infrastructure. a software product life cycle. A software
Software process infrastructure varies, product life cycle may include multiple software
depending on the size and complexity of the development life cycles for evolving and
organization and the projects undertaken within enhancing the software.
the organization. Small, simple organizations Individual software processes have no
and projects have small, simple infrastructure temporal ordering among them. The temporal
needs. Large, complex organizations and relationships among software processes are
projects, by necessity, have larger and more provided by a software life cycle model: either
complex software process infrastructures. In the an SDLC or SPLC. Life cycle models typically
latter case, various organizational units may be emphasize the key software processes within the
established (such as a software engineering model and their temporal and logical
process group or a steering committee) to interdependencies and relationships. Detailed
definitions of the software processes in a life 3. Organizational processes provide support

cycle model may be provided directly or by for software engineering; they include
reference to other documents. training, process measurement analysis,
In addition to conveying the temporal and infrastructure management, portfolio and
logical relationships among software processes, reuse management, organizational process
the software development life cycle model (or improvement, and management of software
models used within an organization) includes life cycle models.
the control mechanisms for applying entry and 4. Cross-projectprocesses, such as reuse,
exit criteria (e.g., project reviews, customer software product line, and domain
approvals, software testing, quality thresholds, engineering; they involve more than a
demonstrations, team consensus). The output of single software project in an organization.
one software process often provides the input
for others (e.g., software requirements provide Software processes in addition to those listed
input for a software architectural design process above include the following.
and the software construction and software Project management processes include
testing processes). Concurrent execution of processes for planning and estimating, resource
several software process activities may produce management, measuring and controlling,
a shared output (e.g., the interface specifications leading, managing risk, managing stakeholders,
for interfaces among multiple software and coordinating the primary, supporting,
components developed by different teams). organizational, and cross-project processes of
Some software processes may be regarded as software development and maintenance
less effective unless other software processes projects.
are being performed at the same time (e.g., Software processes are also developed for
software test planning during software particular needs, such as process activities that
requirements analysis can improve the software address software quality characteristics (see the
requirements). Software Quality KA). For example, security
2.1. CategoriesofSoftwareProcesses concerns during software development may
[1*, Preface] [2* , p294295] [3*, c22c24] necessitate one or more software processes to
protect the security of the development
Many distinct software processes have been environment and reduce the risk of malicious
defined for use in the various parts of the acts. Software processes may also be developed
software development and software to provide adequate grounds for establishing
maintenance life cycles. These processes can be confidence in the integrity of the software.
categorized as follows: 2.2. SoftwareLifeCycleModels
[1*, c2] [2*, s3.2] [3*, s2.1] [5]
1. Primary processes include software
processes for development, operation, and The intangible and malleable nature of software
maintenance of software. permits a wide variety of software development
2. Supporting processes are applied life cycle models, ranging from linear models in
intermittently or continuously throughout a which the phases of software development are
software product life cycle to support accomplished sequentially with feedback and
primary processes; they include software iteration as needed followed by integration,
processes such as configuration testing, and delivery of a single product; to
management, quality assurance, and iterative models in which software is developed
verification and validation. in increments of increasing functionality on
iterative cycles; to agile models that typically
involve frequent demonstrations of working an incremental software development life cycle

software to a customer or user representative model may incorporate sequential software
who directs development of the software in requirements and design phases but permit
short iterative cycles that produce small considerable flexibility in revising the software
increments of working, deliverable software. requirements and architecture during software
Incremental, iterative, and agile models can construction.
deliver early subsets of working software into
the user environment, if desired. 2.3. SoftwareProcessAdaptation
Linear SDLC models are sometimes referred [1*, s2.7] [2*, p51]
to as predictive software development life cycle
models, while iterative and agile SDLCs are Predefined SDLCs, SPLCs, and individual
referred to as adaptive software development software processes often need to be adapted (or
life cycle models. It should be noted that various tailored) to better serve local needs.
maintenance activities during an SPLC can be Organizational context, innovations in
conducted using different SDLC models, as technology, project size, product criticality,
appropriate to the maintenance activities. regulatory requirements, industry practices, and
A distinguishing feature of the various corporate culture may determine needed
software development life cycle models is the adaptations. Adaptation of individual software
way in which software requirements are processes and software life cycle models
managed. Linear development models typically (development and product) may consist of
develop a complete set of software adding more details to software processes,
requirements, to the extent possible, during activities, tasks, and procedures to address
project initiation and planning. The software critical concerns. It may consist of using an
requirements are then rigorously controlled. alternate set of activities that achieves the
Changes to the software requirements are based purpose and outcomes of the software process.
on change requests that are processed by a Adaptation may also include omitting software
change control board (see Requesting, processes or activities from a development or
Evaluating and Approving Software Changes in product life cycle model that are clearly
the Change Control Board in the Software inapplicable to the scope of work to be
Configuration Management KA). An accomplished.
incremental model produces successive
increments of working, deliverable software 2.4. PracticalConsiderations
based on partitioning of the software [2*, p188190]
requirements to be implemented in each of the
increments. The software requirements may be In practice, software processes and activities are
rigorously controlled, as in a linear model, or often interleaved, overlapped, and applied
there may be some flexibility in revising the concurrently. Software life cycle models that
software requirements as the software product specify discrete software processes, with
evolves. Agile models may define product scope rigorously specified entry and exit criteria and
and high-level features initially; however, agile prescribed boundaries and interfaces, should be
models are designed to facilitate evolution of recognized as idealizations that must be adapted
the software requirements during the project. to reflect the realities of software development
It must be emphasized that the continuum of and maintenance within the organizational
SDLCs from linear to agile is not a thin, straight context and business environment.
line. Elements of different approaches may be Another practical consideration: software
incorporated into a specific model; for example, processes (such as configuration management,
construction, and testing) can be adapted to exit criteria are being met, to review risk factors
facilitate operation, support, maintenance, and risk management, or to identify lessons
migration, and retirement of the software. learned. Process assessment is carried out using
Additional factors to be considered when both an assessment model and an assessment
defining and tailoring a software life cycle method. The model can provide a norm for a
model include required conformance to benchmarking comparison among projects
standards, directives, and policies; customer within an organization and among
demands; criticality of the software product; and organizations.
organizational maturity and competencies. Other A process audit differs from a process
factors include the nature of the work (e.g., assessment. Assessments are performed to
modification of existing software versus new determine levels of capability or maturity and to
development) and the application domain (e.g., identify software processes to be improved.
aerospace versus hotel management). Audits are typically conducted to ascertain
compliance with policies and standards. Audits
3. Software Process Assessment and provide management visibility into the actual
Improvement operations being performed in the organization
[2*, p188, p194] [3*, c26] [4*, p397, c15] so that accurate and meaningful decisions can
be made concerning issues that are impacting a
This topic addresses software process development project, a maintenance activity, or
assessment models, software process a software-related topic.
assessment methods, software process Success factors for software process
improvement models, and continuous and assessment and improvement within software
staged process ratings. Software process engineering organizations include management
assessments are used to evaluate the form and sponsorship, planning, training, experienced and
content of a software process, which may be capable leaders, team commitment, expectation
specified by a standardized set of criteria. In management, the use of change agents, plus
some instances, the terms process appraisal pilot projects and experimentation with tools.
and capability evaluation are used instead of Additional factors include independence of the
process assessment. Capability evaluations are assessor and the timeliness of the assessment.
typically performed by an acquirer (or potential
acquirer) or by an external agent on behalf of an 3.1. SoftwareProcessAssessmentModels
acquirer (or potential acquirer). The results are [2*, s4.5, s4.6] [3*, s26.5] [4*, p4448]
used as an indicator of whether the software
processes used by a supplier (or potential Software process assessment models typically
supplier) are acceptable to the acquirer. include assessment criteria for software
Performance appraisals are typically performed processes that are regarded as constituting good
within an organization to identify software practices. These practices may address software
processes in need of improvement or to development processes only, or they may also
determine whether a process (or processes) include topics such as software maintenance,
satisfies the criteria at a given level of process software project management, systems
capability or maturity. engineering, or human resources management.
Process assessments are performed at the
levels of entire organizations, organizational 3.2. SoftwareProcessAssessmentMethods
units within organizations, and individual [1*, p322331] [3*, s26.3]
projects. Assessment may involve issues such as [4*, p4448, s16.4] [6]
assessing whether software process entry and
A software process assessment method can be 3.3. SoftwareProcessImprovementModels

qualitative or quantitative. Qualitative [2*, p187188] [3*, s26.5] [4*, s2.7]
assessments rely on the judgment of experts;
quantitative assessments assign numerical Software process improvement models
scores to software processes based on analysis emphasize iterative cycles of continuous
of objective evidence that indicates attainment improvement. A software process improvement
of the goals and outcomes of a defined software cycle typically involves the subprocesses of
process. For example, a quantitative assessment measuring, analyzing, and changing. The Plan-
of the software inspection process might be Do-Check-Act model is a well-known iterative
performed by examining the procedural steps approach to software process improvement.
followed and results obtained plus data Improvement activities include identifying and
concerning defects found and time required to prioritizing desired improvements (planning);
find and fix the defects as compared to software introducing an improvement, including change
testing. management and training (doing); evaluating
A typical method of software process the improvement as compared to previous or
assessment includes planning, fact-finding (by exemplary process results and costs (checking);
collecting evidence through questionnaires, and making further modifications (acting). The
interviews, and observation of work practices), Plan-Do-Check-Act process improvement
collection and validation of process data, and model can be applied, for example, to improve
analysis and reporting. Process assessments may software processes that enhance defect
rely on the subjective, qualitative judgment of prevention.
the assessor, or on the objective presence or
absence of defined artifacts, records, and other 3.4. ContinuousandStagedSoftwareProcess
evidence. Ratings
The activities performed during a software [1*, p2834] [3*, s26.5] [4*, p3945]
process assessment and the distribution of effort
for assessment activities are different depending Software process capability and software
on the purpose of the software process process maturity are typically rated using five or
assessment. Software process assessments may six levels to characterize the capability or
be undertaken to develop capability ratings used maturity of the software processes used within
to make recommendations for process an organization.
improvements or may be undertaken to obtain a A continuous rating system involves assigning
process maturity rating in order to qualify for a a rating to each software process of interest; a
contract or award. staged rating system is established by assigning
The quality of assessment results depends on the same maturity rating to all of the software
the software process assessment method, the processes within a specified process level. A
integrity and quality of the obtained data, the representation of continuous and staged process
assessment teams capability and objectivity, levels is provided in Table 8.1. Continuous
and the evidence examined during the models typically use a level 0 rating; staged
assessment. The goal of a software process models typically do not.
assessment is to gain insight that will establish Table 8.1. Software Process Rating Levels
the current status of a process or processes and Continuous Staged
provide a basis for process improvement; Representation Representation
performing a software process assessment by Level
of Capability of Maturity
following a checklist for conformance without Levels Levels
gaining insight adds little value.
0 Incomplete accomplished for that maturity level, which

provides a foundation for improving all of the
1 Performed Initial software processes at the next higher level.
2 Managed Managed
3 Defined Defined 4.Software Measurement
[3*, s26.2] [4*, s18.1.1]
Quantitatively
4
Managed This topic addresses software process and
5 Optimizing product measurement, quality of measurement
In Table 8.1, level 0 indicates that a software results, software information models, and
process is incompletely performed or may not software process measurement techniques (see
be performed. At level 1, a software process is Measurement in the Engineering Foundations
being performed (capability rating), or the KA).
software processes in a maturity level 1 group Before a new process is implemented or a
are being performed but on an ad hoc, informal current process is modified, measurement
basis. At level 2, a software process (capability results for the current situation should be
rating) or the processes in maturity level 2 are obtained to provide a baseline for comparison
being performed in a manner that provides between the current situation and the new
management visibility into intermediate work situation. For example, before introducing the
products and can exert some control over software inspection process, effort required to
transitions between processes. At level 3, a fix defects discovered by testing should be
single software process or the processes in a measured. Following an initial start-up period
maturity level 3 group plus the process or after the inspection process is introduced, the
processes in maturity level 2 are well defined combined effort of inspection plus testing can be
(perhaps in organizational policies and compared to the previous amount of effort
procedures) and are being repeated across required for testing alone. Similar
different projects. Level 3 of process capability considerations apply if a process is changed.
or maturity provides the basis for process
improvement across an organization because the 4.1. SoftwareProcessandProduct
process is (or processes are) conducted in a Measurement[1*, s6.3, p273]
similar manner. This allows collection of [3*, s26.2, p638]
performance data in a uniform manner across
multiple projects. At maturity level 4, Software process and product measurement are
quantitative measures can be applied and used concerned with determining the efficiency and
for process assessment; statistical analysis may effectiveness of a software process, activity, or
be used. At maturity level 5, the mechanisms for task. The efficiency of a software process,
continuous process improvements are applied. activity, or task is the ratio of resources actually
Continuous and staged representations can be consumed to resources expected or desired to be
used to determine the order in which software consumed in accomplishing a software process,
processes are to be improved. In the continuous activity, or task (see Efficiency in the Software
representation, the different capability levels for Engineering Economics KA). Effort (or
different software processes provide a guideline equivalent cost) is the primary measure of
for determining the order in which software resources for most software processes,
processes will be improved. In the staged activities, and tasks; it is measured in units such
representation, satisfying the goals of a set of as person-hours, person-days, staffweeks, or
software processes within a maturity level is
staff-months of effort or in equivalent monetary Causes of low efficiency and/or low

unitssuch as euros or dollars. effectiveness in the way a software process,
Effectiveness is the ratio of actual output to activity, or task is executed might include one or
expected output produced by a software process, more of the following problems: deficient input
activity, or task; for example, actual number of work products, inexperienced personnel, lack of
defects detected and corrected during software adequate tools and infrastructure, learning a new
testing to expected number of defects to be process, a complex product, or an unfamiliar
detected and correctedperhaps based on product domain. The efficiency and
historical data for similar projects (see effectiveness of software process execution are
Effectiveness in the Software Engineering also affected (either positively or negatively) by
Economics KA). Note that measurement of factors such as turnover in software personnel,
software process effectiveness requires schedule changes, a new customer
measurement of the relevant product attributes; representative, or a new organizational policy.
for example, measurement of software defects In software engineering, productivity in
discovered and corrected during software performing a process, activity, or task is the
testing. ratio of output produced divided by resources
One must take care when measuring product consumed; for example, the number of software
attributes for the purpose of determining process defects discovered and corrected divided by
effectiveness. For example, the number of person-hours of effort (see Productivity in the
defects detected and corrected by testing may Software Engineering Economics KA).
not achieve the expected number of defects and Accurate measurement of productivity must
thus provide a misleadingly low effectiveness include total effort used to satisfy the exit
measure, either because the software being criteria of a software process, activity, or task;
tested is of betterthan-usual quality or perhaps for example, the effort required to correct
because introduction of a newly introduced defects discovered during software testing must
upstream inspection process has reduced the be included in software development
remaining number of defects in the software. productivity.
Product measures that may be important in Calculation of productivity must account for
determining the effectiveness of software the context in which the work is accomplished.
processes include product complexity, total For example, the effort to correct discovered
defects, defect density, and the quality of defects will be included in the productivity
requirements, design documentation, and other calculation of a software team if team members
related work products. correct the defects they findas in unit testing
Also note that efficiency and effectiveness are by software developers or in a cross-functional
independent concepts. An effective software agile team. Or the productivity calculation may
process can be inefficient in achieving a desired include either the effort of the software
software process result; for example, the amount developers or the effort of an independent
of effort expended to find and fix software testing team, depending on who fixes the defects
defects could be very high and result in low found by the independent testers. Note that this
efficiency, as compared to expectations. example refers to the effort of teams of
An efficient process can be ineffective in developers or teams of testers and not to
accomplishing the desired transformation of individuals. Software productivity calculated at
input work products into output work products; the level of individuals can be misleading
for example, failure to find and correct a because of the many factors that can affect the
sufficient number of software defects during the individual productivity of software engineers.
testing process.
Standardized definitions and counting rules product improvement goals. Needed data can be
for measurement of software processes and collected and retained in a repository; the data
work products are necessary to provide can be analyzed and models can be constructed.
standardized measurement results across Validation and refinement of software
projects within an organization, to populate a information models occur during software
repository of historical data that can be analyzed projects and after projects are completed to
to identify software processes that need to be ensure that the level of accuracy is sufficient
improved, and to build predictive models based and that their limitations are known and
on accumulated data. In the example above, understood. Software information models may
definitions of software defects and staff-hours of also be developed for contexts other than
testing effort plus counting rules for defects and software projects; for example, a software
effort would be necessary to obtain satisfactory information model might be developed for
measurement results. processes that apply across an organization,
The extent to which the software process is such as software configuration management or
institutionalized is important; failure to software quality assurance processes at the
institutionalize a software process may explain organizational level.
why good software processes do not always Analysis-driven software information model
produce anticipated results. Software processes building involves the development, calibration,
may be institutionalized by adoption within the and evaluation of a model. A software
local organizational unit or across larger units of information model is developed by establishing
an enterprise. a hypothesized transformation of input variables
into desired outputs; for example, product size
4.2. QualityofMeasurementResults and complexity might be transformed into
[4*, s3.43.7] estimated effort needed to develop a software
product using a regression equation developed
The quality of process and product measurement from observed data from past projects. A model
results is primarily determined by the reliability is calibrated by adjusting parameters in the
and validity of the measured results. model to match observed results from past
Measurements that do not satisfy these quality projects; for example, the exponent in a
criteria can result in incorrect interpretations nonlinear regression model might be changed by
and faulty software process improvement applying the regression equation to a different
initiatives. Other desirable properties of set of past projects other than the projects used
software measurements include ease of to develop the model.
collection, analysis, and presentation plus a A model is evaluated by comparing computed
strong correlation between cause and effect. results to actual outcomes for a different set of
The Software Engineering Measurement topic similar data. There are three possible evaluation
in the Software Engineering Management KA outcomes:
describes a process for implementing a software
measurement program. 1. results computed for a different data set
4.3. SoftwareInformationModels vary widely from actual outcomes for that
[1*, p310311] [3*, p712713] [4*, s19.2] data set, in which case the derived model is
not applicable for the new data set and
Software information models allow modeling, should not be applied to analyze or make
analysis, and prediction of software process and predictions
software product attributes to provide answers for future projects;
to relevant questions and achieve process and
2. results computed for a new data set are activities that are candidates for improvement.
close to actual outcomes for that data set, in In some cases, new software processes may be
which case minor adjustments are made to needed.
the parameters of the model to improve Process measurement techniques also provide
agreement; the information needed to measure the effects of
3. results computed for the new data set and process improvement initiatives. Process
subsequent data sets are very close and no measurement techniques can be used to collect
adjustments to the model are needed. both quantitative and qualitative data.
Continuous evaluation of the model may 4.4.1. QuantitativeProcessMeasurement

indicate a need for adjustments over time as the Techniques
context in which the model is applied changes. [4*, s5.1, s5.7, s9.8]
The Goals/Questions/Metrics (GQM) method
was originally intended for establishing The purpose of quantitative process
measurement activities, but it can also be used measurement techniques is to collect, transform,
to guide analysis and improvement of software and analyze quantitative process and work
processes. product data that can be used to indicate where
It can be used to guide analysis-driven process improvements are needed and to assess
software information model building; results the results of process improvement initiatives.
obtained from the software information model Quantitative process measurement techniques
can be used to guide process improvement. are used to collect and analyze data in numerical
The following example illustrates application form to which mathematical and statistical
of the GQM method: techniques can be applied.
Quantitative process data can be collected as a
Goal: Reduce the average change request byproduct of software processes. For example,
processing time by 10% within six months. the number of defects discovered during
Question 1-1: What is the baseline change software testing and the staff-hours expended
request processing time? can be collected by direct measurement, and the
Metric 1-1-1: Average of change request productivity of defect discovery can be derived
processing times on starting date by calculating defects discovered per staff-hour.
Metric 1-1-2: Standard deviation of change Basic tools for quality control can be used to
request processing times on starting date analyze quantitative process measurement data
Question 1-2: What is the current change (e.g., check sheets, Pareto diagrams, histograms,
request processing time? scatter diagrams, run charts, control charts, and
Metric 1-2-1: Average of change request cause-and-effect diagrams) (see Root Cause
processing times currently Analysis in the Engineering Foundations KA).
Metric 1-2-2: Standard deviation of change In addition, various statistical techniques can be
request processing times currently used that range from calculation of medians and
means to multivariate analysis methods (see
4.4. SoftwareProcessMeasurementTechniques Statistical Analysis in the Engineering
[1*, c8] Foundations KA).
Data collected using quantitative process
Software process measurement techniques are measurement techniques can also be used as
used to collect process data and work product inputs to simulation models (see Modeling,
data, transform the data into useful information, Prototyping, and Simulation in the Engineering
and analyze the information to identify process Foundations KA); these models can be used to
assess the impact of various approaches to process tools allow different types of analyses
software process improvement. and simulations (for example, discrete event
Orthogonal Defect Classification (ODC) can simulation). In addition, general purpose
be used to analyze quantitative process business tools, such as a spreadsheet, may be
measurement data. ODC can be used to group useful.
detected defects into categories and link the Computer-Assisted Software Engineering
defects in each category to the software process (CASE) tools can reinforce the use of integrated
or software processes where a group of defects processes, support the execution of process
originated (see Defect Characterization in the definitions, and provide guidance to humans in
Software Quality KA). Software interface performing well-defined processes. Simple tools
defects, for example, may have originated such as word processors and spreadsheets can
during an inadequate software design process; be used to prepare textual descriptions of
improving the software design process will processes, activities, and tasks; these tools also
reduce the number of software interface defects. support traceability among the inputs and
ODC can provide quantitative data for applying outputs of multiple software processes (such as
root cause analysis. stakeholder needs analysis, software
Statistical Process Control can be used to requirements specification, software
track process stability, or the lack of process architecture, and software detailed design) as
stability, using control charts. well as the results of software processes such as
documentation, software components, test cases,
4.4.2. QualitativeProcessMeasurement and problem reports.
Techniques Most of the knowledge areas in this Guide
[1*, s6.4] describe specialized tools that can be used to
manage the processes within that KA. In
Qualitative process measurement techniques particular, see the Software Configuration
including interviews, questionnaires, and expert Management KA for a discussion of software
judgmentcan be used to augment quantitative configuration management tools that can be
process measurement techniques. Group used to manage the construction, integration,
consensus techniques, including the Delphi and release processes for software products.
technique, can be used to obtain consensus Other tools, such as those for requirements
among groups of stakeholders. management and testing, are described in the
appropriate KAs.
5. Software Engineering Process Tools Software process tools can support projects
[1*, s8.7] that involve geographically dispersed (virtual)
teams. Increasingly, software process tools are
Software process tools support many of the available through cloud computing facilities as
notations used to define, implement, and well as through dedicated infrastructures.
manage individual software processes and A project control panel or dashboard can
software life cycle models. They include editors display selected process and product attributes
for notations such as data-flow diagrams, state for software projects and indicate measurements
charts, BPMN, IDEF0 diagrams, Petri nets, and that are within control limits and those needing
UML activity diagrams. In some cases, software corrective action.
Kan 2003
[4*]
Fairley [1*]
2009
Moore 2009
[2*]
Sommerville 2011
[3*]
p2829,
1. Software Process Definition p177 p295 p36,
c5
1.1. Software Process Management s26.1 p453454
p183,
1.2. Software Process Infrastructure p437438
p186
2. Software Life Cycles c2 p190
c22, c23,
2.1. Categories of Software Processes preface p294295
c24
2.2. Software Life Cycle Models c2 s3.2 s2.1
2.3. Software Process Adaptation s2.7 p51
2.4. Practical Considerations p188190
3. Software Process Assessment and p188,
c26 p397, c15
Improvement p194
3.1. Software Process Assessment s4.5,
s26.5 p4448
Models s4.6
3.2. Software Process Assessment p4448,
p322331 s26.3
Methods s16.4
3.3. Software Process Improvement
p187188 s26.5 s2.7
Models
3.4. Continuous and Staged Ratings p2834 s26.5 p3945
4. Software Measurement s26.2 s18.1.1
4.1. Software Process and Product s6.3, s26.2,
Measurement p273 p638
s3.4,
s3.5,
4.2. Quality of Measurement Results
s3.6,
s3.7
4.3. Software Information Models p310311 p. 712 s19.2
713
s5.1,
4.4. Software Process Measurement s6.4,
s5.7,
Techniques c8
s9.8
5. Software Engineering Process Tools s8.7
FURTHER READINGS ISO/IEC15504-1:2004Informationtechnology
ProcessassessmentPart1:Concepts
SoftwareExtensiontotheGuidetotheProject andvocabulary [8].
ManagementBodyofKnowledge (SWX)
[5]. This standard, commonly known as SPICE
(Software Process Improvement and Capability
SWX provides adaptations and extensions to the Determination), includes multiple parts. Part 1
generic practices of project management provides concepts and vocabulary for software
documented in the PMBOK Guide for development processes and related
managing software projects. The primary businessmanagement functions. Other parts of
contribution of this extension to the PMBOK 15504 define the requirements and procedures
Guideis description of processes that are for performing process assessments.
applicable for managing adaptive life cycle REFERENCES
software projects.
[1*] R.E. Fairley, ManagingandLeading
D. Gibson, D. Goldenson, and K. Kost, SoftwareProjects, Wiley-IEEE Computer
Performance Results of CMMI-Based Society Press, 2009.
Process Improvement [6].
[2*] J.W. Moore, TheRoadMaptoSoftware
This technical report summarizes publicly Engineering:AStandards-BasedGuide,
available empirical evidence about the Wiley-IEEE Computer Society Press, 2006.
performance results that can occur as a
consequence of CMMIbased process [3*] I. Sommerville, SoftwareEngineering, 9th
improvement. The report contains a series of ed., Addison-Wesley, 2011.
brief case descriptions that were created with
collaboration from representatives from 10 [4*] S.H. Kan, MetricsandModelsinSoftware
organizations that have achieved notable QualityEngineering, 2nd ed.,
quantitative performance results through their
CMMI-based improvement efforts.
[5] Project Management Institute and IEEE
CMMI forDevelopment,Version1.3 [7].
Computer Society, SoftwareExtensionto
thePMBOKGuideFifthEdition, ed:
CMMIforDevelopment,Version1.3 provides Project Management Institute, 2013.
an integrated set of process guidelines for
[6] D. Gibson, D. Goldenson, and K. Kost,
developing and improving products and
Performance Results of CMMI-Based
services. These guidelines include best practices
Process Improvement, Software
for developing and improving products and
Engineering Institute, 2006; http://
services to meet the needs of customers and end
resources.sei.cmu.edu/library/asset-view.
users.
cfm?assetID=8065.
[7] CMMI Product Team, CMMI for

Development, Version 1.3, Software [8] ISO/IEC15504-1:2004,Information

Engineering Institute, 2010; http:// TechnologyProcessAssessmentPart1:
resources.sei.cmu.edu/library/asset-view. ConceptsandVocabulary, ISO/IEC, 2004.
cfm?assetID=9661.
CHAPTER 9
SOFTWARE ENGINEERING MODELS AND

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

technique to help software engineers
understand,
9-1
Figure 9.1. Breakdown of Topics for the Software Engineering Models and Methods KA
engineer, and communicate aspects of the [1*, c2s2, c5s1, c5s2] [2*, c2s2] [3*, c5s0]
software to appropriate stakeholders.
Stakeholders are those persons or parties who Modeling provides the software engineer with
have a stated or implied interest in the software an organized and systematic approach for
(for example, user, buyer, supplier, architect, representing significant aspects of the software
certifying authority, evaluator, developer, under study, facilitating decision-making about
software engineer, and perhaps others). the software or elements of it, and
While there are many modeling languages, communicating those significant decisions to
notations, techniques, and tools in the literature others in the stakeholder communities. There
and in practice, there are unifying general are three general principles guiding such
concepts that apply in some form to them all. modeling activities:
The following sections provide background on
these general concepts. Model the Essentials: good models do not
usually represent every aspect or feature of
1.1. ModelingPrinciples the software under every possible condition.
Modeling typically involves developing A model is an abstraction or simplification of

only those aspects or features of the a software component. A consequence of using
software that need specific answers, abstraction is that no single abstraction
abstracting away any nonessential completely describes a software component.
information. This approach keeps the Rather, the model of the software is represented
models manageable and useful. as an aggregation of abstractions, whichwhen
Provide Perspective: modeling provides taken togetherdescribe only selected aspects,
views of the software under study using a perspectives, or viewsonly those that are
defined set of rules for expression of the needed to make informed decisions and respond
model within each view. This to the reasons for creating the model in the first
perspectivedriven approach provides place. This simplification leads to a set of
dimensionality to the model (for example, a assumptions about the context within which the
structural view, behavioral view, temporal model is placed that should also be captured in
view, organizational view, and other views the model. Then, when reusing the model, these
as relevant). Organizing information into assumptions can be validated first to establish
views focuses the software modeling efforts the relevancy of the reused model within its new
on specific concerns relevant to that view use and context.
using the appropriate notation, vocabulary,
methods, and tools. 1.2. PropertiesandExpressionofModels
EnableEffectiveCommunications: [1*, c5s2, c5s3] [3*, c4s1.1p7, c4s6p3,
modeling employs the application domain c5s0p3]
vocabulary of the software, a modeling
language, and semantic expression (in other Properties of models are those distinguishing
words, meaning within context). When used features of a particular model used to
rigorously and systematically, this modeling characterize its completeness, consistency, and
results in a reporting approach that correctness within the chosen modeling notation
facilitates effective communication of and tooling used. Properties of models include
software information to project the following:
stakeholders.
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,
assertions, constraints, functions, or
component descriptions.
Correctness: the degree to which the model
satisfies its requirements and design
specifications 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 being relative to the modeling effort) may be a
questions regarding the requirements, design, union of multiple submodels and any special
and/or implementation can then be handled function models. Examination and decision-
appropriately. making relative to a single model within this
The primary expression element of a model is collection of submodels may be problematic.
an entity. An entity may represent concrete Understanding the precise meanings of
artifacts (for example, processors, sensors, or modeling constructs can also be difficult.
robots) or abstract artifacts (for example, Modeling languages are defined by syntactic
software modules or communication protocols). and semantic rules. For textual languages,
Model entities are connected to other entities syntax is defined using a notation grammar that
using relations (in other words, lines or textual defines valid language constructs (for example,
operators on target entities). Expression of Backus-Naur Form (BNF)). For graphical
model entities may be accomplished using languages, syntax is defined using graphical
textual or graphical modeling languages; both models called metamodels. As with BNF,
modeling language types connect model entities metamodels define the valid syntactical
through specific language constructs. The constructs of a graphical modeling language; the
meaning of an entity may be represented by its metamodel defines how these constructs can be
shape, textual attributes, or both. Generally, composed to produce valid models.
textual information adheres to language-specific Semantics for modeling languages specify the
syntactic structure. The precise meanings related meaning attached to the entities and relations
to the modeling of context, structure, or captured within the model. For example, a
behavior using these entities and relations is simple diagram of two boxes connected by a
dependent on the modeling language used, the line is open to a variety of interpretations.
design rigor applied to the modeling effort, the Knowing that the diagram on which the boxes
specific view being constructed, and the entity are placed and connected is an object diagram or
to which the specific notation element may be an activity diagram can assist in the
attached. Multiple views of the model may be interpretation of this model.
required to capture the needed semantics of the As a practical matter, there is usually a good
software. understanding of the semantics of a specific
When using models supported with software model due to the modeling language
automation, models may be checked for selected, how that modeling language is used to
completeness and consistency. The usefulness of express entities and relations within that model,
these checks depends greatly on the level of the experience base of the modeler(s), and the
semantic and syntactic rigor applied to the context within which the modeling has been
modeling effort in addition to explicit tool undertaken and so represented. Meaning is
support. Correctness is typically checked communicated through the model even in the
through simulation and/or review. presence of incomplete information through
abstraction; pragmatics explains how meaning is
1.3. Syntax,Semantics,andPragmatics embodied in the model and its context and
[2* c2s2.2.2p6] [3*, c5s0] communicated effectively to other software
engineers.
Models can be surprisingly deceptive. The fact There are still instances, however, where
that a model is an abstraction with missing caution is needed regarding modeling and
information can lead one into a false sense of semantics. For example, any model parts
completely understanding the software from a imported from another model or library must be
single model. A complete model (complete examined for semantic assumptions that conflict
in the new modeling environment; this may not other words, do not change) before and after
be obvious. The model should be checked for execution of the function or method. These
documented assumptions. While modeling invariants are relevant and necessary to the
syntax may be identical, the model may mean software and the correct operation of the
something quite different in the new function or method.
environment, which is a different context. Also,
consider that as software matures and changes 2. Types of Models
are made, semantic discord can be introduced,
leading to errors. With many software engineers A typical model consists of an aggregation of
working on a model part over time coupled with submodels. Each submodel is a partial
tool updates and perhaps new requirements, description and is created for a specific purpose;
there are opportunities for portions of the model it may be comprised of one or more diagrams.
to represent something different from the The collection of submodels may employ
original authors intent and initial model multiple modeling languages or a single
context. modeling language. The Unified Modeling
Language (UML) recognizes a rich collection of
1.4. Preconditions,Postconditions,and modeling diagrams. Use of these diagrams,
Invariants along with the modeling language constructs,
[2*, c4s4] [4*, c10s4p2, c10s5p2p4] brings about three broad model types commonly
used: information models, behavioral models,
When modeling functions or methods, the and structure models (see section 1.1).
software engineer typically starts with a set of
assumptions about the state of the software prior 2.1. InformationModeling
to, during, and after the function or method [1*, c7s2.2] [3*, c8s1]
executes. These assumptions are essential to the
correct operation of the function or method and Information models provide a central focus on
are grouped, for discussion, as a set of data and information. An information model is
preconditions, postconditions, and invariants. an abstract representation that identifies and
defines a set of concepts, properties, relations,
Preconditions: a set of conditions that must and constraints on data entities. The semantic or
be satisfied prior to execution of the conceptual information model is often used to
function or method. If these preconditions provide some formalism and context to the
do not hold prior to execution of the software being modeled as viewed from the
function or method, the function or method problem perspective, without concern for how
may produce erroneous results. this model is actually mapped to the
Postconditions: a set of conditions that is implementation of the software. The semantic or
guaranteed to be true after the function or conceptual information model is an abstraction
method has executed successfully. and, as such, includes only the concepts,
Typically, the postconditions represent how properties, relations, and constraints needed to
the state of the software has changed, how conceptualize the real-world view of the
parameters passed to the function or method information. Subsequent transformations of the
have changed, how data values have semantic or conceptual information model lead
changed, or how the return value has been to the elaboration of logical and then physical
affected. data models as implemented in the software.
Invariants: a set of conditions within the
operational environment that persist (in 2.2. BehavioralModeling
[1*, c7s2.1, c7s2.3, c7s2.4] [2*, c9s2] correct enough to serve their intended purpose
[3*, c5s4] for the stakeholders.
The sections that follow briefly describe the
Behavioral models identify and define the analysis techniques generally used with
functions of the software being modeled. software models to ensure that the software
Behavioral models generally take three basic engineer and other relevant stakeholders gain
forms: state machines, control-flow models, and appropriate value from the development and use
dataflow models. State machines provide a of models.
model of the software as a collection of defined
states, events, and transitions. The software 3.1. AnalyzingforCompleteness
transitions from one state to the next by way of [3*, c4s1.1p7, c4s6] [5*, p811]
a guarded or unguarded triggering event that
occurs in the modeled environment. Control- In order to have software that fully meets the
flow models depict how a sequence of events needs of the stakeholders, completeness is
causes processes to be activated or deactivated. criticalfrom the requirements elicitation
Data-flow behavior is typified as a sequence of process to code implementation. Completeness
steps where data moves through processes is the degree to which all of the specified
toward data stores or data sinks. requirements have been implemented and
2.3. StructureModeling verified. Models may be checked for
[1*, c7s2.5, c7s3.1, c7s3.2] [3*, c5s3] [4*, c4] completeness by a modeling tool that uses
techniques such as structural analysis and state-
Structure models illustrate the physical or space reachability analysis (which ensure that
logical composition of software from its various all paths in the state models are reached by
component parts. Structure modeling establishes some set of correct inputs); models may also be
the defined boundary between the software checked for completeness manually by using
being implemented or modeled and the inspections or other review techniques (see the
environment in which it is to operate. Some Software Quality KA). Errors and warnings
common structural constructs used in structure generated by these analysis tools and found by
modeling are composition, decomposition, inspection or review indicate probable needed
generalization, and specialization of entities; corrective actions to ensure completeness of the
identification of relevant relations and models.
cardinality between entities; and the definition
of process or functional interfaces. Structure 3.2. AnalyzingforConsistency
diagrams provided by the UML for structure [3*, c4s1.1p7, c4s6] [5*, p811]
modeling include class, component, object,
deployment, and packaging diagrams. Consistency is the degree to which models
contain no conflicting requirements, assertions,
3.Analysis of Models constraints, functions, or component
descriptions. Typically, consistency checking is
The development of models affords the software accomplished with the modeling tool using an
engineer an opportunity to study, reason about, automated analysis function; models may also
and understand the structure, function, be checked for consistency manually using
operational usage, and assembly considerations inspections or other review techniques (see the
associated with software. Analysis of Software Quality KA). As with completeness,
constructed models is needed to ensure that errors and warnings generated by these analysis
these models are complete, consistent, and
tools and found by inspection or review indicate improves the management of software work
the need for corrective action. products and software process quality; it also
provides assurances to stakeholders that all
3.3. AnalyzingforCorrectness requirements have been satisfied. Traceability
[5*, p811] enables change analysis once the software is
developed and released, since relationships to
Correctness is the degree to which a model software work products can easily be traversed
satisfies its software requirements and software to assess change impact. Modeling tools
design specifications, is free of defects, and typically provide some automated or manual
ultimately meets the stakeholders needs. means to specify and manage traceability links
Analyzing for correctness includes verifying between requirements, design, code, and/or test
syntactic correctness of the model (that is, entities as may be represented in the models and
correct use of the modeling language grammar other software work products. (For more
and constructs) and verifying semantic information on traceability, see the Software
correctness of the model (that is, use of the Configuration Management KA).
modeling language constructs to correctly
represent the meaning of that which is being 3.5. InteractionAnalysis
modeled). To analyze a model for syntactic and [2*, c10, c11] [3*, c29s1.1, c29s5] [4*, c5]
semantic correctness, one analyzes iteither
automatically (for example, using the modeling Interaction analysis focuses on the
tool to check for model syntactic correctness) or communications or control flow relations
manually (using inspections or other review between entities used to accomplish a specific
techniques)searching for possible defects and task or function within the software model. This
then removing or repairing the confirmed analysis examines the dynamic behavior of the
defects before the software is released for use. interactions between different portions of the
software model, including other software layers
3.4. Traceability (such as the operating system, middleware, and
[3*, c4s7.1, c4s7.2] applications). It may also be important for some
software applications to examine interactions
Developing software typically involves the use, between the computer software application and
creation, and modification of many work the user interface software. Some software
products such as planning documents, process modeling environments provide simulation
specifications, software requirements, diagrams, facilities to study aspects of the dynamic
designs and pseudo-code, handwritten and tool- behavior of modeled software. Stepping through
generated code, manual and automated test the simulation provides an analysis option for
cases and reports, and files and data. These the software engineer to review the interaction
work products may be related through various design and verify that the different parts of the
dependency relationships (for example, uses, software work together to provide the intended
implements, and tests). As software is being functions.
developed, managed, maintained, or extended, 4.Software Engineering Methods
there is a need to map and control these
traceability relationships to demonstrate Software engineering methods provide an
software requirements consistency with the organized and systematic approach to
software model (see Requirements Tracing in developing software for a target computer.
the Software Requirements KA) and the many There are numerous methods from which to
work products. Use of traceability typically choose, and it is important for the software
engineer to choose an appropriate method or supporting database designs or data

methods for the software development task at repositories typically found in business
hand; this choice can have a dramatic effect on software, where data is actively managed as
the success of the software project. Use of these a business systems resource or asset.
software engineering methods coupled with Object-OrientedAnalysisandDesign
people of the right skill set and tools enable the Methods: The object-oriented model is
software engineers to visualize the details of the represented as a collection of objects that
software and ultimately transform the encapsulate data and relationships and
representation into a working set of code and interact with other objects through methods.
data. Objects may be real-world items or virtual
Selected software engineering methods are items. The software model is constructed
discussed below. The topic areas are organized using diagrams to constitute selected views
into discussions of Heuristic Methods, Formal of the software. Progressive refinement of
Methods, Prototyping Methods, and Agile the software models leads to a detailed
Methods. design. The detailed design is then either
evolved through successive iteration or
4.1. HeuristicMethods transformed (using some mechanism) into
[1*, c13, c15, c16] [3*, c2s2.2, c5s4.1, c7s1,] the implementation view of the model,
where the code and packaging approach for
Heuristic methods are those experience-based eventual software product release and
software engineering methods that have been deployment is expressed.
and are fairly widely practiced in the software
industry. This topic area contains three broad 4.2. FormalMethods
discussion categories: structured analysis and [1*, c18] [3*, c27] [5*, p824]
design methods, data modeling methods, and
objectoriented analysis and design methods. Formal methods are software engineering
methods used to specify, develop, and verify the
Structured Analysis and Design Methods: software through application of a rigorous
The software model is developed primarily mathematically based notation and language.
from a functional or behavioral viewpoint, Through use of a specification language, the
starting from a high-level view of the software model can be checked for consistency
software (including data and control (in other words, lack of ambiguity),
elements) and then progressively completeness, and correctness in a systematic
decomposing or refining the model and automated or semi-automated fashion. This
components through increasingly detailed topic is related to the Formal Analysis section in
designs. The detailed design eventually the Software Requirements KA.
converges to very specific details or This section addresses specification
specifications of the software that must be languages, program refinement and derivation,
coded (by hand, automatically generated, or formal verification, and logical inference.
both), built, tested, and verified.
DataModelingMethods: The data model is Specification Languages: Specification
constructed from the viewpoint of the data languages provide the mathematical basis
or information used. Data tables and for a formal method; specification
relationships define the data models. This languages are formal, higher level computer
data modeling method is used primarily for languages (in other words, not a classic 3rd
defining and analyzing data requirements Generation Language (3GL) programming
language) used during the software developing the proof that those
specification, requirements analysis, and/ or preconditions and postconditions must hold
design stages to describe specific input/ under all inputs. This provides a way for the
output behavior. Specification languages are software engineer to predict software
not directly executable languages; they are behavior without having to execute the
typically comprised of a notation and software. Some Integrated Development
syntax, semantics for use of the notation, Environments (IDEs) include ways to
and a set of allowed relations for objects. represent these proofs along with the design
Program Refinement and Derivation: or code.
Program refinement is the process of 4.3. PrototypingMethods
creating a lower level (or more detailed) [1*, c12s2] [3*, c2s3.1] [6*, c7s3p5]
specification using a series of
transformations. It is through successive Software prototyping is an activity that
transformations that the software engineer generally creates incomplete or minimally
derives an executable representation of a functional versions of a software application,
program. Specifications may be refined, usually for trying out specific new features,
adding details until the model can be soliciting feedback on software requirements or
formulated in a 3GL programming language user interfaces, further exploring software
or in an executable portion of the chosen requirements, software design, or
specification language. This specification implementation options, and/or gaining some
refinement is made possible by defining other useful insight into the software. The
specifications with precise semantic software engineer selects a prototyping method
properties; the specifications must set out to understand the least understood aspects or
not only the relationships between entities components of the software first; this approach
but also the exact runtime meanings of is in contrast with other software engineering
those relationships and operations. methods that usually begin development with
Formal Verification: Model checking is a the most understood portions first. Typically, the
formal verification method; it typically prototyped product does not become the final
involves performing a state-space software product without extensive
exploration or reachability analysis to development rework or refactoring.
demonstrate that the represented software This section discusses prototyping styles,
design has or preserves certain model targets, and evaluation techniques in brief.
properties of interest. An example of model
checking is an analysis that verifies correct PrototypingStyle: This addresses the
program behavior under all possible various approaches to developing
interleaving of event or message arrivals. prototypes. Prototypes can be developed as
The use of formal verification requires a throwaway code or paper products, as an
rigorously specified model of the software
evolution of a working design, or as an
and its operational environment; this model
executable specification. Different
often takes the form of a finite state
prototyping life cycle processes are
machine or other formally defined
typically used for each style. The style
automaton.
chosen is based on the type of results the
Logical Inference: Logical inference is a
project needs, the quality of the results
method of designing software that involves
needed, and the urgency of the results.
specifying preconditions and postconditions
Prototyping Target: The target of the
around each significant block of the design,
prototype activity is the specific product
andusing mathematical logic
being served by the prototyping effort. purpose database development tools used by
Examples of prototyping targets include a software engineers to quickly develop, test,
requirements specification, an architectural and deploy new or modified business
design element or component, an algorithm, applications.
or a humanmachine user interface. XP: This approach uses stories or scenarios
PrototypingEvaluationTechniques: A for requirements, develops tests first, has
prototype may be used or evaluated in a direct customer involvement on the team
number of ways by the software engineer or (typically defining acceptance tests), uses
other project stakeholders, driven primarily pair programming, and provides for
by the underlying reasons that led to continuous code refactoring and integration.
prototype development in the first place. Stories are decomposed into tasks,
Prototypes may be evaluated or tested prioritized, estimated, developed, and
against the actual implemented software or tested. Each increment of software is tested
against with automated and manual tests; an
a target set of requirements (for example, a increment may be released frequently, such
requirements prototype); the prototype may as every couple of weeks or so.
also serve as a model for a future software Scrum: This agile approach is more project
development effort (for example, as in a management-friendly than the others. The
user interface specification). scrum master manages the activities within
the project increment; each increment is
4.4. AgileMethods called a sprint and lasts no more than 30
[3*, c3] [6*, c7s3p7] [7*, c6, App. A] days. A Product Backlog Item (PBI) list is
developed from which tasks are identified,
Agile methods were born in the 1990s from the defined, prioritized, and estimated. A
need to reduce the apparent large overhead working version of the software is tested
associated with heavyweight, plan-based and released in each increment. Daily scrum
methods used in large-scale software- meetings ensure work is managed to plan.
development projects. Agile methods are FDD: This is a model-driven, short,
considered lightweight methods in that they are iterative software development approach
characterized by short, iterative development using a five-phase process: (1) develop a
cycles, self-organizing teams, simpler designs, product model to scope the breadth of the
code refactoring, test-driven development, domain, (2) create the list of needs or
frequent customer involvement, and an features, (3) build the feature development
emphasis on creating a demonstrable working plan, (4) develop designs for iteration-
product with each development cycle. specific features, and (5) code, test, and then
Many agile methods are available in the integrate the features. FDD is similar to an
literature; some of the more popular approaches, incremental software development
which are discussed here in brief, include Rapid approach; it is also similar to XP, except
Application Development (RAD), eXtreme that code ownership is assigned to
Programming (XP), Scrum, and Feature-Driven individuals rather than the team. FDD
Development (FDD). emphasizes an overall architectural
approach to the software, which promotes
RAD: Rapid software development methods building the feature correctly the first time
are used primarily in data-intensive, rather than emphasizing continual
businesssystems application development. refactoring.
The RAD method is enabled with special-
There are many more variations of agile heavyweight and lightweight methods based
methods in the literature and in practice. Note primarily on prevailing organizational business
that there will always be a place for needs. These business needs, as typically
heavyweight, plan-based software engineering represented by some of the project stakeholders,
methods as well as places where agile methods should and do drive the choice in using one
shine. There are new methods arising from software engineering method over another or in
combinations of agile and plan-based methods constructing a new method from the best
where practitioners are defining new methods features of a combination of software
that balance the features needed in both engineering methods.
Budgen[1*]
2003 Wing 1990
[5*]
Page-Jones
Brookshear 2008
[3*] [4*] [6*]
Mellor and Balcer 2002 Boehm and Tur
[2*] [7
1. Modeling
c2s2,
1.1. Modeling
c5s1, c2s2 c5s0
Principles
c5s2
1.2. Properties c4s1.1p7,
c5s2,
and Expression of c4s6p3,
c5s3
Models c5s0p3
1.3. Syntax,
c2s2.2.2
Semantics, and c5s0
p6
Pragmatics
1.4. Preconditions, c10s4p2,
Postconditions, and c4s4 c10s5
Invariants p2p4
2. Types of Models
2.1. Information
c7s2.2 c8s1
Modeling
c7s2.1,
2.2. Behavioral
c7s2.3, c9s2 c5s4
Modeling
c7s2.4
c7s2.5,
2.3. Structure
c7s3.1, c5s3 c4
Modeling
c7s3.2
3. Analysis of Models
3.1. Analyzing for c4s1.1p7,
pp811
Completeness c4s6
3.2. Analyzing for c4s1.1p7,
pp811
Consistency c4s6
3.3. Analyzing for
pp811
Correctness
c4s7.1,
3.4. Traceability
c4s7.2
3.5. Interaction c29s1.1,
c10, c11 c5
Analysis c29s5
Budgen[1*]
2003 Wing 1990
[5*]
Page-Jones
Brookshear 2008
[3*] [4*] [6*]
Mellor and Balcer 2002 Boehm and Tur
[2*] [7
4. Software
Engineering
Methods
c2s2.2,
4.1. Heuristic c13, c15,
c7s1,
Methods c16
c5s4.1
4.2. Formal Methods c18 c27 pp824
4.3. Prototyping
c12s2 c2s3.1 c7s3p5
Methods
c6, app.
4.4. Agile Methods c3 c7s3p7
A
REFERENCES [4*] M. Page-Jones, Fundamentalsof
[1*] D. Budgen, SoftwareDesign, 2nd ed., ObjectOrientedDesigninUML, 1st ed.,
Addison-Wesley, 2003. AddisonWesley, 1999.
[2*] S.J. Mellor and M.J. Balcer, Executable [5*] J.M. Wing, A Specifiers Introduction to
UML:AFoundationforModel-Driven Formal Methods, Computer, vol. 23, no. 9,
Architecture, 1st ed., Addison-Wesley, 1990, pp. 8, 1023.
2002.
[6*] J.G. Brookshear, ComputerScience:An
[3*] I. Sommerville, SoftwareEngineering, 9th Overview, 10th ed., Addison-Wesley, 2008.
ed., Addison-Wesley, 2011.
[7*] B. Boehm and R. Turner, Balancing
AgilityandDiscipline:AGuideforthe
Perplexed, Addison-Wesley, 2003.
CHAPTER 10 SOFTWARE QUALITY
ACRONYMS What is software quality, and why is it so

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

use. Stakeholder value is expressed in for the product), lead time (how fast they get the
requirements. For software products, product), and software quality.
stakeholders could value price (what they pay
This KA addresses definitions and provides Ethics also play a significant role in software
an overview of practices, tools, and techniques quality, the culture, and the attitudes of software
for defining software quality and for appraising engineers. The IEEE Computer Society and the
the state of software quality during ACM have developed a code of ethics and
development, maintenance, and deployment. professional practice (see Codes of Ethics and
Cited references provide additional details. Professional Conduct in the Software
Engineering Professional Practice KA).
SOFTWARE QUALITY 1.2. ValueandCostsofQuality
[7*, c17, c22]
Quality KA is presented in Figure 10.1. Defining and then achieving software quality is
not simple. Quality characteristics may or may
1. Software Quality Fundamentals not be required, or they may be required to a
greater or lesser degree, and tradeoffs may be
Reaching agreement on what constitutes quality made among them. To help determine the level
for all stakeholders and clearly communicating of software quality, i.e., achieving stakeholder
that agreement to software engineers require value, this section presents cost of software
that the many aspects of quality be formally quality (CoSQ): a set of measurements derived
defined and discussed. from the economic assessment of software
A software engineer should understand quality development and maintenance
quality concepts, characteristics, values, and processes. The CoSQ measurements are
their application to the software under examples of process measurements that may be
development or maintenance. The important used to infer characteristics of a product.
concept is that the software requirements define The premise underlying the CoSQ is that the
the required quality attributes of the software. level of quality in a software product can be
Software requirements influence the inferred from the cost of activities related to
measurement methods and acceptance criteria dealing with the consequences of poor quality.
for assessing the degree to which the software Poor quality means that the software product
and related documentation achieve the desired does not fully satisfy stated and implied needs
quality levels. or established requirements. There are four
cost of quality categories: prevention, appraisal,
1.1. SoftwareEngineeringCultureandEthics internal failure, and external failure.
[3*, c1s4] [6*, c2s3.5] Prevention costs include investments in
software process improvement efforts, quality
Software engineers are expected to share a infrastructure, quality tools, training, audits, and
commitment to software quality as part of their management reviews. These costs are usually
culture. A healthy software engineering culture not specific to a project; they span the
includes many characteristics, including the organization. Appraisal costs arise from project
understanding that tradeoffs among cost, activities that find defects. These appraisal
schedule, and quality are a basic tenant of the activities can be categorized into costs of
engineering of any product. A strong software reviews (design, peer) and costs of testing
engineering ethic assumes that engineers (software unit testing, software integration,
accurately report information, conditions, and system level testing, acceptance testing);
outcomes related to quality. appraisal costs would be extended to
subcontracted software suppliers. Costs of
internal failures are those that are incurred to fix It is not possible to completely distinguish
defects found during appraisal activities and process quality from product quality because
discovered prior to delivery of the software process outcomes include products.
product to the customer. External failure costs Determining whether a process has the
include activities to respond to software capability to consistently produce products of
problems discovered after delivery to the desired quality is not simple.
customer. The software engineering process, discussed
Software engineers should be able to use in the Software Engineering Process KA,
CoSQ methods to ascertain levels of software influences the quality characteristics of software
quality and should also be able to present products, which in turn affect quality as
quality alternatives and their costs so that perceived by stakeholders.
tradeoffs between cost, schedule, and delivery 1.3.2. SoftwareProductQuality
of stakeholder value can be made.
The software engineer, first of all, must
1.3. ModelsandQualityCharacteristics determine the real purpose of the software. In
[3*, c24s1] [7*, c2s4] [8*, c17] this regard, stakeholder requirements are
paramount, and they include quality
Terminology for software quality characteristics requirements in addition to functional
differs from one taxonomy (or model of requirements. Thus, software engineers have a
software quality) to another, each model responsibility to elicit quality requirements that
perhaps having a different number of may not be explicit at the outset and to
hierarchical levels and a different total number understand their importance as well as the level
of characteristics. Various authors have of difficulty in attaining them. All software
produced models of software quality development processes (e.g., eliciting
characteristics or attributes that can be useful requirements, designing, constructing, building,
for discussing, planning, and rating the quality checking, improving quality) are designed with
of software products. ISO/IEC 25010: 2011 [4] these quality requirements in mind and may
defines product quality and quality in use as two carry additional development costs if attributes
related quality models. Appendix B in the such as safety, security, and dependability are
SWEBOK Guide provides a list of applicable important. The additional development costs
standards for each KA. Standards for this KA help ensure that quality obtained can be traded
cover various ways of characterizing software off against the anticipated benefits.
quality. The term work-product means any artifact
that is the outcome of a process used to create
1.3.1. SoftwareProcessQuality the final software product. Examples of a work-
product include a system/subsystem
Software quality management and software specification, a software requirements
engineering process quality have a direct specification for a software component of a
bearing on the quality of the software product. system, a software design description, source
Models and criteria that evaluate the code, software test documentation, or reports.
capabilities of software organizations are While some treatments of quality are described
primarily project organization and management in terms of final software and system
considerations and, as such, are covered in the performance, sound engineering practice
Software Engineering Management and requires that intermediate work-products
Software Engineering Process KAs. relevant to quality be evaluated throughout the
software engineering process.
1.4. SoftwareQualityImprovement Safety-critical systems are those in which a

[3*, c1s4] [9*, c24] [10*, c11s2.4] system failure could harm human life, other
living things, physical structures, or the
The quality of software products can be environment. The software in these systems is
improved through preventative processes or an safety-critical. There are increasing numbers of
iterative process of continual improvement, applications of safety-critical software in a
which requires management control, growing number of industries. Examples of
coordination, and feedback from many systems with safetycritical software include
concurrent processes: (1) the software life cycle mass transit systems, chemical manufacturing
processes, (2) the process of fault/defect plants, and medical devices. The failure of
detection, removal, and prevention, and (3) the software in these systems could have
quality improvement process. catastrophic effects. There are industry
The theory and concepts behind quality standards, such as DO-178C [11], and emerging
improvementsuch as building in quality processes, tools, and techniques for developing
through the prevention and early detection of safetycritical software. The intent of these
defects, continual improvement, and stakeholder standards, tools, and techniques is to reduce the
focusare pertinent to software engineering. risk of injecting faults into the software and thus
These concepts are based on the work of experts improve software reliability.
in quality who have stated that the quality of a Safety-critical software can be categorized as
product is directly linked to the quality of the direct or indirect. Direct is that software
process used to create it. Approaches such as the embedded in a safety-critical system, such as the
Deming improvement cycle of Plan-Do- flight control computer of an aircraft. Indirect
CheckAct (PDCA), evolutionary delivery, includes software applications used to develop
kaizen, and quality function deployment (QFD) safetycritical software. Indirect software is
offer techniques to specify quality objectives included in software engineering environments
and determine whether they are met. The and software test environments.
Software Engineering Institutes IDEAL is Three complementary techniques for reducing
another method [7*]. Quality management is the risk of failure are avoidance, detection and
now recognized by the SWEBOK Guide as an removal, and damage limitation. These
important discipline. techniques impact software functional
Management sponsorship supports process requirements, software performance
and product evaluations and the resulting requirements, and development processes.
findings. Then an improvement program is Increasing levels of risk imply increasing levels
developed identifying detailed actions and of software quality assurance and control
improvement projects to be addressed in a techniques such as inspections. Higher risk
feasible time frame. Management support levels may necessitate more thorough
implies that each improvement project has inspections of requirements, design, and code or
enough resources to achieve the goal defined for the use of more formal analytical techniques.
it. Management sponsorship is solicited Another technique for managing and controlling
frequently by implementing proactive software risk is building assurance cases. An
communication activities. assurance case is a reasoned, auditable artifact
created to support the contention that its claim
1.5. SoftwareSafety or claims are satisfied. It contains the following
[9*, c11s3] and their relationships: one or more claims
about properties; arguments that logically link
the evidence and any assumptions to the claims;
and a body of evidence and assumptions first three categories, an increasing number of
supporting these arguments [12]. organizations organize SPI into a separate
category that may span across many projects
2. Software Quality Management Processes (see the Software Engineering Process KA).
Software quality processes consist of tasks
Software quality management is the collection and techniques to indicate how software plans
of all processes that ensure that software (e.g., software management, development,
products, services, and life cycle process quality management, or configuration
implementations meet organizational software management plans) are being implemented and
quality objectives and achieve stakeholder how well the intermediate and final products are
satisfaction [13, 14]. SQM defines processes, meeting their specified requirements. Results
process owners, requirements for the processes, from these tasks are assembled in reports for
measurements of the processes and their management before corrective action is taken.
outputs, and feedback channels throughout the The management of an SQM process is tasked
whole software life cycle. with ensuring that the results of these reports are
SQM comprises four subcategories: software accurate.
quality planning, software quality assurance Risk management can also play an important
(SQA), software quality control (SQC), and role in delivering quality software.
software process improvement (SPI). Software Incorporating disciplined risk analysis and
quality planning includes determining which management techniques into the software life
quality standards are to be used, defining cycle processes can help improve product
specific quality goals, and estimating the effort quality (see the Software Engineering
and schedule of software quality activities. In Management KA for related material on risk
some cases, software quality planning also management).
includes defining the software quality processes
to be used. SQA activities define and assess the 2.1. SoftwareQualityAssurance
adequacy of software processes to provide [7*, c4c6, c11, c12, c2627]
evidence that establishes confidence that the
software processes are appropriate for and To quell a widespread misunderstanding,
produce software products of suitable quality for software quality assurance is not testing.
their intended purposes [5]. SQC activities software quality assurance (SQA) is a set of
examine specific project artifacts (documents activities that define and assess the adequacy of
and executables) to determine whether they software processes to provide evidence that
comply with standards established for the establishes confidence that the software
project (including requirements, constraints, processes are appropriate and produce software
designs, contracts, and plans). SQC evaluates products of suitable quality for their intended
intermediate products as well as the final purposes. A key attribute of SQA is the
products. objectivity of the SQA function with respect to
The fourth SQM category dealing with the project. The SQA function may also be
improvement has various names within the organizationally independent of the project; that
software industry, including SPI, software is, free from technical, managerial, and financial
quality improvement, and software corrective pressures from the project [5]. SQA has two
and preventive action. The activities in this aspects: product assurance and process
category seek to improve process effectiveness, assurance, which are explained in section 2.3.
efficiency, and other characteristics with the The software quality plan (in some industry
ultimate goal of improving software quality. sectors it is termed the software quality
Although SPI could be included in any of the assurance plan) defines the activities and tasks
employed to ensure that software developed for demonstrates whether the requirements
a specific product satisfies the projects are correct, complete, accurate,
established requirements and user needs within consistent, and testable. The V&V
project cost and schedule constraints and is processes determine whether the
commensurate with project risks. The SQAP development products of a given activity
first ensures that quality targets are clearly conform to the requirements of that
defined and understood. activity and whether the product satisfies
The SQA plans quality activities and tasks its intended use and user needs.
are specified with their costs, resource
requirements, objectives, and schedule in Verification is an attempt to ensure that the
relation to related objectives in the software product is built correctly, in the sense that the
engineering management, software output products of an activity meet the
development, and software maintenance plans. specifications imposed on them in previous
The SQA plan should be consistent with the activities. Validation is an attempt to ensure that
software configuration management plan (see the right product is builtthat is, the product
the Software Configuration Management KA). fulfills its specific intended purpose. Both the
The SQA plan identifies documents, standards, verification process and the validation process
practices, and conventions governing the project begin early in the development or maintenance
and how these items are checked and monitored phase. They provide an examination of key
to ensure adequacy and compliance. The SQA product features in relation to both the products
plan also identifies measures; statistical immediate predecessor and the specifications to
techniques; procedures for problem reporting be met.
and corrective action; resources such as tools, The purpose of planning V&V is to ensure
techniques, and methodologies; security for that each resource, role, and responsibility is
physical media; training; and SQA reporting and
clearly assigned. The resulting V&V plan
documentation. Moreover, the SQA plan
documents describe the various resources and
addresses the software quality assurance
their roles and activities, as well as the
activities of any other type of activity described
techniques and tools to be used. An
in the software planssuch as procurement of
understanding of the different purposes of each
supplier software for the project, commercial
V&V activity helps in the careful planning of
off-the-shelf software (COTS) installation, and
the techniques and resources needed to fulfill
service after delivery of the software. It can also
their purposes. The plan also addresses the
contain acceptance criteria as well as reporting
management, communication, policies, and
and management activities that are critical to
software quality. procedures of the V&V activities and their
interaction, as well as defect reporting and
2.2. Verification&Validation documentation requirements.
[9*, c2s2.3, c8, c15s1.1,
2.3. ReviewsandAudits
c21s3.3] As stated in [15], [9*, c24s3] [16*]
The purpose of V&V is to help the Reviews and audit processes are broadly defined
development organization build quality as staticmeaning that no software programs or
into the system during the life cycle. models are executedexamination of software
V&V processes provide an objective engineering artifacts with respect to standards
assessment of products and processes that have been established by the organization
throughout the life cycle. This assessment or project for those artifacts. Different types of
reviews and audits are distinguished by their about corrective actions, changes in the
purpose, levels of independence, tools and allocation of resources, or changes to the
techniques, roles, and by the subject of the scope of the project.
activity. Product assurance and process
assurance audits are typically conducted by Inputs to management reviews may include
software quality assurance (SQA) personnel audit reports, progress reports, V&V reports,
who are independent of development teams. and plans of many types, including risk
Management reviews are conducted by management, project management, software
organizational or project management. The configuration management, software safety, and
engineering staff conducts technical reviews. risk assessment, among others. (Refer to the
Software Engineering Management and the
Management reviews evaluate actual project Software Configuration Management KAs for
results with respect to plans. related material.)
Technical reviews (including inspections, 2.3.2. TechnicalReviews
walkthrough, and desk checking) examine
engineering work-products. As stated in [16*],
Process assurance audits. SQA process
assurance activities make certain that the The purpose of a technical review is to
processes used to develop, install, operate, evaluate a software product by a team of
and maintain software conform to contracts, qualified personnel to determine its
comply with any imposed laws, rules, and suitability for its intended use and
identify discrepancies from specifications
regulations and are adequate, efficient and
and standards. It provides management
effective for their intended purpose [5].
with evidence to confirm the technical
Product assurance audits. SQA product
status of the project.
assurance activities make certain to provide
evidence that software products and related
Although any work-product can be reviewed,
documentation are identified in and comply
technical reviews are performed on the main
with contracts; and ensure that
software engineering work-products of software
nonconformances are identified and
requirements and software design.
addressed [5].
Purpose, roles, activities, and most
importantly the level of formality distinguish
2.3.1. ManagementReviews
different types of technical reviews. Inspections
As stated in [16*], are the most formal, walkthroughs less, and pair
reviews or desk checks are the least formal.
The purpose of a management review is Examples of specific roles include a decision
to monitor progress, determine the status maker (i.e., software lead), a review leader, a
of plans and schedules, and evaluate the recorder, and checkers (technical staff members
effectiveness of management processes, who examine the work-products). Reviews are
tools and techniques. Management also distinguished by whether meetings (face to
reviews compare actual project results face or electronic) are included in the process.
against plans to determine the status of In some review methods checkers solitarily
projects or maintenance efforts. The main examine work-products and send their results
parameters of management reviews are back to a coordinator. In other methods checkers
project cost, schedule, scope, and quality. work cooperatively in meetings. A technical
Management reviews evaluate decisions review may require that mandatory inputs be in
place in order to proceed:
Statement of objectives 4. Led. An impartial moderator who is trained

Specific software product in inspection techniques leads inspection
Specific project management plan Issues meetings.
list associated with this product 5. Meeting. The inspection process includes
Technical review procedure. meetings (face to face or electronic)
conducted by a moderator according to a
The team follows the documented review formal procedure in which inspection team
procedure. The technical review is completed members report the anomalies they have
once all the activities listed in the examination found and other issues.
have been completed.
Technical reviews of source code may include Software inspections always involve the
a wide variety of concerns such as analysis of author of an intermediate or final product; other
algorithms, utilization of critical computer reviews might not. Inspections also include an
resources, adherence to coding standards, inspection leader, a recorder, a reader, and a few
structure and organization of code for testability, (two to five) checkers (inspectors). The
and safetycritical considerations. members of an inspection team may possess
Note that technical reviews of source code or different expertise, such as domain expertise,
design models such as UML are also termed software design method expertise, or
static analysis (see topic 3, Practical programming language expertise. Inspections
Considerations). are usually conducted on one relatively small
section of the product at a time (samples). Each
2.3.3. Inspections team member examines the software product
and other review inputs prior to the review
The purpose of an inspection is to detect and meeting, perhaps by applying an analytical
identify software product anomalies [16*]. technique (see section 3.3.3) to a small section
Some important differentiators of inspections as of the product or to the entire product with a
compared to other types of technical reviews are focus on only one aspecte.g., interfaces.
these: During the inspection, the moderator conducts
the session and verifies that everyone has
1. Rules. Inspections are based upon prepared for the inspection and conducts the
examining a work-product with respect to a session. The inspection recorder documents
defined set of criteria specified by the anomalies found. A set of rules, with criteria and
organization. Sets of rules can be defined questions germane to the issues of interest, is a
for different types of workproducts (e.g., common tool used in inspections. The resulting
rules for requirements, architecture list often classifies the anomalies (see section
descriptions, source code). 3.2, Defect Characterization) and is reviewed
2. Sampling. Rather that attempt to examine for completeness and accuracy by the team. The
every word and figure in a document, the inspection exit decision corresponds to one of
inspection process allows checkers to the following options:
evaluate defined subsets (samples) of the
documents under review. 1. Accept with no or, at most, minor
3. Peer. Individuals holding management reworking 2. Accept with rework verification
positions over members of the inspection 3. Reinspect.
team do not participate in the inspection.
This is a key distinction between peer 2.3.4. Walkthroughs
review and management review.
As stated in [16*], the standard [16*], the important point is that

they can occur on almost any product at any
The purpose of a systematic walk- stage of the development or maintenance
through is to evaluate a software product. process. 3. Practical Considerations
A walkthrough may be conducted for the
purpose of educating an audience 3.1. SoftwareQualityRequirements
regarding a software product. [9*, c11s1] [18*, c12]
[17*, c15s3.2.2, c15s3.3.1, c16s9.10]
Walkthroughs are distinguished from
inspections. The main difference is that the 3.1.1. InfluenceFactors
author presents the work-product to the other
participants in a meeting (face to face or Various factors influence planning,
electronic). Unlike an inspection, the meeting management, and selection of SQM activities
participants may not have necessarily seen the and techniques, including
material prior to the meeting. The meetings may
be conducted less formally. The author takes the the domain of the system in which the
role of explaining and showing the material to software resides; the system functions could
participants and solicits feedback. Like be safety-critical, mission-critical,
inspections, walkthroughs may be conducted on businesscritical, security-critical
any type of work-product including project plan, the physical environment in which the
requirements, design, source code, and test software system resides
reports. system and software functional (what the
2.3.5. ProcessAssuranceandProduct system does) and quality (how well the
AssuranceAudits system performs its functions) requirements
the commercial (external) or standard
As stated in [16*], (internal) components to be used in the
system
The purpose of a software audit is to the specific software engineering standards
provide an independent evaluation of the applicable
conformance of software products and the methods and software tools to be used
processes to applicable regulations, for development and maintenance and for
standards, guidelines, plans, and quality evaluation and improvement
procedures. the budget, staff, project organization, plans,
and scheduling of all processes the
Process assurance audits determine the intended users and use of the system
adequacy of plans, schedules, and requirements the integrity level of the system.
to achieve project objectives [5]. The audit is a
formally organized activity with participants Information on these factors influences how
having specific rolessuch as lead auditor, the SQM processes are organized and
another auditor, a recorder, or an initiatorand documented, how specific SQM activities are
including a representative of the audited selected, what resources are needed, and which
organization. Audits identify instances of of those resources impose bounds on the efforts.
nonconformance and produce a report requiring
the team to take corrective action. 3.1.2. Dependability
While there may be many formal names for
reviews and audits, such as those identified in In cases where system failure may have
extremely severe consequences, overall
dependability (hardware, software, and human Verification, validation, and testing processes,
or operational) is the main quality requirement techniques, methods, and tools identify faults
over and above basic functionality. This is the that impact dependability as early as possible in
case for the following reasons: system failures the life cycle. Additionally, mechanisms may
affect a large number of people; users often need to be in place in the software to guard
reject systems that are unreliable, unsafe, or against external attacks and to tolerate faults.
insecure; system failure costs may be enormous;
and undependable systems may cause 3.1.3. IntegrityLevelsofSoftware
information loss. System and software
dependability include such characteristics as Defining integrity levels is a method of risk
availability, reliability, safety, and security. management.
When developing dependable software, tools
and techniques can be applied to reduce the risk Software integrity levels are a range of
of injecting faults into the intermediate values that represent software
deliverables or the final software product. complexity, criticality, risk, safety level,
security level,
Software Quality 10-12
desired performance, reliability, or other alone, without some classification, may not be
project-unique characteristics that define the sufficient to identify the underlying causes of the
importance of the software to the user and defects.
acquirer. The characteristics used to Specific types of problems need to be grouped to
determine software integrity level vary identify trends over time. The point is to establish a
depending on the intended application and defect taxonomy that is meaningful to the
use of the system. The software is a part of organization and to software engineers.
the system, and its integrity level is to be Software quality control activities discover
determined as a part of that system. information at all stages of software development
and maintenance. In some cases, the word defect is
The assigned software integrity levels may overloaded to refer to different types of anomalies.
change as the software evolves. Design, coding, However, different engineering cultures and
procedural, and technology features implemented standards may use somewhat different meanings for
in the system or software can raise or lower the these terms. The variety of terms prompts this
assigned software integrity levels. The software section to provide a widely used set of definitions
integrity levels established for a project result from [19]:
agreements among the acquirer, supplier, developer,
and independent assurance authorities. A software Computational Error: the difference between
integrity level scheme is a tool used in determining a computed, observed, or measured value or
software integrity levels. [5] condition and the true, specified, or
As noted in [17*], the integrity levels can be theoretically correct value or condition.
applied during development to allocate additional Error: A human action that produces an
verification and validation efforts to high-integrity incorrect result. A slip or mistake that a person
components. makes. Also called human error.
Defect: An imperfection or deficiency in a
3.2. DefectCharacterization work product where that work product does not
[3*, c3s3, c8s8, c10s2] meet its requirements or specifications and
needs to be either repaired or replaced. A
Software quality evaluation (i.e., software quality defect is caused by a person committing an
control) techniques find defects, faults and failures. error.
Characterizing these techniques leads to an Fault: A defect in source code. An incorrect
understanding of the product, facilitates corrections step, process, or data definition in computer
to the process or the product, and informs program. The encoding of a human error in
management and other stakeholders of the status of source code. Fault is the formal name of a bug.
the process or product. Many taxonomies exist and, Failure: An event in which a system or system
while attempts have been made to gain consensus, component does not perform a required
the literature indicates that there are quite a few in function within specified limits. A failure is
use. Defect characterization is also used in audits produced when a fault is encountered by the
and reviews, with the review leader often processor under specified conditions.
presenting a list of issues provided by team
members for consideration at a review meeting. Using these definitions three widely used
As new design methods and languages evolve, software quality measurements are defect density
along with advances in overall software (number of defects per unit size of documents),
technologies, new classes of defects appear, and a fault density (number of faults per 1K lines of
great deal of effort is required to interpret code), and failure intensity (failures per use-hour or
previously defined classes. When tracking defects, per test-hour). Reliability models are built from
the software engineer is interested in not only the failure data collected during software testing or
number of defects but also the types. Information from software in service and thus can be used to
estimate the probability of future failures and to tools because they do not involve executing the
assist in decisions on when to stop testing. software code.
One probable action resulting from SQM Other, more formal, types of analytical
findings is to remove the defects from the product techniques are known as formal methods. They are
under examination (e.g., find and fix bugs, create notably used to verify software requirements and
new build). Other activities attempt to eliminate the designs. They have mostly been used in the
causes of the defectsfor example, root cause verification of crucial parts of critical systems, such
analysis (RCA). RCA activities include analyzing as specific security and safety requirements. (See
and summarizing the findings to find root causes also Formal Methods in the Software Engineering
and using measurement techniques to improve the Models and Methods KA.)
product and the process as well as to track the
defects and their removal. Process improvement is 3.3.2. DynamicTechniques
primarily discussed in the Software Engineering
Process KA, with the SQM process being a source Dynamic techniques involve executing the software
of information. code. Different kinds of dynamic techniques are
Data on inadequacies and defects found by performed throughout the development and
software quality control techniques may be lost maintenance of software. Generally, these are
unless they are recorded. For some techniques (e.g., testing techniques, but techniques such as
technical reviews, audits, inspections), recorders simulation and model analysis may be considered
are present to set down such information, along dynamic (see the Software Engineering Models and
with issues and decisions. When automated tools Methods KA). Code reading is considered a static
are used (see topic 4, Software Quality Tools), the technique, but experienced software engineers may
tool output may provide the defect information. execute the code as they read through it. Code
Reports about defects are provided to the reading may utilize dynamic techniques. This
management of the organization. discrepancy in categorizing indicates that people
with different roles and experience in the
3.3. SoftwareQualityManagementTechniques organization may consider and apply these
[7*, c7s3] [8*, c17] [9*, c12s5, c15s1, p417] techniques differently.
[16*] Different groups may perform testing during
software development, including groups
Software quality control techniques can be independent of the development team. The
categorized in many ways, but a straightforward Software Testing KA is devoted entirely to this
approach uses just two categories: static and subject.
dynamic. Dynamic techniques involve executing
the software; static techniques involve analyzing 3.3.3. Testing
documents and source code but not executing the
software. Two types of testing may fall under V&V because
of their responsibility for the quality of the
3.3.1. StaticTechniques materials used in the project:
Static techniques examine software documentation Evaluation and tests of tools to be used on the
(including requirements, interface specifications, project
designs, and models) and software source code Conformance tests (or review of conformance
without executing the code. There are many tools tests) of components and COTS products to be
and techniques for statically examining software used in the product.
work-products (see section 2.3.2). In addition, tools
that analyze source code control flow and search Sometimes an independent (third-party or IV&V)
for dead code are considered to be static analysis organization may be tasked to perform testing or to
monitor the test process V&V may be called upon descriptive statistics based (e.g., Pareto
to evaluate the testing itself: adequacy of plans, analysis, run charts, scatter plots, normal
processes, and procedures, and adequacy and distribution)
accuracy of results. statistical tests (e.g., the binomial test,
The third party is not the developer, nor is it chisquared test)
associated with the development of the product. trend analysis (e.g., control charts; see The
Instead, the third party is an independent facility, Quality Toolbox in the list of further readings)
usually accredited by some body of authority. Their prediction (e.g., reliability models).
purpose is to test a product for conformance to a
specific set of requirements (see the Software Descriptive statistics-based techniques and tests
Testing KA). often provide a snapshot of the more troublesome
3.4. SoftwareQualityMeasurement areas of the software product under examination.
[3*, c4] [8*, c17] [9*, p90] The resulting charts and graphs are visualization
aids, which the decision makers can use to focus
Software quality measurements are used to support resources and conduct process improvements where
decision-making. With the increasing sophistication they appear to be most needed. Results from trend
of software, questions of quality go beyond analysis may indicate that a schedule is being met,
whether or not the software works to how well it such as in testing, or that certain classes of faults
achieves measurable quality goals. may become more likely to occur unless some
Decisions supported by software quality corrective action is taken in development. The
measurement include determining levels of predictive techniques assist in estimating testing
software quality (notably because models of effort and schedule and in predicting failures. More
software product quality include measures to discussion on measurement in general appears in
determine the degree to which the software product the Software Engineering Process and Software
achieves quality goals); managerial questions about Engineering Management KAs. More specific
effort, cost, and schedule; determining when to stop information on testing measurement is presented in
testing and release a product (see Termination the Software Testing KA.
under section 5.1, Practical Considerations, in the Software quality measurement includes
Software Testing KA); and determining the efficacy measuring defect occurrences and applying
of process improvement efforts. statistical methods to understand the types of
The cost of SQM processes is an issue frequently defects that occur most frequently. This information
raised in deciding how a project or a software may be used by software process improvement for
development and maintenance group should be determining methods to prevent, reduce, or
organized. Often, generic models of cost are used, eliminate their recurrence. They also aid in
which are based on when a defect is found and how understanding trends, how well detection and
much effort it takes to fix the defect relative to containment techniques are working, and how well
finding the defect earlier in the development the development and maintenance processes are
process. Software quality measurement data progressing.
collected internally may give a better picture of From these measurement methods, defect
cost within this project or organization. profiles can be developed for a specific application
While the software quality measurement data domain. Then, for the next software project within
may be useful in itself (e.g., the number of that organization, the profiles can be used to guide
defective requirements or the proportion of the SQM processesthat is, to expend the effort
defective requirements), mathematical and where problems are most likely to occur. Similarly,
graphical techniques can be applied to aid in the benchmarks, or defect counts typical of that
interpretation of the measures (see the Engineering domain, may serve as one aid in determining when
Foundations KA). These techniques include the product is ready for delivery. Discussion on
using data from SQM to improve development and
maintenance processes appears in the Software process. They allow users to enter defects found
Engineering Management and Software during inspections and reviews for later
Engineering Process KAs. removal.
Some tools help organizations perform software
4. Software Quality Tools safety hazard analysis. These tools provide, e.g.,
automated support for failure mode and effects
Software quality tools include static and dynamic analysis (FMEA) and fault tree analysis (FTA).
analysis tools. Static analysis tools input source Tools that support tracking of software problems
code, perform syntactical and semantic analysis provide for entry of anomalies discovered
without executing the code, and present results to during software testing and subsequent analysis,
users. There is a large variety in the depth, disposition, and resolution. Some tools include
thoroughness, and scope of static analysis tools that support for workflow and for tracking the status
can be applied to artifacts including models, in of problem resolution.
addition to source code. (See the Software Tools that analyze data captured from software
Construction, Software Testing, and Software engineering environments and software test
Maintenance KAs for descriptions of dynamic environments and produce visual displays of
analysis quantified data in the form of graphs, charts, and
tools.) tables. These tools sometimes include the
Categories of static analysis tools include the functionality to perform statistical analysis on
following: data sets (for the purpose of discerning trends
and making forecasts). Some of these tools
Tools that facilitate and partially automate reviews provide defect and removal injection rates;
and inspections of documents and code. These defect densities; yields; distribution of defect
tools can route work to different participants in injection and removal for each of the life cycle
order to partially automate and control a review phases.
Kan 2002
[3*] Galin 2004 2003MooreWiegers
Voland [10*] 2006 [
[17*]
[7*]
Bott et al. 2000
IEEE Std. 1028-2008
[9*]
Naik and Tripathy 2008 [16*]
[8*]
1. Software
Quality
Fundamentals
1.1. Software
Engineering
c1s4 c2s3.5
Culture and
Ethics
1.2. Value and c17,
Cost of Quality c22
1.3. Models
and Quality c24s1 c2s4 c17
Characteristics
1.4. Software
c11
Quality c1s4 c24
s2.4
Improvement
1.5. Software
c11s3
Safety
2. Software
Quality
Management
Processes
2.1. Software c4c6,
Quality c11,
Assurance c2627
c2
s2.3,
2.2. Verification c8, c15
and Validation s1.1,
c21
s3.3
2.3. Reviews
c24s3 *
and Audits
Kan 2002
[3*] Galin 2004 2003MooreWiegers
Voland [10*] 2006 [
[17*]
[7*]
Bott et al. 2000
IEEE Std. 1028-2008
[9*]
Naik and Tripathy 2008 [16*]
[8*]
3. Software
Quality Practical
Considerations
c15
s3.2.2,
3.1. Software
c15
Quality c11s1 c12
s3.3.1,
Requirements
c16
s9.10
c3s3,
3.2. Defect
c8s8,
Characterization
c10s2
c12s5,
3.3. SQM
c7s3 c17 c15s1, *
Techniques
p417
3.4. Software
Quality c4 c17 p90
Measurement
4. Software
Quality Tools
FURTHER READINGS Provides a pragmatic how-to explanation
N. Leveson, Safeware:SystemSafetyand of a comprehensive set of methods, tools,
Computers [20]. and techniques for solving quality
improvement problems. Includes the
This book describes the importance of seven basic quality control tools and many
software safety practices and how these others.
practices can be incorporated into
software development projects. IEEEStd.P730-2013DraftStandardfor
SoftwareQualityAssuranceProcesses
T. Gilb, PrinciplesofSoftware [5].
EngineeringManagement [21].
This draft standard expands the SQA
This is one of the first books on iterative processes identified in IEEE/ISO/IEC
and incremental development techniques. 12207-2008. P730 establishes standards
The Evo Method defines quantified goals, for initiating, planning, controlling, and
frequent timeboxed iterations, executing the software quality assurance
measurements of progress toward goals, processes of a software development or
and adaptation of plans based on actual maintenance project. Approval of this
results. draft standard is expected in 2014.
REFERENCES
T. Gilb and D. Graham, Software [1] P.B. Crosby, QualityIsFree, McGraw-
Inspection [22]. Hill, 1979.
This book introduces measurement and [2] W. Humphrey, ManagingtheSoftware

statistical sampling for reviews and Process, Addison-Wesley, 1989.
defects. It presents techniques that
produce quantified results for reducing [3*] S.H. Kan, MetricsandModelsin
defects, improving productivity, tracking SoftwareQualityEngineering, 2nd
projects, and creating documentation. ed., AddisonWesley, 2002.
K.E. Wiegers, PeerReviewsinSoftware:
APracticalGuide [23]. [4] ISO/IEC25010:2011Systemsand
Software
This book provides clear, succinct EngineeringSystemsandSoftware
explanations of different peer review QualityRequirementsandEvaluation
methods distinguished by level of (SQuaRE)SystemsandSoftware
formality and effectiveness. Pragmatic QualityModels, ISO/IEC, 2011.
guidance for implementing the methods
and how to select which methods are [5] IEEEP730/D8DraftStandardfor
appropriate for given circumstances is SoftwareQualityAssuranceProcesses,
provided. IEEE, 2012.
N.R. Tague, TheQualityToolbox, 2nd ed., [6*] F. Bott et al., ProfessionalIssuesin

[24]. SoftwareEngineering, 3rd ed., Taylor
& Francis, 2000.
[7*] D. Galin, SoftwareQuality [15] IEEEStd.1012-2012Standardfor

Assurance:FromTheoryto SystemandSoftwareVerificationand
Implementation, Pearson Education Validation, IEEE, 2012.
Limited, 2004.
[16*] IEEEStd.1028-2008,Software
[8*] S. Naik and P. Tripathy, Software ReviewsandAudits, IEEE, 2008.
TestingandQualityAssurance:
TheoryandPractice, Wiley- [17*] J.W. Moore, TheRoadMapto
Spektrum, 2008. SoftwareEngineering:AStandards-
BasedGuide, Wiley-IEEE Computer
[9*] P. Clements et al., Documenting Society Press, 2006.
SoftwareArchitectures:Viewsand
Beyond, 2nd ed., Pearson Education, [18*] K.E. Wiegers, Software
2010. Requirements, 2nd ed., Microsoft
Press, 2003.
[10*] G. Voland, EngineeringbyDesign,
2nd ed., Prentice Hall, 2003. [19] ISO/IEC/IEEE24765:2010Systems
andSoftwareEngineering
[11] RTCADO-178C,Software Vocabulary, ISO/ IEC/IEEE, 2010.
ConsiderationsinAirborneSystems
andEquipmentCertification, Radio [20] N. Leveson, Safeware:SystemSafety
Technical Commission for andComputers, Addison-Wesley
Aeronautics, 2011. Professional, 1995.
[12] IEEEStd.15026.1-2011Trial-Use [21] T. Gilb, PrinciplesofSoftware

Standard EngineeringManagement, Addison-
AdoptionofISO/IECTR15026- Wesley Professional, 1988.
1:2010
SystemsandSoftwareEngineering [22] T. Gilb and D. Graham, Software
SystemsandSoftwareAssurance Inspection, Addison-Wesley
Part1:ConceptsandVocabulary, Professional, 1993.
IEEE, 2011.
[13] IEEEStd.12207-2008(a.k.a. [23] K. Wiegers, PeerReviewsin
ISO/IEC Software:APracticalGuide,
12207:2008)StandardforSystems Addison-Wesley Professional, 2001.
andSoftwareEngineeringSoftware
LifeCycleProcesses, IEEE, 2008. [24] N.R. Tague, TheQualityToolbox, 2nd
ed., ASQ Quality Press, 2010.
[14] ISO9000:2005QualityManagement
SystemsFundamentalsand
Vocabulary, ISO, 2005.
CHAPTER 11
SOFTWARE ENGINEERING
PROFESSIONAL PRACTICE
ACRONYMS knowledge, skills, training, and experience
Association for Computing in professional practice.
ACM The term professional practice refers
Machinery
to a way of conducting services so as to
BCS British Computer Society achieve certain standards or criteria in
Certified Software Development both the process of performing a service
CSDA
Associate and the end product resulting from the
Certified Software Development service. These standards and criteria can
CSDP include both technical and nontechnical
Professional
aspects. The concept of professional
International Electrotechnical
IEC practice can be viewed as being more
Commission
applicable within those professions that
IEEE CS IEEE Computer Society have a generally accepted body of
International. Federation for knowledge; codes of ethics and
IFIP
Information Processing professional conduct with penalties for
IP Intellectual Property violations; accepted processes for
accreditation, certification, and licensing;
International Organization for and professional societies to provide and
ISO
Standardization administer all of these. Admission to these
NDA Non-Disclosure Agreement professional societies is often predicated
World Intellectual Property on a prescribed combination of education
WIPO and experience.
Organization
A software engineer maintains a
WTO World Trade Organization
professional practice by performing all
INTRODUCTION
work in accordance with generally
accepted practices, standards, and
The Software Engineering Professional
guidelines notably set forth by the
Practice knowledge area (KA) is
applicable professional society. For
concerned with the knowledge, skills, and
example, the Association for
attitudes that software engineers must
possess to practice software engineering in Computing Machinery (ACM) and IEEE
Computer Society (IEEE CS) have
a professional, responsible, and ethical
established a Software Engineering Code
manner. Because of the widespread
of Ethics and Professional Practice. Both
applications of software products in social
the British Computer Society (BCS) and
and personal life, the quality of software
the International Federation for
products can have profound impact on our
Information Processing (IFIP) have
personal well-being and societal harmony.
established similar professional practice
Software engineers must handle unique
standards. ISO/IEC and IEEE have further
engineering problems, producing software
provided internationally accepted software
with known characteristics and reliability. engineering standards (see Appendix B of
This requirement calls for software this Guide). IEEE CS has established two
engineers who possess a proper set of international certification programs
(CSDA, CSDP) and a corresponding ofKnowledge(SWEBOK Guide). All of

GuidetotheSoftwareEngineeringBody these are
11-1
Figure 11.1. Breakdown of Topics for the Software Engineering Professional Practice KA
elements that lay the foundation for of the BREAKDOWN OF TOPICS FOR
professional practice of software SOFTWARE ENGINEERING
engineering. PROFESSIONAL PRACTICE
The Software Engineering Professional In other countries, however, the

Practice accreditation process is independent of
KAs breakdown of topics is shown in government and performed by private
Figure membership associations. For example, in
11.1. The subareas presented in this KA the United States, engineering
are professionalism, group dynamics and accreditation is performed by an
psychology, and communication skills. organization known as ABET. An
organization known as CSAB serving as a
1. Professionalism participating body of ABET is the lead
society within ABET for the accreditation
A software engineer displays of degree programs in software
professionalism notably through engineering.
adherence to codes of ethics and While the process of accreditation may
professional conduct and to standards and be different for each country and
practices that are established by the jurisdiction, the general meaning is the
engineers professional community. same. For an institutions course of study
The professional community is often to be accredited means that the
represented by one or more professional accreditation body recognizes an
societies; those societies publish codes of educational institution as maintaining
ethics and professional conduct as well as standards that qualify the graduates for
criteria for admittance to the community. admission to higher or more specialized
Those criteria form the basis for institutions or for professional practice
accreditation and licensing activities and [2].
may be used as a measure to determine
engineering competence or negligence. 1.1.2. Certification
1.1. Accreditation,Certification,and Certification refers to the confirmation of

Licensing a persons particular characteristics. A
[1*, c1s4.1, common type of certification is
professional certification, where a person
c1s5.1c1s5.4] 1.1.1. Accreditation is certified as being able to complete an
activity in a certain discipline at a stated
Accreditation is a process to certify the level of competency. Professional
competency, authority, or credibility of an certification also can also verify the
organization. Accredited schools or holders ability to meet professional
programs are assured to adhere to standards and to apply professional
particular standards and maintain certain judgment in solving or addressing
qualities. In many countries, the basic problems. Professional certification can
means by which engineers acquire also involve the verification of prescribed
knowledge is through completion of an knowledge, the mastering of best practice
accredited course of study. Often, and proven methodologies, and the
engineering accreditation is performed by amount of professional experience.
a government organization, such as the An engineer usually obtains certification
ministry of education. Such countries with by passing an examination in conjunction
government accreditations include China, with other experience-based criteria. These
France, Germany, Israel, Italy, and Russia. examinations are often administered by
nongovernmental organizations, such as 1.2. CodesofEthicsandProfessional

professional societies. Conduct
In software engineering, certification [1*, c1s6c1s9] [3*, c8] [4*, c1s2] [5*,
testifies to ones qualification as a software c33]
engineer. For example, the IEEE CS has [6*]
enacted two certification programs (CSDA
and CSDP) designed to confirm a software Codes of ethics and professional conduct
engineers knowledge of standard software comprise the values and behavior that an
engineering practices and to advance ones engineers professional practice and
career. A lack of certification does not decisions should embody.
exclude the individual from working as a The professional community establishes
software engineer. Currently certification codes of ethics and professional conduct.
in software engineering is completely They exist in the context of, and are
voluntary. In fact, most software engineers adjusted to agree with, societal norms and
are not certified under any program. local laws. Therefore, codes of ethics and
professional conduct present guidance in
1.1.3. Licensing the face of conflicting imperatives.
Once established, codes of ethics and
Licensing is the action of giving a professional conduct are enforced by the
person the authorization to perform certain profession, as represented by professional
kinds of activities and take responsibility societies or by a statutory body.
for resultant engineering products. The Violations may be acts of commission,
noun license refers to both that such as concealing inadequate work,
authorization and the document recording disclosing confidential information,
that authorization. Governmental falsifying information, or misrepresenting
authorities or statutory bodies usually ones abilities. They may also occur
issue licenses. through omission, including failure to
Obtaining a license to practice requires disclose risks or to provide important
not only that an individual meets a certain information, failure to give proper credit
standard, but also that they do so with a or to acknowledge references, and failure
certain ability to practice or operate. to represent client interests. Violations of
Sometimes there is an entry-level codes of ethics and professional conduct
requirement which sets the minimum skills may result in penalties and possible
and capabilities to practice, but as the expulsion from professional status.
professional moves through his or her A code of ethics and professional
career, the required skills and capabilities conduct for software engineering was
change and evolve. approved by the ACM Council and the
In general, engineers are licensed as a IEEE CS Board of Governors in 1999
means of protecting the public from [6*]. According to the short version of this
unqualified individuals. In some countries, code:
no one can practice as a professional
engineer unless licensed; or further, no Software engineers shall commit
company may offer engineering services themselves to making the analysis,
unless at least one licensed engineer is specification, design, development,
employed there. testing and maintenance of software
a beneficial and respected
profession. In accordance with their 1.4. NatureandRoleofSoftware

commitment to the health, safety EngineeringStandards
and welfare of the public, software [1*, c5s3.2, c10s2.1] [5*, c32s6] [7*,
engineers shall adhere to the eight c1s2]
principles concerning the public,
client and employer, product, Software engineering standards cover a
judgment, management, profession, remarkable variety of topics. They provide
colleagues, and self, respectively. guidelines for the practice of software
Since standards and codes of ethics and engineering and processes to be used
professional conduct may be introduced, during development, maintenance, and
modified, or replaced at any time, support of software. By establishing a
individual software engineers bear the consensual body of knowledge and
responsibility for their own continuing experience, software engineering
study to stay current in their professional standards establish a basis upon which
practice. further guidelines may be developed.
Appendix B of this Guide provides
1.3. NatureandRoleofProfessional guidance on IEEE and ISO/ IEC software
Societies engineering standards that support the
[1*, c1s1c1s2] [4*, c1s2] [5*, c35s1] knowledge areas of this Guide.
The benefits of software engineering
Professional societies are comprised of a standards are many and include improving
mix of practitioners and academics. These software quality, helping avoid errors,
societies serve to define, advance, and protecting both software producers and
regulate their corresponding professions. users, increasing professional discipline,
Professional societies help to establish and helping technology transition.
professional standards as well as codes of
ethics and professional conduct. For this 1.5. EconomicImpactofSoftware
reason, they also engage in related [3*, c10s8] [4*, c1s1.1] [8*, c1]
activities, which include
Software has economic effects at the
establishing and promulgating a body individual, business, and societal levels.
of generally accepted knowledge; Software success may be determined by
accrediting, certifying, and licensing; the suitability of a product for a
dispensing disciplinary actions; recognized problem as well as by its
advancing the profession through effectiveness when applied to that
conferences, training, and problem.
publications. At the individual level, an engineers
continuing employment may depend on
Participation in professional societies their ability and willingness to interpret
assists the individual engineer in and execute tasks in meeting customers or
maintaining and sharpening their employers needs and expectations. The
professional knowledge and relevancy and customer or employers financial situation
in expanding and maintaining their may in turn be positively or negatively
professional network. 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 precondition to work. These agreements

more effective organizations. Moreover, typically apply to information the software
organizations that acquire or provide engineer could only gain through
successful software may be a boon to the association with the customer. The terms
society in which they operate by providing of these agreements may extend past
both employment and improved services. termination of the association.
However, the development or acquisition Another concern is IP ownership. Rights
costs of software can also equate to those to software engineering assetsproducts,
of any major acquisition. innovations, inventions, discoveries, and
At the societal level, direct impacts of ideasmay reside with the employer or
software success or failure include or customer, either under explicit contract
exclude accidents, interruptions, and loss terms or relevant laws, if those assets are
of service. Indirect impacts include the obtained during the term of the software
success or failure of the organization that engineers relationship with that employer
acquired or produced the software, or customer. Contracts differ in the
increased or decreased societal ownership of assets created using non-
productivity, harmonious or disruptive employer-owned equipment or
social order, and even the saving or loss of information.
property and life. Finally, contracts can also specify
among other elements the location at
1.6. EmploymentContracts which work is to be performed; standards
[1*, c7] to which that work will be held; the
system configuration to be used for
Software engineering services may be development; limitations of the software
provided under a variety of client-engineer engineers and employers liability; a
relationships. The software engineering communication matrix and/or escalation
work may be solicited as company-to- plan; and administrative details such as
customer supplier, engineerto-customer rates, frequency of compensation, working
consultancy, direct hire, or even hours, and working conditions.
volunteering. In all of these situations, the
customer and supplier agree that a product 1.7.LegalIssues
or service will be provided in return for [1*, c6, c11] [3*, c5s3c5s4] [9*, c1s10]
some sort of consideration. Here, we are
most concerned with the engineer-to- Legal issues surrounding software
customer arrangement and its attendant engineering professional practice notably
agreements or contracts, whether they are include matters related to standards,
of the direct-hire or consultant variety, and trademarks, patents, copyrights, trade
the issues they typically address. secrets, professional liability, legal
A common concern in software requirements, trade compliance, and
engineering contracts is confidentiality. cybercrime. It is therefore beneficial to
Employers derive commercial advantage possess knowledge of these issues and
from intellectual property, so they strive to their applicability.
protect that property from disclosure. Legal issues are jurisdictionally based;
Therefore, software engineers are often software engineers must consult attorneys
required to sign non-disclosure (NDA) or who specialize in the type and jurisdiction
intellectual property (IP) agreements as a of any identified legal issues.
1.7.1.Standards 1.7.3.Patents
Software engineering standards establish Patents protect an inventors right to

guidelines for generally accepted practices manufacture and sell an idea. A patent
and minimum requirements for products consists of a set of exclusive rights granted
and services provided by a software by a sovereign government to an
engineer. Appendix B of this Guide individual, group of individuals, or
provides guidance on software organization for a limited period of time.
engineering standards that are applicable Patents are an old form of idea-ownership
to each KA. protection and date back to the 15th
Standards are valuable sources of century.
requirements and assistance during the Application for a patent entails careful
everyday conduct of software engineering records of the process that led to the
activities. Adherence to standards invention. Patent attorneys are helpful in
facilitates discipline by enumerating writing patent disclosure claims in a
minimal characteristics of products and manner most likely to protect the software
practice. That discipline helps to mitigate engineers rights.
subconscious assumptions or Note that, if inventions are made during
overconfidence in a design. For these the course of a software engineering
reasons, organizations performing contract, ownership may belong to the
software engineering activities often employer or customer or be jointly held,
include conformance to standards as part rather than belong to the software
of their organizational policies. Further, engineer.
adherence to standards is a major There are rules concerning what is and
component of defense from legal action or is not patentable. In many countries,
from allegations of malpractice. software code is not patentable, although
software algorithms may be. Existing and
1.7.2.Trademarks filed patent applications can be searched at
WIPO.
A trademark relates to any word, name,
symbol, or device that is used in business 1.7.4.Copyrights
transactions. It is used to indicate the
source or origin of the goods [2]. Most governments in the world give
Trademark protection protects names, exclusive rights of an original work to its
logos, images, and packaging. However, if creator, usually for a limited time, enacted
a name, image, or other trademarked asset as a copyright. Copyrights protect the way
becomes a generic term, then trademark an idea is presentednot the idea itself.
protection is nullified. For example, they may protect the
The World Intellectual Property particular wording of an account of an
Organization (WIPO) is the authority that historical event, whereas the event itself is
frames the rules and regulations on not protected. Copyrights are long-term
trademarks. WIPO is the United Nations and renewable; they date back to the 17th
agency dedicated to the use of intellectual century.
property as a means of stimulating
innovation and creativity. 1.7.5.TradeSecrets
In many countries, an intellectual asset who is harmed to recover their loss even if
such as a formula, algorithm, process, no guarantees were made. Because it is
design, method, pattern, instrument, or difficult to measure the suitability or
compilation of information may be safety of software, failure to take due care
considered a trade secret, provided that can be used to prove negligence on the
these assets are not generally known and part of software engineers. A defense
may provide a business some economic against such an allegation is to show that
advantage. The designation of trade standards and generally accepted practices
secret provides legal protection if the were followed in the development of the
asset is stolen. This protection is not product.
subject to a time limit. However, if
another party derives or discovers the 1.7.7.LegalRequirements
same asset legally, then the asset is no
longer protected and the other party will Software engineers must operate within
also possess all rights to use it. the confines of local, national, and
international legal frameworks. Therefore,
1.7.6.ProfessionalLiability software engineers must be aware of legal
requirements for
It is common for software engineers to be
concerned with matters of professional registration and licensingincluding
liability. As an individual provides examination, education, experience,
services to a client or employer, it is vital and training requirements;
to adhere to standards and generally contractual agreements;
accepted practices, thereby protecting noncontractual legalities, such as those
against allegations or proceedings of or governing liability;
related to malpractice, negligence, or Basic information on the international
incompetence. legal framework can be accessed from
For engineers, including software the World Trade Organization (WTO).
engineers, professional liability is related 1.7.8.TradeCompliance
to product liability. Under the laws and
rules governing in their jurisdiction, All software professionals must be aware
engineers may be held to account for of legal restrictions on import, export, or
failing to fully and conscientiously follow reexport of goods, services, and
recommended practice; this is known as technology in the jurisdictions in which
negligence. They may also be subject to they work. The considerations include
laws governing strict liability and either export controls and classification, transfer
implied or express warranty, where, by of goods, acquisition of necessary
selling the product, the engineer is held to governmental licenses for foreign use of
warrant that the product is both suitable hardware and software, services and
and safe for use. In some countries (for technology by sanctioned nation,
example, in the US), privity (the idea enterprise or individual entities, and
that one could only sue the person selling import restrictions and duties. Trade
the product) is no longer a defense against experts should be consulted for detailed
liability actions. compliance guidance.
Legal suits for liability can be brought
under tort law in the US allowing anyone 1.7.9.Cybercrime
Cybercrime refers to any crime that relevant facts,

involves a computer, computer software, significant risks and tradeoffs, and
computer networks, or embedded software warnings of undesirable or dangerous
controlling a system. The computer or consequences from use or misuse of
software may have been used in the the software.
commission of a crime or it may have
been the target. This category of crime Software engineers should avoid
includes fraud, unauthorized access, spam,
obscene or offensive content, threats, certifying or approving unacceptable
harassment, theft of sensitive personal products, disclosing confidential
data or trade secrets, and use of one information, or
computer to damage or infiltrate other falsifying facts or data.
networked computers and automated
system controls. In addition, software engineers and their
Computer and software users commit managers should notably provide the
fraud by altering electronic data to following documentation for use by other
facilitate illegal activity. Forms of elements of the software development
unauthorized access include hacking, organization:
eavesdropping, and using computer
systems in a way that is concealed from software requirements specifications,
their owners. software design documents, details on
Many countries have separate laws to the software engineering tools used,
cover cybercrimes, but it has sometimes software test specifications and
been difficult to prosecute cybercrimes results, and details on the adopted
due to a lack of precisely framed statutes. software engineering methods;
The software engineer has a professional problems encountered during the
obligation to consider the threat of development process.
cybercrime and to understand how the
For external stakeholders (customer,
software system will protect or endanger
users, others) software documentation
software and user information from
should notably provide
accidental or malicious access, use,
modification, destruction, or disclosure.
information needed to determine if the
software is likely to meet the
1.8.Documentation
customers and users needs,
[1*, c10s5.8] [3*, c1s5] [5*, c32]
description of the safe, and unsafe, use
Providing clear, thorough, and accurate of the software,
documentation is the responsibility of each description of the protection of
software engineer. The adequacy of sensitive information created by or
documentation is judged by different stored using the software, and
criteria based on the needs of the various clear identification of warnings and
stakeholder audiences. critical procedures.
Good documentation complies with
Use of software may include
accepted standards and guidelines. In
particular, software engineers should installation, operation, administration, and
document performance of other functions by various
groups of users and support personnel. If
the customer will acquire ownership of the the solution that most nearly meets those
software source code or the right to goals; this means that the way the goals
modify the code, the software engineer are stated is critically important.
should provide documentation of the Design goals may include minimization
functional specifications, the software of monetary cost and maximization of
design, the test suite, and the necessary reliability, performance, or some other
operating environment for the software. criteria on a wide range of dimensions.
The minimum length of time documents However, it is difficult to formulate a
should be kept is the duration of the tradeoff analysis of cost against risk,
software products life cycle or the time especially where primary production and
required by relevant organizational or secondary risk-based costs must be traded
regulatory requirements. against each other.
A software engineer must conduct a
1.9.TradeoffAnalysis tradeoff analysis in an ethical manner
[3*, c1s2, c10] [9*, c9s5.10] notably by being objective and impartial
when selecting criteria for comparison of
Within the practice of software alternative problem solutions and when
engineering, a software engineer often has assigning weights or importance to these
to choose between alternative problem criteria. Any conflict of interest must be
solutions. The outcome of these choices is disclosed up front.
determined by the software engineers
professional evaluation of the risks, costs, 2.Group Dynamics and Psychology
and benefits of alternatives, in cooperation
with stakeholders. The software engineers Engineering work is very often conducted
evaluation is called tradeoff analysis. in the context of teamwork. A software
Tradeoff analysis notably enables the engineer must be able to interact
identification of competing and cooperatively and constructively with
complementary software requirements in others to first determine and then meet
order to prioritize the final set of both needs and expectations. Knowledge
requirements defining the software to be of group dynamics and psychology is an
constructed (see Requirements asset when interacting with customers,
Negotiation in the Software Requirements coworkers, suppliers, and subordinates to
KA and Determination and Negotiation of solve software engineering problems.
Requirements in the Software Engineering
Management KA). 2.1. DynamicsofWorkingin
In the case of an ongoing software Teams/Groups
development project that is late or over [3*, c1s6] [9*, c1s3.5, c10]
budget, tradeoff analysis is often
conducted to decide which software Software engineers must work with others.
requirements can be relaxed or dropped On one hand, they work internally in
given the effects thereof. engineering teams; on the other hand, they
A first step in a tradeoff analysis is work with customers, members of the
establishing design goals (see Engineering public, regulators, and other stakeholders.
Design in the Engineering Foundations Performing teamsthose that demonstrate
KA) and setting the relative importance of consistent quality of work and progress
those goals. This permits identification of toward goalsare cohesive and possess a
cooperative, honest, and focused In general, an individuals (in particular,

atmosphere. Individual and team goals are a software engineers) ability to
aligned so that the members naturally decompose a problem and creatively
commit to and feel ownership of shared develop a solution can be inhibited by
outcomes.
Team members facilitate this need for more knowledge,
atmosphere by being intellectually honest, subconscious assumptions,
making use of group thinking, admitting volume of data,
ignorance, and acknowledging mistakes. fear of failure or consequence of
They share responsibility, rewards, and failure,
workload fairly. They take care to culture, either application
communicate clearly, directly to each domain or organizational,
other and in documents, as well as in lack of ability to express the problem,
source code, so that information is perceived working atmosphere, and
accessible to everyone. Peer reviews about emotional status of the individual.
work products are framed in a constructive
and nonpersonal way (see Reviews and The impact of these inhibiting factors
Audits in the Software Quality KA). This can be reduced by cultivating good
allows all the members to pursue a cycle problem solving habits that minimize the
of continuous improvement and growth impact of misleading assumptions. The
without personal risk. In general, members ability to focus is vital, as is intellectual
of cohesive teams demonstrate respect for humility: both allow a software engineer
each other and their leader. to suspend personal considerations and
One point to emphasize is that software consult with others freely, which is
engineers must be able to work in especially important when working in
multidisciplinary environments and in teams.
varied application domains. Since today There is a set of basic methods
software is everywhere, from a phone to a engineers use to facilitate problem solving
car, software is impacting peoples lives (see Problem Solving Techniques in the
far beyond the more traditional concept of Computing Foundations KA). Breaking
software made for information down problems and solving them one
management in a business environment. piece at a time reduces cognitive overload.
Taking advantage of professional curiosity
2.2. IndividualCognition and pursuing continuous professional
[3*, c1s6.5] [5*, c33] development through training and study
add skills and knowledge to the software
Engineers desire to solve problems. The engineers portfolio; reading, networking,
ability to solve problems effectively and and experimenting with new tools,
efficiently is what every engineer strives techniques, and methods are all valid
for. However, the limits and processes of means of professional development.
individual cognition affect problem
solving. In software engineering, notably 2.3. DealingwithProblem
due to the highly abstract nature of Complexity
software itself, individual cognition plays [3*, c3s2] [5*, c33]
a very prominent role in problem solving.
Many, if not most, software engineering feedback on evolving or new requirements

problems are too complex and difficult to as well problem reports so that the
address as a whole or to be tackled by software may be extended and improved.
individual software engineers. When such Therefore, it is vital to maintain open
circumstances arise, the usual means to and productive communication with
adopt is teamwork and problem stakeholders for the duration of the
decomposition (see Problem Solving software products lifetime.
Techniques in the Computing Foundations
KA). 2.5. DealingwithUncertaintyand
Teams work together to deal with Ambiguity
complex and large problems by sharing [4*, c24s4, c26s2] [9*, c9s4]
burdens and drawing upon each others
knowledge and creativity. When software As with engineers of other fields, software
engineers work in teams, different views engineers must often deal with and resolve
and abilities of the individual engineers uncertainty and ambiguities while
complement each other and help build a providing services and developing
solution that is otherwise difficult to come products. The software engineer must
by. Some specific teamwork examples to attack and reduce or eliminate any lack of
software engineering are pair clarity that is an obstacle to performing
programming (see Agile Methods in the work.
Software Engineering Models and Often, uncertainty is simply a reflection
Methods KA) and code review (see of lack of knowledge. In this case,
Reviews and Audits in the Software investigation through recourse to formal
Quality KA). sources such as textbooks and professional
journals, interviews with stakeholders, or
2.4. InteractingwithStakeholders consultation with teammates and peers can
[9*, c2s3.1] overcome it.
When uncertainty or ambiguity cannot
Success of a software engineering be overcome easily, software engineers or
endeavor depends upon positive organizations may choose to regard it as a
interactions with stakeholders. They project risk. In this case, work estimates or
should provide support, information, and pricing are adjusted to mitigate the
feedback at all stages of the software life anticipated cost of addressing it (see Risk
cycle process. For example, during the Management in the Software Engineering
early stages, it is critical to identify all Management KA).
stakeholders and discover how the product
will affect them, so that sufficient 2.6. DealingwithMulticultural
definition of the stakeholder requirements Environments
can be properly and completely captured. [9*, c10s7]
During development, stakeholders may
provide feedback on specifications and/or Multicultural environments can have an
early versions of the software, change of impact on the dynamics of a group. This is
priority, as well as clarification of detailed especially true when the group is
or new software requirements. Last, during geographically separated or
software maintenance and until the end of communication is infrequent, since such
product life, stakeholders provide separation elevates the importance of each
contact. Intercultural communication is acceptance and safe product usage depend

even more difficult if the difference in on the provision of relevant training and
time zones make oral communication less documentation. It follows that the
frequent. software engineers own career success is
Multicultural environments are quite affected by the ability to consistently
prevalent in software engineering, perhaps provide oral and written communication
more than in other fields of engineering, effectively and on time.
due to the strong trend of international
outsourcing and the easy shipment of 3.1. Reading,Understanding,and
software components instantaneously Summarizing
across the globe. For example, it is rather [5*, c33s3]
common for a software project to be
divided into pieces across national and Software engineers are able to read and
cultural borders, and it is also quite understand technical material. Technical
common for a software project team to material includes reference books,
consist of people from diverse cultural manuals, research papers, and program
backgrounds. source code.
For a software project to be a success, Reading is not only a primary way of
team members must achieve a level of improving skills, but also a way of
tolerance, acknowledging that some rules gathering information necessary for the
depend on societal norms and that not all completion of engineering goals. A
societies derive the same solutions and software engineer sifts through
expectations. accumulated information, filtering out the
This tolerance and accompanying pieces that will be most helpful.
understanding can be facilitated by the Customers may request that a software
support of leadership and management. engineer summarize the results of such
More frequent communication, including information gathering for them,
face-to-face meetings, can help to mitigate simplifying or explaining it so that they
geographical and cultural divisions, may make the final choice between
promote cohesiveness, and raise competing solutions.
productivity. Also, being able to Reading and comprehending source
communicate with teammates in their code is also a component of information
native language could be very beneficial. gathering and problem solving. When
3. Communication Skills modifying, extending, or rewriting
software, it is critical to understand both
It is vital that a software engineer its implementation directly derived from
communicate well, both orally and in the presented code and its design, which
reading and writing. Successful attainment must often be inferred.
of software requirements and deadlines
depends on developing clear 3.2. Writing
understanding between the software [3*, c1s5]
engineer and customers, supervisors,
coworkers, and suppliers. Optimal Software engineers are able to produce
problem solving is made possible through written products as required by customer
the ability to investigate, comprehend, and requests or generally accepted practice.
summarize information. Customer product These written products may include source
code, software project plans, software addition, the use of electronic information
requirement documents, risk analyses, stores, accessible to all team members, for
software design documents, software test organizational policies, standards,
plans, user manuals, technical reports and common engineering procedures, and
evaluations, justifications, diagrams and project-specific information, can be most
charts, and so forth. beneficial.
Writing clearly and concisely is very Some software engineering teams focus
important because often it is the primary on face-to-face interaction and promote
method of communication among relevant such interaction by office space
parties. In all cases, written software arrangement. Although private offices
engineering products must be written so improve individual productivity,
that they are accessible, understandable colocating team members in physical or
and relevant for their intended audience(s). virtual forms and providing communal
work areas is important to collaborative
3.3. TeamandGroupCommunication efforts.
[3*, c1s6.8] [4*, c22s3] [5*, c27s1]
[9*, c10s4] 3.4. PresentationSkills
[3*, c1s5] [4*, c22] [9*, c10s7c10s8]
Effective communication among team and
group members is essential to a Software engineers rely on their
collaborative software engineering effort. presentation skills during software life
Stakeholders must be consulted, decisions cycle processes. For example, during the
must be made, and plans must be software requirements phase, software
generated. The greater the number of team engineers may walk customers and
and group members, the greater the need teammates through software requirements
to communicate. and conduct formal requirements reviews
The number of communication paths, (see Requirement Reviews in the Software
however, grows quadratically with the Requirements KA). During and after
addition of each team member. Further, software design, software construction,
team members are unlikely to and software maintenance, software
communicate with anyone perceived to be engineers lead reviews, product
removed from them by more than two walkthroughs (see Review and Audits in
degrees (levels). This problem can be the Software Quality KA), and training.
more serious when software engineering All of these require the ability to present
endeavors or organizations are spread technical information to groups and solicit
across national and continental borders. ideas or feedback.
Some communication can be The software engineers ability to
accomplished in writing. Software convey concepts effectively in a
documentation is a common substitute for presentation therefore influences product
direct interaction. Email is another but, acceptance, management, and customer
although it is useful, it is not always support; it also influences the ability of
enough; also, if one sends too many stakeholders to comprehend and assist in
messages, it becomes difficult to identify the product effort. This knowledge needs
the important information. Increasingly, to be archived in the form of slides,
organizations are using enterprise knowledge writeup, technical whitepapers,
collaboration tools to share information. In
and any other material utilized for

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

c24s4,
Uncertainty and c9s4
c26s2
Ambiguity
2.6. Dealing with
Multicultural c10s7
Environments
3. Communication
Skills
3.1. Reading,
Understanding, and c33s3
Summarizing
3.2. Writing c1s5
3.3. Team and Group
c1s6.8 c22s3 c27s1 c10s4
Communication
3.4. Presentation c10s7
c1s5 c22
Skills c10s8
FURTHER READINGS Gerald M. Weinberg, ThePsychologyof
Computer Programming [10].
This was the first major book to address Software Engineering Ethics and
programming as an individual and team Professional Practices, Software
effort and became a classic in the field. Engineering Code of Ethics and
Professional Practice (Version 5.2),
Kinney and Lange, P.A., Intellectual 1999;
PropertyLawforBusinessLawyers www.acm.org/serving/se/code.htm.
[11].
[7*] J.W. Moore, TheRoadMapto
This book covers IP laws in the US. It not Software
only talks about what the IP law is; it also Engineering:AStandards-Based
explains why it looks the way it does. Guide, Wiley-IEEE Computer Society
REFERENCES Press, 2006.
[1*] F. Bott et al., ProfessionalIssuesin [8*] S. Tockey, ReturnonSoftware:

SoftwareEngineering, 3rd ed., Taylor MaximizingtheReturnonYour
& Francis, 2000. SoftwareInvestment, Addison-Wesley,
2004.
[2] Merriam-WebstersCollegiate
Dictionary, 11th ed., 2003. [9*] R.E. Fairley, ManagingandLeading
SoftwareProjects, Wiley-IEEE
[3*] G. Voland, EngineeringbyDesign, Computer Society Press, 2009.
2nd ed., Prentice Hall, 2003.
[10] G.M. Weinberg, ThePsychologyof
[4*] I. Sommerville, Software ComputerProgramming:Silver
Engineering, 9th ed., Addison-Wesley, AnniversaryEdition, Dorset House,
2011. 1998.
[5*] S. McConnell, CodeComplete, 2nd [11] Kinney and Lange, P.A., Intellectual
ed., Microsoft Press, 2004. PropertyLawforBusinessLawyers,
Thomson West, 2013.
[6*] IEEE CS/ACM Joint Task Force on
CHAPTER 12 SOFTWARE ENGINEERING
ECONOMICS
ACRONYMS SPLC Software Product Life Cycle

EVM Earned Value Management ROI Return on Investment
IRR Internal Rate of Return ROCE Return on Capital Employed
Minimum Acceptable Rate of TCO Total Cost of Ownership
MARR
Return INTRODUCTION
SDLC Software Development Life Cycle
Software engineering economics is about organizations independent of focus,

making decisions related to software product and service portfolio, or capital
engineering in a business context. The ownership and taxation restrictions.
success of a software product, service, and Decisions like Should we use a specific
solution depends on good business component? may look easy from a
management. Yet, in many companies and technical perspective, but can have serious
organizations, software business implications on the business viability of a
relationships to software development and software project and the resulting product.
engineering remain vague. This Often engineers wonder whether such
knowledge area (KA) provides an concerns apply at all, as they are only
overview on software engineering engineers. Economic analysis and
economics. decision-making are important engineering
Economics is the study of value, costs, considerations because engineers are
resources, and their relationship in a given capable of evaluating decisions both
context or situation. In the discipline of technically and from a business
software engineering, activities have costs, perspective. The contents of this
but the resulting software itself has knowledge area are important topics for
economic attributes as well. Software software engineers to be aware of even if
engineering economics provides a way to they are never actually involved in
study the attributes of software and concrete business decisions; they will have
software processes in a systematic way a well-rounded view of business issues
that relates them to economic measures. and the role technical considerations play
These economic measures can be weighed in making business decisions. Many
and analyzed when making decisions that engineering proposals and decisions, such
are within the scope of a software as make versus buy, have deep intrinsic
organization and those within the economic impacts that should be
integrated scope of an entire producing or considered explicitly.
acquiring business. This KA first covers the foundations,
Software engineering economics is key terminology, basic concepts, and
concerned with aligning software technical common practices of software engineering
decisions with the business goals of the economics to indicate how decision-
organization. In all types of organizations making in software engineering includes,
be it for-profit, notfor-profit, or or should include a business perspective. It
governmentalthis translates into then provides a life cycle perspective,
sustainably staying in business. In for- highlights risk and uncertainty
profit organizations this additionally management, and shows how economic
relates to achieving a tangible return on analysis methods are used. Some practical
the invested capital both assets and considerations finalize the knowledge
capital employed. This KA has been area.
formulated in a way to address all types of
12-1
Figure 12.1. Breakdown of Topics for the Software Engineering Economics KA

BREAKDOWN OF TOPICS FOR measure financial performance, such
SOFTWARE ENGINEERING as cash flow and ROI (see section 4.3,
ECONOMICS Return on Investment), and take
corrective actions in case of deviation
The breakdown of topics for the Software from objectives and strategy.
Engineering Economics KA is shown in
Figure 12.1. 1.2. Accounting
[1*, c15]
1. Software Engineering Economics
Fundamentals Accounting is part of finance. It allows
people whose money is being used to run
1.1. Finance an organization to know the results of their
[1*, c2] investment: did they get the profit they
were expecting? In for-profit
Finance is the branch of economics organizations, this relates to the tangible
concerned with issues such as allocation, ROI (see section 4.3, Return on
management, acquisition, and investment Investment), while in not-for-profit and
of resources. Finance is an element of governmental organizations as well as
every organization, including software for-profit organizations, it translates into
engineering organizations. sustainably staying in business. The
The field of finance deals with the primary role of accounting is to measure
concepts of time, money, risk, and how the organizations actual financial
they are interrelated. It also deals with performance and to communicate financial
how money is spent and budgeted. information about a business entity to
Corporate finance is concerned with stakeholders, such as shareholders,
providing the funds for an organizations financial auditors, and investors.
activities. Generally, this involves Communication is generally in the form of
balancing risk and profitability, while financial statements that show in money
attempting to maximize an organizations terms the economic resources to be
wealth and the value of its stock. This controlled. It is important to select the
holds primarily for for-profit right information that is both relevant and
organizations, but also applies to not-for- reliable to the user. Information and its
profit organizations. The latter needs timing are partially governed by risk
finances to ensure sustainability, while not management and governance policies.
targeting tangible profit. To do this, an Accounting systems are also a rich source
organization must of historical data for estimating.
identify organizational goals, time 1.3. Controlling

horizons, risk factors, tax [1*, c15]
considerations, and financial
constraints; Controlling is an element of finance and
identify and implement the accounting. Controlling involves
appropriate business strategy, such as measuring and correcting the performance
which portfolio and investment of finance and accounting. It ensures that
decisions to take, how to manage cash an organizations objectives and plans are
flow, and where to get the funding; accomplished. Controlling cost is a
specialized branch of controlling used to effect, the complete financial picture of

detect variances of actual costs from that proposal. How much money goes out?
planned costs. When does it go out? How much money
comes in? When does it come in? Simply,
1.4. CashFlow if the cash flow stream for Proposal A is
[1*, c3] more desirable than the cash flow stream
for Proposal B, thenall other things
Cash flow is the movement of money into being equalthe organization is better off
or out of a business, project, or financial carrying out Proposal A than Proposal B.
product over a given period. The concepts Thus, the cash flow stream is an important
of cash flow instances and cash flow input for investment decision-making. A
streams are used to describe the business cash flow instance is a specific amount of
perspective of a proposal. To make a money flowing into or out of the
meaningful business decision about any organization at a specific time as a direct
Figure 12.2. A Cash Flow Diagram

specific proposal, that proposal will need result of some activity.
to be evaluated from a business A cash flow diagram is a picture of a
perspective. In a proposal to develop and cash flow stream. It gives the reader a
launch product X, the payment for new quick overview of the financial picture of
software licenses is an example of an the subject organization or project. Figure
outgoing cash flow instance. Money 12.2 shows an example of a cash flow
would need to be spent to carry out that diagram for a proposal.
proposal. The sales income from product
X in the 11th month after market launch is 1.5. Decision-MakingProcess
an example of an incoming cash flow [1*, c2, c4]
instance. Money would be coming in
because of carrying out the proposal. If we assume that candidate solutions
The term cashflowstream refers to the solve a given technical problem equally
set of cash flow instances over time that well, why should the organization care
are caused by carrying out some given which one is chosen? The answer is that
proposal. The cash flow stream is, in there is usually a large difference in the
costs and incomes from the different more fluid. Sometimes the steps can be
solutions. A commercial, off-the-shelf, done in a different order and often several
objectrequest broker product might cost a of the steps can be done in parallel. The
few thousand dollars, but the effort to important thing is to be sure that none of
develop a homegrown service that gives the steps are skipped or curtailed. Its also
the same functionality could easily cost important to understand that this same
several hundred times that amount. process applies at all levels of decision
If the candidate solutions all adequately making: from a decision as big as
solve the problem from a technical determining whether a software project
perspective, then the selection of the most should be done at all, to a deciding on an
appropriate alternative should be based on algorithm or data structure to use in a
commercial factors such as optimizing software module. The difference is how
total cost of ownership (TCO) or financially significant the decision is and,
maximizing the short-term return on therefore, how much effort should be
investment (ROI). Life cycle costs such as invested in making that decision. The
defect correction, field service, and project-level decision is financially
support duration are also relevant significant and probably warrants a
considerations. These costs need to be relatively high level of effort to make the
factored in when selecting among decision. Selecting an algorithm is often
acceptable technical approaches, as they much less financially significant and
are part of the lifetime ROI (see section warrants a much lower level of effort to
4.3, Return on Investment). make the decision, even though the same
A systematic process for making basic decision-making process is being
decisions will achieve transparency and used.
allow later justification. Governance More often than not, an organization
criteria in many organizations demand could carry out more than one proposal if
selection from at least two alternatives. A it wanted to, and usually there are
systematic process is shown in Figure important relationships among proposals.
12.3. It starts with a business challenge at Maybe Proposal Y can only be carried out
hand and describes the steps to identify if Proposal X is also carried out. Or maybe
alternative solutions, define selection Proposal P cannot be carried out if
criteria, evaluate the solutions, implement Proposal Q is carried out, nor could Q be
one selected solution, and monitor the carried out if P were. Choices are much
performance of that solution. easier to make when there are mutually
Figure 12.3 shows the process as mostly exclusive pathsfor example, either A or
stepwise and serial. The real process is B or C or whatever is chosen. In preparing
Figure 12.3. The Basic Business Decision-Making Process

decisions, it is recommended to turn any the inflation rate is over a couple of

given set of proposals, along with their percentage points annually, it can cause
various interrelationships, into a set of noticeable changes in the value of a
mutually exclusive alternatives. The proposal. The present time value therefore
choice can then be made among these needs to be adjusted for inflation rates and
alternatives. also for exchange rate fluctuations.
1.6. Valuation
[1*, c5, c8] 1.8. Depreciation
[1*, c14]
In an abstract sense, the decision-making
processbe it financial decision making Depreciation involves spreading the cost
or other is about maximizing value. The of a tangible asset across a number of time
alternative that maximizes total value periods; it is used to determine how
should always be chosen. A financial basis investments in capitalized assets are
for value-based comparison is comparing charged against income over several years.
two or more cash flows. Several bases of Depreciation is an important part of
comparison are available, including determining after-tax cash flow, which is
critical for accurately addressing profit
present worth and taxes. If a software product is to be
future worth sold after the development costs are
annual equivalent incurred, those costs should be capitalized
internal rate of return (discounted) and depreciated over subsequent time
payback period. periods. The depreciation expense for each
time period is the capitalized cost of
Based on the time-value of money, two developing the software divided across the
or more cash flows are equivalent only number of periods in which the software
when they equal the same amount of will be sold. A software project proposal
money at a common point in time. may be compared to other software and
Comparing cash flows only makes sense nonsoftware proposals or to alternative
when they are expressed in the same time investment options, so it is important to
frame. determine how those other proposals
Note that value cant always be would be depreciated and how profits
expressed in terms of money. For example, would be estimated.
whether an item is a brand name or not
can significantly affect its perceived value. 1.9. Taxation
Relevant values that cant be expressed in [1*, c16, c17]
terms of money still need to be expressed
in similar terms so that they can be Governments charge taxes in order to
evaluated objectively. finance expenses that society needs but
1.7. Inflation that no single organization would invest
[1*, c13] in. Companies have to pay income taxes,
which can take a substantial portion of a
Inflation describes long-term trends in corporations gross profit. A decision
prices. Inflation means that the same analysis that does not account for taxation
things cost more than they did before. If can lead to the wrong choice. A proposal
the planning horizon of a business with a high pretax profit wont look nearly
decision is longer than a few years, or if
as profitable in posttax terms. Not [2*, c1]

accounting for taxation can also lead to
unrealistically high expectations about Effectiveness is about having impact. It is
how profitable a proposed product might the relationship between achieved
be. objectives to defined objectives.
1.10. Time-ValueofMoney Effectiveness means doing the right
[1*, c5, c11] things. Effectiveness looks only at
whether defined objectives are reached
One of the most fundamental concepts in not at how they are reached.
financeand therefore, in business
decisions is that money has time-value: 1.13. Productivity
its value changes over time. A specific [2*, c23]
amount of money right now almost always
has a different value than the same amount Productivity is the ratio of output over
of money at some other time. This concept input from an economic perspective.
has been around since the earliest recorded Output is the value delivered. Input covers
human history and is commonly known as all resources (e.g., effort) spent to generate
timevalue. In order to compare proposals the output. Productivity combines
or portfolio elements, they should be efficiency and effectiveness from a
valueoriented perspective: maximizing
normalized in cost, value, and risk to the
productivity is about generating highest
net present value. Currency exchange
value with lowest resource consumption.
variations over time need to be taken into
account based on historical data. This is
2.Life Cycle Economics
particularly important in cross-border
developments of all kinds. 2.1. Product
[2*, c22] [3*, c6]
1.11. Efficiency
[2*, c1] A product is an economic good (or output)
that is created in a process that transforms
Economic efficiency of a process, activity,
product factors (or inputs) to an output.
or task is the ratio of resources actually
When sold, a product is a deliverable that
consumed to resources expected to be
creates both a value and an experience for
consumed or desired to be consumed in
its users. A product can be a combination
accomplishing the process, activity, or
of systems, solutions, materials, and
task. Efficiency means doing things
services delivered internally (e.g., in-
right. An efficient behavior, like an
house IT solution) or externally (e.g.,
effective behavior, delivers resultsbut
software application), either as-is or as a
keeps the necessary effort to a minimum.
component for another product (e.g.,
Factors that may affect efficiency in
embedded software).
software engineering include product
complexity, quality requirements, time 2.2. Project
pressure, process capability, team [2*, c22] [3*, c1]
distribution, interrupts, feature churn,
tools, and programming language. A project is a temporary endeavor
undertaken to create a unique product,
1.12. Effectiveness
service, or result.7 In software which means that the same resources are
engineering, different project types are not available for other projects.
distinguished (e.g., product development,
outsourced services, software 2.5. ProductLifeCycle
maintenance, service creation, and so on). [2*, c2] [3*, c2]
During its life cycle, a software product
may require many projects. For example, A software product life cycle (SPLC)
during the product conception phase, a includes all activities needed to define,
project might be conducted to determine build, operate, maintain, and retire a
the customer need and market software product or service and its
requirements; during maintenance, a variants. The SPLC activities of operate,
project might be conducted to produce a maintain, and retire typically occur in
next version of a product. a much longer time frame than initial
software development (the software
2.3. Program development life cycleSDLCsee
Software Life Cycle Models in the
A program is a group of related projects, Software Engineering Process KA). Also
subprograms, and program activities the operate-maintain-retire activities of an
managed in a coordinated way to obtain SPLC typically consume more total effort
benefits not available from managing and other resources than the SDLC
them individually.8 Programs are often activities (see Majority of Maintenance
used to identify and manage different Costs in the Software Maintenance KA).
deliveries to a single customer or market The value contributed by a software
over a time horizon of several years. product or associated services can be
objectively determined during the operate
2.4. Portfolio and maintain time frame. Software
engineering economics should be
Portfolios are projects, programs, concerned with all SPLC activities,
subportfolios, and operations managed as including the activities after initial product
a group to achieve strategic objectives. 9 release.
Portfolios are used to group and then
manage simultaneously all assets within a 2.6. ProjectLifeCycle
business line or organization. Looking to [2*, c2] [3*, c2]
an entire portfolio makes sure that impacts
Project life cycle activities typically
of decisions are considered, such as
involve five process groupsInitiating,
resource allocation to a specific project
Planning, Execut-
ing, Monitoring and Controlling, and
7 Project Management Institute, Inc., PMI Closing [4] (see the Software Engineering
LexiconofProjectManagementTerms, Management KA). The activities within a
2012, www.pmi.org/ PMBOK-Guide-and- software project life cycle are often
Standards/~/media/Registered/ interleaved, overlapped, and iterated in
PMI_Lexicon_Final.ashx. various ways [3*, c2] [5] (see the
Software Engineering Process KA). For
8 Ibid. instance, agile product development
within an SPLC involves multiple
9 Ibid. iterations that produce increments of
deliverable software. An SPLC should goodwill, culture, and competences should

include risk management and be considered.
synchronization with different suppliers (if 2.9.PlanningHorizon
any), while providing auditable decision- [1*, c11]
making information (e.g., complying with
product liability needs or governance When an organization chooses to invest in
regulations). The software project life a particular proposal, money gets tied up
cycle and the software product life cycle in that proposalso-called frozen
are interrelated; an SPLC may include assets. The economic impact of frozen
several SDLCs. assets tends to start high and decreases
over time. On the other hand, operating
2.7.Proposals and maintenance costs of elements
[1*, c3] associated with the proposal tend to start
low but increase over time. The total cost
Making a business decision begins with of the proposalthat is, owning and
the notion of a proposal. Proposals relate operating a productis the sum of those
to reaching a business objectiveat the two costs. Early on, frozen asset costs
project, product, or portfolio level. A dominate; later, the operating and
proposal is a single, separate option that is maintenance costs dominate. There is a
being considered, like carrying out a point in time where the sum of the costs is
particular software development project or minimized; this is called the minimum
not. Another proposal could be to enhance costlifetime.
an existing software component, and still To properly compare a proposal with a
another might be to redevelop that same fouryear life span to a proposal with a six-
software from scratch. Each proposal year life span, the economic effects of
represents a unit of choiceeither you can either cutting the six-year proposal by two
choose to carry out that proposal or you years or investing the profits from the
can choose not to. The whole purpose of four-year proposal for another two years
business decision-making is to figure out, need to be addressed. The planning
given the current business circumstances, horizon, sometimes known as the study
which proposals should be carried out and period, is the consistent time frame over
which shouldnt. which proposals are considered. Effects
such as software lifetime will need to be
2.8.InvestmentDecisions factored into establishing a planning
[1*, c4] horizon. Once the planning horizon is
established, several techniques are
Investors make investment decisions to available for putting proposals with
spend money and resources on achieving a different life spans into that planning
target objective. Investors are either inside horizon.
(e.g., finance, board) or outside (e.g.,
banks) the organization. The target relates 2.10.PriceandPricing
to some economic criteria, such as [1*, c13]
achieving a high return on the investment,
strengthening the capabilities of the A price is what is paid in exchange for a
organization, or improving the value of the good or service. Price is a fundamental
company. Intangible aspects such as aspect of financial modeling and is one of
the four Ps of the marketing mix. The the cost based on expenses (e.g.,
other three Ps are product, promotion, and production, software engineering,
place. Price is the only revenue-generating distribution, rework) and on the target cost
element amongst the four Ps; the rest are to be competitive and successful in a
costs. market. The target cost can be below the
Pricing is an element of finance and actual estimated cost. The planning and
marketing. It is the process of determining controlling of these costs (called cost
what a company will receive in exchange management) is important and should
for its products. Pricing factors include always be included in costing.
manufacturing cost, market placement, An important concept in costing is the
competition, market condition, and quality total cost of ownership (TCO). This holds
of product. Pricing applies prices to especially for software, because there are
products and services based on factors many not-so-obvious costs related to
such as fixed amount, quantity break, SPLC activities after initial product
promotion or sales campaign, specific development. TCO for a software product
vendor quote, shipment or invoice date, is defined as the total cost for acquiring,
combination of multiple orders, service activating, and keeping that product
offerings, and many others. The needs of running. These costs can be grouped as
the consumer can be converted into direct and indirect costs. TCO is an
demand only if the consumer has the accounting method that is crucial in
willingness and capacity to buy the making sound economic decisions.
product. Thus, pricing is very important in
marketing. Pricing is initially done during 2.12. PerformanceMeasurement
the project initiation phase and is a part of [3*, c7, c8]
go decision making.
Performance measurement is the process
2.11. CostandCosting whereby an organization establishes and
[1*, c15] measures the parameters used to
determine whether programs, investments,
A cost is the value of money that has been and acquisitions are achieving the desired
used up to produce something and, hence, results. It is used to evaluate whether
is not available for use anymore. In performance objectives are actually
economics, a cost is an alternative that is achieved; to control budgets, resources,
given up as a result of a decision. progress, and decisions; and to improve
A sunk cost is the expenses before a performance.
certain time, typically used to abstract
decisions from expenses in the past, which 2.13. EarnedValueManagement
can cause emotional hurdles in looking [3*, c8]
forward. From a traditional economics
Earned value management (EVM) is a
point of view, sunk costs should not be
project management technique for
considered in decision making.
measuring progress based on created
Opportunity cost is the cost of an
value. At a given moment, the results
alternative that must be forgone in order to
achieved to date in a project are compared
pursue another alternative.
with the projected budget and the planned
Costing is part of finance and product
schedule progress for that date. Progress
management. It is the process to determine
relates already-consumed resources and
achieved results at a given point in time resources for other opportunities. Sunk
with the respective planned values for the costs should not be considered in such
same date. It helps to identify possible decision making because they have been
performance problems at an early stage. A spent and will not reappear as a value.
key principle in EVM is tracking cost and 2.15. ReplacementandRetirement
schedule variances via comparison of Decisions
planned versus actual schedule and budget [1*, c12] [2*, c9]
versus actual cost. EVM tracking gives
much earlier visibility to deviations and A replacement decision is made when an
thus permits corrections earlier than organization already has a particular asset
classic cost and schedule tracking that and they are considering replacing it with
only looks at delivered documents and something else; for example, deciding
products. between maintaining and supporting a
legacy software product or redeveloping it
2.14. TerminationDecisions from the ground up. Replacement
[1*, c11, c12] [2*, c9] decisions use the same business decision
process as described above, but there are
Termination means to end a project or additional challenges: sunk cost and
product. Termination can be preplanned salvage value. Retirement decisions are
for the end of a long product lifetime (e.g., also about getting out of an activity
when foreseeing that a product will reach altogether, such as when a software
its lifetime) or can come rather company considers not selling a software
spontaneously during product product anymore or a hardware
development (e.g., when project manufacturer considers not building and
performance targets are not achieved). In selling a particular model of computer any
both cases, the decision should be longer. Retirement decision can be
carefully prepared, considering always the influenced by lock-in factors such as
alternatives of continuing versus technology dependency and high exit
terminating. Costs of different alternatives costs.
must be estimatedcovering topics such
as replacement, information collection, 3.Risk and Uncertainty
suppliers, alternatives, assets, and utilizing
Figure 12.4. Goals, Estimates, and Plans

3.1. Goals,Estimates,andPlans with given requirements would take longer

[3*, c6] than the target date foreseen by the client.
In such cases, plans demand a review of
Goals in software engineering economics initial goals as well as estimates and the
are mostly business goals (or business underlying uncertainties and inaccuracies.
objectives). Creative solutions with the underlying
A business goal relates business needs rationale of achieving a win-win position
(such as increasing profitability) to are applied to resolve conflicts.
investing resources (such as starting a To be of value, planning should involve
project or launching a product with a consideration of the project constraints
given budget, content, and timing). Goals and commitments to stakeholders. Figure
apply to operational planning (for 12.4 shows how goals are initially defined.
instance, to reach a certain milestone at a Estimates are done based on the initial
given date or to extend software testing by goals. The plan tries to match the goals
some time to achieve a desired quality and the estimates. This is an iterative
levelsee Key Issues in the Software process, because an initial estimate
Testing KA) and to the strategic level typically does not meet the initial goals.
(such as reaching a certain profitability or
market share in a stated time period). 3.2. EstimationTechniques
An estimate is a well-founded [3*, c6]
evaluation of resources and time that will
be needed to achieve stated goals (see Estimations are used to analyze and
Effort, Schedule, and Cost Estimation in forecast the resources or time necessary to
the Software Engineering Management implement requirements (see Effort,
KA and Maintenance Cost Estimation in Schedule, and Cost Estimation in the
the Software Maintenance KA). A Software Engineering Management KA
software estimate is used to determine and Maintenance Cost Estimation in the
whether the project goals can be achieved Software Maintenance KA). Five families
within the constraints on schedule, budget, of estimation techniques exist:
features, and quality attributes. Estimates
are typically internally generated and are Expert judgment
not necessarily visible externally. Analogy
Estimates should not be driven exclusively Estimation by parts
by the project goals because this could Parametric methods
make an estimate overly optimistic. Statistical methods.
Estimation is a periodic activity; estimates
should be continually revised during a No single estimation technique is
project. perfect, so using multiple estimation
A plan describes the activities and technique is useful. Convergence among
milestones that are necessary in order to the estimates produced by different
reach the goals of a project (see Software techniques indicates that the estimates are
Project Planning in the Software probably accurate. Spread among the
Engineering Management KA). The plan estimates indicates that certain factors
should be in line with the goal and the might have been overlooked. Finding the
estimate, which is not necessarily easy and factors that caused the spread and then
obvioussuch as when a software project
reestimating again to produce results that expectation variance and decision

converge could lead to a better estimate. making
3.3. AddressingUncertainty Monte Carlo analysis
[3*, c6] decision trees
expected value of perfect information.
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 constraints of schedule, budget,
resources, and technology, or to provide
for building product increments, 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. DecisionsunderRisk
[1*, c24] [3*, c9]
Decisions under risk techniques are used

when the decision maker can assign
probabilities to the different possible
outcomes (see Risk Management in the
KA). The specific techniques include
expected value decision making

3.6.
Figure 12.5. The for-profit decision-making process

DecisionsunderUncertainty
[1*, c25] [3*, c9]
Decisions under uncertainty techniques are

used when the decision maker cannot
assign probabilities to the different
possible outcomes because needed
information is not available (see Risk
Management in the Software Engineering
Management KA). Specific techniques
include
Laplace Rule
Maximin Rule
Maximax Rule
Hurwicz Rule
Minimax Regret Rule.
4.Economic Analysis Methods
4.1. For-ProfitDecisionAnalysis (in present-day cash terms) that alternative

[1*, c10] is worth than investing at the MARR.
Figure 12.5 describes a process for 4.3. ReturnonInvestment

identifying the best alternative from a set [1*, c10]
of mutually exclusive alternatives.
Decision criteria depend on the business Return on investment (ROI) is a measure
objectives and typically include ROI (see of the profitability of a company or
section 4.3, Return on Investment) or business unit. It is defined as the ratio of
Return on Capital Employed (ROCE) (see money gained or lost (whether realized or
section 4.4, Return on Capital Employed). unrealized) on an investment relative to
For-profit decision techniques dont the amount of money invested. The
apply for government and nonprofit purpose of ROI varies and includes, for
organizations. In these cases, organizations instance, providing a rationale for future
have different goalswhich means that a investments and acquisition decisions.
different set of decision techniques are
needed, such as cost-benefit or cost- 4.4. ReturnonCapitalEmployed
effectiveness analysis.
4.2. MinimumAcceptableRate The return on capital employed (ROCE) is
ofReturn a measure of the profitability of a
[1*, c10] company or business unit. It is defined as
the ratio of a gross profit before taxes and
The minimum acceptable rate of return interest (EBIT) to the total assets minus
(MARR) is the lowest internal rate of current liabilities. It describes the return
return the organization would consider to on the used capital.
be a good investment. Generally speaking, 4.5. Cost-BenefitAnalysis
it wouldnt be smart to invest in an [1*, c18]
activity with a return of 10% when theres
another activity thats known to return Cost-benefit analysis is one of the most
20%. The MARR is a statement that an widely used methods for evaluating
organization is confident it can achieve at individual proposals. Any proposal with a
least that rate of return. The MARR benefit-cost ratio of less than 1.0 can
represents the organizations opportunity usually be rejected without further
cost for investments. By choosing to analysis because it would cost more than
invest in some activity, the organization is the benefit. Proposals with a higher ratio
explicitly deciding to not invest that same need to consider the associated risk of an
money somewhere else. If the investment and compare the benefits with
the option of investing the money at a
organization is already confident it can get
guaranteed interest rate (see section 4.2,
some known rate of return, other
Minimum Acceptable Rate of Return).
alternatives should be chosen only if their
rate of return is at least that high. A simple
4.6. Cost-EffectivenessAnalysis
way to account for that opportunity cost is
[1*, c18]
to use the MARR as the interest rate in
business decisions. Cost-effectiveness analysis is similar to
An alternatives present worth evaluated at costbenefit analysis. There are two
the MARR shows how much more or less versions of costeffectiveness analysis: the
fixed-cost version maximizes the benefit attributes, that need to be considered,

given some upper bound on cost; the and those attributes cant be cast in terms
fixed-effectiveness version minimizes the of money. Multiple attribute decision
cost needed to achieve a fixed goal. techniques allow other, nonfinancial
criteria to be factored into the decision.
4.7. Break-EvenAnalysis There are two families of multiple
[1*, c19] attribute decision techniques that differ in
how they use the attributes in the decision.
Break-even analysis identifies the point One family is the compensatory, or
where the costs of developing a product single-dimensioned, techniques. This
and the revenue to be generated are equal. family collapses all of the attributes onto a
Such an analysis can be used to choose single figure of merit. The family is called
between different proposals at different compensatory because, for any given
estimated costs and revenue. Given alternative, a lower score in one attribute
estimated costs and revenue of two or can be compensated byor traded off
more proposals, break-even analysis helps againsta higher score in other attributes.
in choosing among them. The compensatory techniques include
4.8. BusinessCase nondimensional scaling

[1*, c3] additive weighting analytic
hierarchy process.
The business case is the consolidated
information summarizing and explaining a In contrast, the other family is the
business proposal from different noncompensatory, or fully dimensioned,
perspectives for a decision maker (cost, techniques. This family does not allow
benefit, risk, and so on). It is often used to tradeoffs among the attributes. Each
assess the potential value of a product, attribute is treated as a separate entity in
which can be used as a basis in the the decision process. The
investment decisionmaking process. As noncompensatory techniques include
opposed to a mere profitloss calculation,
the business case is a case of plans and dominance
analyses that is owned by the product satisficing lexicography.
manager and used in support of achieving
the business objectives. 4.10.OptimizationAnalysis
[1*, c20]
4.9. MultipleAttributeEvaluation
[1*, c26] The typical use of optimization analysis is
to study a cost function over a range of
The topics discussed so far are used to values to find the point where overall
make decisions based on a single decision performance is best. Softwares classic
criterion: money. The alternative with the space-time tradeoff is an example of
best present worth, the best ROI, and so optimization; an algorithm that runs faster
forth is the one selected. Aside from will often use more memory. Optimization
technical feasibility, money is almost balances the value of the faster runtime
always the most important decision against the cost of the additional memory.
criterion, but its not always the only one. Real options analysis can be used to
Quite often there are other criteria, other quantify the value of project choices,
including the value of delaying a decision. and the gold plating that results from
Such options are difficult to compute with adding features that have low marginal
precision. However, awareness that value for the users (see Agile Methods in
choices have a monetary value provides the Software Engineering Models and
insight in the timing of decisions such as Methods KA and Software Life Cycle
increasing project staff or lengthening Models in the Software Engineering
time to market to improve quality. Process KA). In agile methods, detailed
planning and lengthy development phases
5.Practical Considerations are replaced by incremental planning and
frequent delivery of small increments of a
5.1. TheGoodEnoughPrinciple deliverable product that is tested and
[1*, c21] evaluated by user representatives.
Often software engineering projects and 5.2. Friction-FreeEconomy

products are not precise about the targets
that should be achieved. Software Economic friction is everything that keeps
requirements are stated, but the marginal markets from having perfect competition.
value of adding a bit more functionality It involves distance, cost of delivery,
cannot be measured. The result could be restrictive regulations, and/or imperfect
late delivery or too-high cost. The good information. In high-friction markets,
enough principle relates marginal value customers dont have many suppliers from
to marginal cost and provides guidance to which to choose. Having been in a
determine criteria when a deliverable is business for a while or owning a store in a
good enough to be delivered. These good location determines the economic
criteria depend on business objectives and position. Its hard for new competitors to
on prioritization of different alternatives, start business and compete. The
such as ranking software requirements, marketplace moves slowly and
measurable quality attributes, or relating predictably. Friction-free markets are just
schedule to product content and cost. the reverse. New competitors emerge and
The RACE principle (reduce accidents customers are quick to respond. The
and control essence) is a popular rule marketplace is anything but predictable.
towards good enough software. Accidents Theoretically, software and IT are
imply unnecessary overheads such as frictionfree. New companies can easily
gold-plating and rework due to late defect create products and often do so at a much
removal or too many requirements lower cost than established companies,
changes. Essence is what customers pay since they need not consider any legacies.
for. Software engineering economics Marketing and sales can be done via the
provides the mechanisms to define criteria Internet and social networks, and basically
that determine when a deliverable is good free distribution mechanisms can enable a
enough to be delivered. It also highlights ramp up to a global business. Software
that both words are relevant: good and engineering economics aims to provide
enough. Insufficient quality or foundations to judge how a software
insufficient quantity is not good enough. business performs and how friction-free a
Agile methods are examples of good market actually is. For instance,
enough that try to optimize value by competition among software app
reducing the overhead of delayed rework developers is inhibited when apps must be
sold through an app store and comply with outside the home country of an enterprise.
that stores rules. Enterprises typically either have their
offshoring branches in lowcost countries
5.3. Ecosystems or they ask specialized companies abroad
to execute the respective activity.
An ecosystem is an environment Offshoring should therefore not be
consisting of all the mutually dependent confused with outsourcing. Offshoring
stakeholders, business units, and within a company is called captive
companies working in a particular area. offshoring. Outsourcing is the result-
In a typical ecosystem, there are producers oriented relationship with a supplier who
and consumers, where the consumers add executes business activities for an
value to the consumed resources. Note enterprise when, traditionally, those
that a consumer is not the end user but an activities were executed inside the
organization that uses the product to enterprise. Outsourcing is site-
enhance it. A software ecosystem is, for independent. The supplier can reside in the
instance, a supplier of an application neighborhood of the enterprise or offshore
working with companies doing the (outsourced offshoring). Software
installation and support in different engineering economics provides the basic
regions. Neither one could exist without criteria and business tools to evaluate
the other. Ecosystems can be permanent or different sourcing mechanisms and control
temporary. Software engineering their performance. For instance, using an
economics provides the mechanisms to outsourcing supplier for software
evaluate alternatives in establishing or development and maintenance might
extending an ecosystemfor instance, reduce the cost per hour of software
assessing whether to work with a specific development, but increase the number of
distributor or have the distribution done by hours and capital expenses due to an
a company doing service in an area. increased need for monitoring and
communication. (For more information on
5.4. OffshoringandOutsourcing offshoring and outsourcing, see
Outsourcing in Management Issues in
Offshoring means executing a business the Software
activity beyond sales and marketing Maintenance KA.)
Tockey [1*]
2005 Fairley [3*]
200
Sommerville 2011
[2*]
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
Tockey [1*]
2005 Fairley [3*]
200
Sommerville 2011
[2*]
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.1. The Good Enough Principle c21
5.2. Friction-Free Economy
5.3. Ecosystems
5.4. Offshoring and Outsourcing
FURTHER READINGS The PMBOK Guide provides guidelines
for managing individual projects and
AGuidetotheProjectManagementBody defines project management related
ofKnowledge (PMBOKGuide) [4]. concepts. It also describes the project
management life cycle and its related
processes, as well as the project life cycle. This book is a classic reading on making a
It is a globally recognized guide for the business case in the software and IT
project management profession. businesses. Many useful examples
illustrate how the business case is
SoftwareExtensiontotheGuidetothe formulated and quantified.
ProjectManagementBodyof REFERENCES
Knowledge(SWX) [5].
[1*] S. Tockey, ReturnonSoftware:
SWX provides adaptations and extensions MaximizingtheReturnonYour
to the generic practices of project SoftwareInvestment, Addison-Wesley,
management documented in the 2004.
PMBOK Guide for managing software
projects. The primary contribution of this [2*] J.H. Allen et al., SoftwareSecurity
extension to the PMBOKGuide is Engineering:AGuideforProject
description of processes that are applicable Managers, Addison-Wesley, 2008.
for managing adaptive life cycle software
projects. [3*] R.E. Fairley, ManagingandLeading
B.W. Boehm, SoftwareEngineering Computer Society Press, 2009.
Economics
[6]. [4] Project Management Institute, A
GuidetotheProjectManagement
This book is the classic reading on BodyofKnowledge(PMBOK(R)
software engineering economics. It Guide), 5th ed., Project Management
provides an overview of business thinking Institute, 2013.
in software engineering. Although the
examples and figures are dated, it still is [5] Project Management Institute and
worth reading. IEEE Computer Society, Software
ExtensiontothePMBOKGuide
C. Ebert and R. Dumke, Software FifthEdition, ed: Project Management
Measurement Institute, 2013.
[7].
[6] B.W. Boehm, SoftwareEngineering
This book provides an overview on Economics, Prentice-Hall, 1981.
quantitative methods in software
engineering, starting with measurement [7] C. Ebert and R. Dumke, Software
theory and proceeding to performance Measurement, Springer, 2007.
management and business decision
making. [8] D.J. Reifer, MakingtheSoftware
BusinessCase:Improvementbythe
D.J. Reifer, MakingtheSoftwareBusiness Numbers, Addison Wesley, 2002.
Case:ImprovementbytheNumbers
[8].
CHAPTER 13
COMPUTING FOUNDATIONS
ACRONYMS
AOP Aspect-Oriented Programming
ALU Arithmetic and Logic Unit
Application Programming
API
Interface
ATM AsynchronousSmall
Transfer Mode
Computer
B/S System Interface
Browser-Server
Computer Emergency Response
CERT
Team
INTRODUCTION COTS Commercial Off-The-Shelf
CRUD Create, Read, Update, Delete
The scope of the Computing
C/S Client-Server
Foundations knowledge area (KA)
encompasses the CS Computer Science
development and DBMS Database Management System operational
environment in which FPU Float Point Unit software
evolves and executes. Because no
software can exist in a I/O Input and Output vacuum or
run without a computer, the ISA Instruction Set Architecture core of
such an environment is the International Organization for computer
and its various components. ISO Knowledge
Standardization
about the computer and its underlying
ISP Internet Service Provider
principles of hardware and software
serves as a framework on LAN Local Area Network which
software engineering is MUX Multiplexer anchored.
Thus, all software engineers must have
NIC Network Interface Card
good understanding of the Computing
Foundations KA. OOP Object-Oriented Programming
It is generally accepted OS Operating System that
software engineering builds OSI Open Systems Interconnection on top of
computer science. For example,
Software Engineering PC Personal Computer 2004:
Curriculum Guidelines for PDA Personal Digital Assistant
Undergraduate Degree PPP Point-to-Point Protocol Programs
in Software Engineering [1] clearly
RFID Radio Frequency Identification
states, One particularly important
aspect is that software RAM Random Access Memory
engineeringbuildson ROM Read Only Memory computer
science and mathematics SCSI (italics
added).
SQL Structured Query Language
TCP Transport Control Protocol
UDP User Datagram Protocol
VPN Virtual Private Network
WAN Wide Area Network
Steve Tockey wrote in his book Return onSoftware:
Both computer science and software engineering deal with computers, computing, and
software. The science of computing, as a body of knowledge, is at the core of both.
13-1
Figure 13.1. Breakdown of Topics for the Computing Foundations KA

Software engineering is programming, data structure, algorithms,
concerned with the application of computer organization, operating systems,
computers, computing, and compilers, databases, networking,
software to practical purposes, distributed systems, and so forth. Thus,
specifically the design, when breaking down topics, it can be
construction, and operation of tempting to decompose the Computing
efficient and economical software Foundations KA according to these often-
systems. found divisions in relevant courses.
However, a purely course-based division
Thus, at the core of software of topics suffers serious drawbacks. For
engineering is an understanding of one, not all courses in computer science
computer science. are related or equally important to
While few people will deny the role software engineering. Thus, some topics
computer science plays in the that would otherwise be covered in a
development of software engineering both computer science course are not covered
as a discipline and as a body of in this KA. For example, computer
knowledge, the importance of computer graphicswhile an important course in a
science to software engineering cannot be computer science degree programis not
overemphasized; thus, this Computing included in this KA.
Foundations KA is being written. Second, some topics discussed in this
The majority of topics discussed in the guideline do not exist as standalone
Computing Foundations KA are also courses in undergraduate or graduate
topics of discussion in basic courses given computer science programs. Consequently,
in computer science undergraduate and such topics may not be adequately covered
graduate programs. Such courses include in a purely course-based breakdown. For
example, abstraction is a topic of approaching problems gradually expand

incorporated into several different and define themselves and finally give rise
computer science courses; it is unclear to different disciplines. For example,
which course abstraction should belong to software engineering focuses on solving
in a course-based breakdown of topics. problems using computers and software.
The Computing Foundations KA is While different problems warrant
divided into seventeen different topics. A different solutions and may require
topics direct usefulness to software different tools and processes, the
engineers is the criterion used for selecting methodology and techniques used in
topics for inclusion in this KA (see Figure solving problems do follow some
13.1). The advantage of this topic-based guidelines and can often be generalized as
breakdown is its foundation on the belief problem solving techniques. For example,
that Computing Foundationsif it is to be a general guideline for solving a generic
grasped firmlymust be considered as a engineering problem is to use the three-
collection of logically connected topics step process given below [2*].
undergirding software engineering in
general and software construction in Formulate the real problem.
particular. Analyze the problem.
The Computing Foundations KA is Design a solution search strategy.
related closely to the Software Design,
Software Construction, Software Testing, 1.2. FormulatingtheReal
Software Maintenance, Software Quality, Problem
and Mathematical Foundations KAs.
Gerard Voland writes, It is important to
BREAKDOWN OF TOPICS FOR recognize that a specific problem should
COMPUTING FOUNDATIONS be formulated if one is to develop a
specific solution [2*]. This formulation is
The breakdown of topics for the called the problem statement, which
Computing Foundations KA is shown in explicitly specifies what both the problem
Figure 13.1. and the desired outcome are.
1. Problem Solving Techniques Although there is no universal way of
[2*, s3.2, c4] [3*, c5] stating a problem, in general a problem
should be expressed in such a way as to
The concepts, notions, and terminology facilitate the development of solutions.
Some general techniques to help one
introduced here form an underlying basis
formulate the real problem include
for understanding the role and scope of statement-restatement, determining the
problem solving techniques. 1.1. source and the cause, revising the
DefinitionofProblemSolving statement, analyzing present and desired
state, and using the fresh eye approach.
Problem solving refers to the thinking and 1.3. AnalyzetheProblem
activities conducted to answer or derive a
solution to a problem. There are many Once the problem statement is available,
ways to approach a problem, and each the next step is to analyze the problem
way employs different tools and uses statement or situation to help structure our
different processes. These different ways search for a solution. Four types of
analysis include situationanalysis, in computer to do. There may be many ways

which the most urgent or critical aspects to tell the story, but all should take the
of a situation are identified first; problem perspective of a computer such that the
analysis, in which the cause of the computer can eventually solve the
problem must be determined; decision problem. In general, a problem should be
analysis, in which the action(s) needed to expressed in such a way as to facilitate the
correct the problem or eliminate its cause development of algorithms and data
must be determined; and potential structures for solving it.
problemanalysis, in which the action(s) The result of the first task is a problem
needed to prevent any reoccurrences of the statement. The next step is to convert the
problem or the development of new problem statement into algorithms that
problems must be determined. 1.4. solve the problem. Once an algorithm is
DesignaSolutionSearchStrategy found, the final step converts the
algorithm into machine instructions that
Once the problem analysis is complete, we form the final solution: software that
can focus on structuring a search strategy solves the problem.
to find the solution. In order to find the Abstractly speaking, problem solving
best solution (here, best could mean using a computer can be considered as a
different things to different people, such as process of problem transformationin
faster, cheaper, more usable, different other words, the step-bystep
capabilities, etc.), we need to eliminate transformation of a problem statement into
paths that do not lead to viable solutions, a problem solution. To the discipline of
design tasks in a way that provides the software engineering, the ultimate
most guidance in searching for a solution, objective of problem solving is to
and use various attributes of the final transform a problem expressed in natural
solution state to guide our choices in the language into electrons running around a
problem solving process. circuit. In general, this transformation can
be broken into three phases:
1.5. ProblemSolvingUsingPrograms
a) Development of algorithms from the
The uniqueness of computer software problem statement.
gives problem solving a flavor that is b) Application of algorithms to the
distinct from general engineering problem problem.
solving. To solve a problem using c) Transformation of algorithms to
computers, we must answer the following program code.
questions.
The conversion of a problem statement
How do we figure out what to tell the into algorithms and algorithms into
computer to do? program codes usually follows a stepwise
How do we convert the problem refinement (a.k.a. systematic
statement into an algorithm? decomposition) in which we start with a
How do we convert the algorithm into problem statement, rewrite it as a task, and
machine instructions? recursively decompose the task into a few
simpler subtasks until the task is so simple
The first task in solving a problem using that solutions to it are straightforward.
a computer is to determine what to tell the There are three basic ways of
decomposing: sequential, conditional, and When abstracting, we concentrate on one

iterative. level of the big picture at a time with
confidence that we can then connect
2.Abstraction effectively with levels above and below.
[3*, s5.25.4] Although we focus on one level,
abstraction does not mean knowing
Abstraction is an indispensible technique nothing about the neighboring levels.
associated with problem solving. It refers Abstraction levels do not necessarily
to both the process and result of correspond to discrete components in
generalization by reducing the information reality or in the problem domain, but to
of a concept, a problem, or an observable welldefined standard interfaces such as
phenomenon so that one can focus on the programming APIs. The advantages that
big picture. One of the most important standard interfaces provide include
skills in any engineering undertaking is portability, easier software/hardware
framing the levels of abstraction integration and wider usage.
appropriately.
Through abstraction, according to 2.2. Encapsulation
Voland, we view the problem and its
possible solution paths from a higher level Encapsulation is a mechanism used to
of conceptual understanding. As a result, implement abstraction. When we are
we may become better prepared to dealing with one level of abstraction, the
recognize possible relationships between information concerning the levels below
different aspects of the problem and and above that level is encapsulated. This
thereby generate more creative design information can be the concept, problem,
solutions [2*]. This is particularly true in or observable phenomenon; or it may be
computer science in general (such as the permissible operations on these
hardware vs. software) and in software relevant entities. Encapsulation usually
engineering in particular (data structure vs. comes with some degree of information
data flow, and so forth). hiding in which some or all of the
underlying details are hidden from the
2.1. LevelsofAbstraction level above the interface provided by the
abstraction. To an object, information
hiding means we dont need to know the
details of how the object is represented or
how the operations on those objects are
implemented.
2.3. Hierarchy
When we use abstraction in our problem

formulation and solution, we may use
different abstractions at different times
in other words, we work on different
levels of abstraction as the situation calls.
Most of the time, these different levels of
abstraction are organized in a hierarchy.
There are many ways to structure a beneficial, it is as times difficult to keep

particular hierarchy and the criteria used alternate abstractions in sync.
in determining the specific content of each
layer in the hierarchy varies depending on 3.Programming Fundamentals
the individuals performing the work. [3*, c619]
Sometimes, a hierarchy of abstraction is
sequential, which means that each layer Programming is composed of the
has one and only one predecessor (lower) methodologies or activities for creating
layer and one and only one successor computer programs that perform a desired
(upper) layerexcept the upmost layer function. It is an indispensible part in
(which has no successor) and the software construction. In general,
bottommost layer (which has no programming can be considered as the
predecessor). Sometimes, however, the process of designing, writing, testing,
hierarchy is organized in a tree-like debugging, and maintaining the source
structure, which means each layer can code. This source code is written in a
have more than one predecessor layer but programming language.
only one successor layer. Occasionally, a The process of writing source code
hierarchy can have a manyto-many often requires expertise in many different
structure, in which each layer can have subject areasincluding knowledge of the
multiple predecessors and successors. At application domain, appropriate data
no time, shall there be any loop in a structures, specialized algorithms, various
hierarchy. language constructs, good programming
A hierarchy often forms naturally in task techniques, and software engineering.
decomposition. Often, a task analysis can
be decomposed in a hierarchical fashion, 3.1. TheProgrammingProcess
starting with the larger tasks and goals of
the organization and breaking each of Programming involves design, writing,
them down into smaller subtasks that can testing, debugging, and maintenance.
again be further subdivided This Design is the conception or invention of a
continuous division of tasks into smaller scheme for turning a customer
ones would produce a hierarchical requirement for computer software into
structure of tasks-subtasks. operational software. It is the activity that
links application requirements to coding
2.4. AlternateAbstractions and debugging. Writing is the actual
coding of the design in an appropriate
Sometimes it is useful to have multiple programming language. Testing is the
alternate abstractions for the same activity to verify that the code one writes
problem so that one can keep different actually does what it is supposed to do.
perspectives in mind. For example, we can Debugging is the activity to find and fix
have a class diagram, a state chart, and a bugs (faults) in the source code (or
sequence diagram for the same software at design). Maintenance is the activity to
the same level of abstraction. These update, correct, and enhance existing
alternate abstractions do not form a programs. Each of these activities is a
hierarchy but rather complement each huge topic and often warrants the
other in helping understanding the explanation of an entire KA in the
problem and its solution. Though SWEBOK Guide and many books.
3.2. ProgrammingParadigms more complex issues (such as how to

structure an interface, how to handle
Programming is highly creative and thus exceptions, and so forth).
somewhat personal. Different people often Object-OrientedProgramming: While
write different programs for the same procedural programming organizes
requirements. This diversity of programs around procedures, object-
programming causes much difficulty in oriented programming (OOP) organize a
the construction and maintenance of large program around objects, which are
complex software. Various programming abstract data structures that combine both
paradigms have been developed over the data and methods used to access or
years to put some standardization into this manipulate the data. The primary features
highly creative and personal activity. of OOP are that objects representing
When one programs, he or she can use one various abstract and concrete entities are
of several programming paradigms to created and these objects interact with
write the code. The major types of each other to collectively fulfill the desired
programming paradigms are discussed functions.
below. Aspect-Oriented Programming:
Unstructured Programming: In Aspect-oriented programming (AOP) is a
unstructured programming, a programmer programming paradigm that is built on top
follows his/her hunch to write the code in of OOP. AOP aims to isolate secondary or
whatever way he/she likes as long as the supporting functions from the main
function is operational. Often, the practice programs business logic by focusing on
is to write code to fulfill a specific utility the cross sections (concerns) of the
without regard to anything else. Programs objects. The primary motivation for AOP
written this way exhibit no particular is to resolve the object tangling and
structure thus the name unstructured scattering associated with OOP, in which
programming. Unstructured the interactions among objects become
programming is also sometimes called ad very complex. The essence of AOP is the
hoc programming. greatly emphasized separation of
Structured/Procedural/ Imperative concerns, which separates noncore
Programming:A hallmark of structured functional concerns or logic into various
programming is the use of well-defined aspects.
control structures, including procedures FunctionalProgramming: Though less
(and/or functions) with each procedure (or popular, functional programming is as
function) performing a specific task. viable as the other paradigms in solving
Interfaces exist between procedures to programming problems. In functional
facilitate correct and smooth calling programming, all computations are treated
operations of the programs. Under as the evaluation of mathematical
structured programming, programmers functions. In contrast to the imperative
often follow established protocols and programming that emphasizes changes in
rules of thumb when writing code. These state, functional programming emphasizes
protocols and rules can be numerous and the application of functions, avoids state
cover almost the entire scope of and mutable data, and provides referential
programmingranging from the simplest transparency.
issue (such as how to name variables,
functions, procedures, and so forth) to 4. Programming Language Basics
[4*, c6] (form) and semantics (meaning). Such

specifications include, for example,
Using computers to solve problems specific requirements for the definition of
involves programmingwhich is writing variables and constants (in other words,
and organizing instructions telling the declaration and types) and format
computer what to do at each step. requirements for the instructions
Programs must be written in some themselves.
programming language with which and In general, a programming language
through which we describe necessary supports such constructs as variables, data
computations. In other words, we use the types, constants, literals, assignment
facilities provided by a programming statements, control statements, procedures,
language to describe problems, develop functions, and comments. The syntax and
algorithms, and reason about problem semantics of each construct must be
solutions. To write any program, one must clearly specified.
understand at least one programming
language. 4.1. ProgrammingLanguage 4.3. Low-LevelProgrammingLanguages
Overview
Programming language can be classified
A programming language is designed to into two classes: low-level languages and
express computations that can be high-level languages. Low-level languages
performed by a computer. In a practical can be understood by a computer with no
sense, a programming language is a or minimal assistance and typically
notation for writing programs and thus include machine languages and assembly
should be able to express most data languages. A machine language uses ones
structures and algorithms. Some, but not and zeros to represent instructions and
all, people restrict the term programming variables, and is directly understandable
language to those languages that can by a computer. An assembly language
express all possible algorithms. contains the same instructions as a
Not all languages have the same machine language but the instructions and
importance and popularity. The most variables have symbolic names that are
popular ones are often defined by a easier for humans to remember.
specification document established by a Assembly languages cannot be directly
well-known and respected organization. understood by a computer and must be
For example, the C programming language translated into a machine language by a
is specified by an ISO standard named utility program called an assembler. There
ISO/IEC 9899. Other languages, such as often exists a correspondence between the
Perl and Python, do not enjoy such instructions of an assembly language and a
treatment and often have a dominant machine language, and the translation
implementation that is used as a reference. from assembly code to machine code is
straightforward. For example, add r1, r2,
4.2. SyntaxandSemanticsof r3 is an assembly instruction for adding
ProgrammingLanguages the content of register r2 and r3 and
storing the sum into register r1. This
Just like natural languages, many instruction can be easily translated into
programming languages have some form machine code 0001 0001 0010 0011.
of written specification of their syntax
(Assume the operation code for addition is sequences to be executed. Such

0001, see Figure 13.2). programming languages are called
add r1, r2, r3 declarative programming languages.
Declarative languages are high-level
0001 0001 0010 0011 languages. The actual implementation of
Figure 13.2. Assembly-to-Binary Translations
the computation written in such a
language is hidden from the programmers
One common trait shared by these two
and thus is not a concern for them.
types of language is their close association
The key point to note is that declarative
with the specifics of a type of computer or
programming only describes what the
instruction set architecture (ISA).
program should accomplish without
4.4. High-LevelProgrammingLanguages
describing how to accomplish it. For this
reason, many people believe declarative
A high-level programming language has a
programming facilitates easier software
strong abstraction from the details of the
development. Declarative programming
computers ISA. In comparison to low-
languages include Lisp (also a functional
level programming languages, it often
programming language) and Prolog, while
uses natural-language elements and is thus
imperative programming languages
much easier for humans to understand.
include C, C++, and JAVA.
Such languages allow symbolic naming of
variables, provide expressiveness, and 5.Debugging Tools and Techniques
enable abstraction of the underlying [3*, c23]
hardware. For example, while each
Once a program is coded and compiled
microprocessor has its own ISA, code
(compilation will be discussed in section
written in a high-level programming
10), the next step is debugging, which is a
language is usually portable between
methodical process of finding and
many different hardware platforms. For
reducing the number of bugs or faults in a
these reasons, most programmers use and
program. The purpose of debugging is to
most software are written in high-level
find out why a program doesnt work or
programming languages. Examples of
produces a wrong result or output. Except
high-level programming languages
for very simple programs, debugging is
include C, C++, C#, and Java.
always necessary.
4.5. Declarativevs.Imperative
5.1. TypesofErrors
ProgrammingLanguages
When a program does not work, it is often
Most programming languages (high-level
because the program contains bugs or
or lowlevel) allow programmers to specify
errors that can be either syntactic errors,
the individual instructions that a computer
logical errors, or data errors. Logical
is to execute. Such programming
errors and data errors are also known as
languages are called imperative
two categories of faults in software
programming languages because one has
engineering terminology (see topic 1.1,
to specify every step clearly to the
Testing-Related Terminology, in the
computer. But some programming
Software Testing KA).
languages allow programmers to only
Syntax errors are simply any error that
describe the function to be performed
prevents the translator
without specifying the exact instruction
(compiler/interpreter) from successfully techniques are used at various stages of

parsing the statement. Every statement in a program development.
program must be parse-able before its The main activity of dynamic debugging
meaning can be understood and is tracing, which is executing the program
interpreted (and, therefore, executed). In one piece at a time, examining the
high-level programming languages, syntax contents of registers and memory, in order
errors are caught during the compilation or to examine the results at each step. There
translation from the high-level language are three ways to trace a program.
into machine code. For example, in the
C/C++ programming language, the Single-stepping: execute one
statement 123=constant; contains a instruction at a time to make sure each
syntax error that will be caught by the instruction is executed correctly. This
compiler during compilation. method is tedious but useful in
Logicerrors are semantic errors that verifying each step of a program.
result in incorrect computations or Breakpoints:tell the program to stop
program behaviors. Your program is legal, executing when it reaches a specific
but wrong! So the results do not match the instruction. This technique lets one
problem statement or user expectations. quickly execute selected code
For example, in the C/C++ programming sequences to get a high-level overview
language, the inline function int f(int x) of the execution behavior.
{return f(x-1);} for computing factorial x! Watchpoints:tell the program to stop
is legal but logically incorrect. This type when a register or memory location
of error cannot be caught by a compiler changes or when it equals to a specific
during compilation and is often discovered value. This technique is useful when
through tracing the execution of the one doesnt know where or when a
program (Modern static checkers do value is changed and when this value
identify some of these errors. However, change likely causes the error.
the point remains that these are not
machine checkable in general). 5.3. DebuggingTools
Dataerrors are input errors that result
either in input data that is different from Debugging can be complex, difficult, and
what the program expects or in the tedious. Like programming, debugging is
processing of wrong data. also highly creative (sometimes more
5.2. DebuggingTechniques creative than programming). Thus some
help from tools is in order. For dynamic
Debugging involves many activities and debugging, debuggers are widely used and
can be static, dynamic, or postmortem. enable the programmer to monitor the
Static debugging usually takes the form execution of a program, stop the
of code review, while dynamic debugging execution, restart the execution, set
usually takes the form of tracing and is breakpoints, change values in memory,
closely associated with testing. and even, in some cases, go back in time.
Postmortemdebugging is the act of For static debugging, there are many
debugging the core dump (memory dump) staticcode analysis tools, which look for
of a process. Core dumps are often a specific set of known problems within
generated after a process has terminated the source code.
due to an unhandled exception. All three
Both commercial and free tools exist in determine whether a program runs in a
various languages. These tools can be few seconds or in a few hours or even a
extremely useful when checking very few days.
large source trees, where it is impractical From the perspective of physical and
to do code walkthroughs. The UNIX lint logical ordering, a data structure is either
program is an early example. linear or nonlinear. Other perspectives
give rise to different classifications that
6.Data Structure and Representation include homogeneous vs. heterogeneous,
[5*, s2.12.6] static vs. dynamic, persistent vs. transient,
external vs. internal, primitive vs.
Programs work on data. But data must be aggregate, recursive vs. nonrecursive;
expressed and organized within computers passive vs. active; and stateful vs. stateless
before being processed by programs. This structures.
organization and expression of data for 6.2. TypesofDataStructure
programs use is the subject of data
structure and representation. Simply put, a As mentioned above, different
data structure tries to store and organize perspectives can be used to classify data
data in a computer in such a way that the structures. However, the predominant
data can be used efficiently. There are perspective used in classification centers
many types of data structures and each on physical and logical ordering between
type of structure is suitable for some kinds data items. This classification divides data
of applications. For example, B/ B+ trees structures into linear and nonlinear
are well suited for implementing massive structures. Linear structures organize data
file systems and databases. items in a single dimension in which each
data entry has one (physical or logical)
6.1. DataStructureOverview predecessor and one successor with the
exception of the first and last entry. The
Data structures are computer first entry has no predecessor and the last
representations of data. Data structures are entry has no successor. Nonlinear
used in almost every program. In a sense, structures organize data items in two or
no meaningful program can be constructed more dimensions, in which case one entry
without the use of some sort of data can have multiple predecessors and
structure. Some design methods and successors. Examples of linear structures
programming languages even organize an include lists, stacks, and queues. Examples
entire software system around data of nonlinear structures include heaps, hash
structures. Fundamentally, data structures tables, and trees (such as binary trees,
are abstractions defined on a collection of balance trees, B-trees, and so forth).
data and its associated operations. Another type of data structure that is
Often, data structures are designed for often encountered in programming is the
improving program or algorithm compound structure. A compound data
efficiency. Examples of such data structure builds on top of other (more
structures include stacks, queues, and primitive) data structures and, in some
heaps. At other times, data structures are way, can be viewed as the same structure
used for conceptual unity (abstract data as the underlying structure. Examples of
type), such as the name and address of a compound structures include sets, graphs,
person. Often, a data structure can
and partitions. For example, a partition can to compose programs are algorithms,
be viewed as a set of sets. which organize various functions into a
series of steps and take into consideration
6.3. OperationsonData the application domain, the solution
Structures strategy, and the data structures being
used. An algorithm can be very simple or
All data structures support some very complex.
operations that produce a specific
structure and ordering, or retrieve relevant 7.1.OverviewofAlgorithms
data from the structure, store data into the
structure, or delete data from the structure. Abstractly speaking, algorithms guide the
Basic operations supported by all data operations of computers and consist of a
structures include create, read, update, and sequence of actions composed to solve a
delete (CRUD). problem. Alternative definitions include
but are not limited to:
Create: Insert a new data entry into the
structure. An algorithm is any well-defined
Read: Retrieve a data entry from the computational procedure that takes
structure. some value or set of values as input
Update: Modify an existing data entry. and produces some value or set of
Delete: Remove a data entry from the values as output.
structure. An algorithm is a sequence of
computational steps that transform the
Some data structures also support input into the output.
additional operations: An algorithm is a tool for solving a
Find a particular element in the wellspecified computation problem.
structure.
Sort all elements according to some Of course, different definitions are
ordering. Traverse all elements in favored by different people. Though there
some specific order. is no universally accepted definition, some
Reorganize or rebalance the structure. agreement exists that an algorithm needs
to be correct, finite (in other words,
Different structures support different terminate eventually or one must be able
operations with different efficiencies. The to write it in a finite number of steps), and
difference between operation efficiency unambiguous.
can be significant. For example, it is easy 7.2. AttributesofAlgorithms
to retrieve the last item inserted into a
stack, but finding a particular element The attributes of algorithms are many and
within a stack is rather slow and tedious. often include modularity, correctness,
maintainability, functionality, robustness,
7.Algorithms and Complexity user-friendliness (i.e. easy to be
[5*, s1.11.3, s3.33.6, s4.14.8, s5.15.7, understood by people), programmer time,
s6.16.3, s7.17.6, s11.1, s12.1] simplicity, and extensibility. A commonly
emphasized attribute is performance or
Programs are not random pieces of code: efficiency by which we mean both time
they are meticulously written to perform and resource-usage efficiency while
user-expected actions. The guide one uses generally emphasizing the time axis. To
some degree, efficiency determines if an The design of algorithms generally

algorithm is feasible or impractical. For follows one of the following strategies:
example, an algorithm that takes one brute force, divide and conquer, dynamic
hundred years to terminate is virtually programming, and greedy selection. The
useless and is even considered incorrect. bruteforcestrategy is actually a no-
strategy. It exhaustively tries every
7.3. AlgorithmicAnalysis possible way to tackle a problem. If a
problem has a solution, this strategy is
Analysis of algorithms is the theoretical guaranteed to find it; however, the time
study of computer-program performance expense may be too high. The divideand
and resource usage; to some extent it conquer strategy improves on the brute
determines the goodness of an algorithm. force strategy by dividing a big problem
Such analysis usually abstracts away the into smaller, homogeneous problems. It
particular details of a specific computer solves the big problem by recursively
and focuses on the asymptotic, machine- solving the smaller problems and combing
independent analysis. the solutions to the smaller problems to
There are three basic types of analysis. form the solution to the big problem. The
In worst-case analysis, one determines underlying assumption for divide and
the maximum time or resources required conquer is that smaller problems are easier
by the algorithm on any input of size n. In to solve.
average-caseanalysis, one determines the The dynamicprogrammingstrategy
expected time or resources required by the improves on the divide and conquer
algorithm over all inputs of size n; in strategy by recognizing that some of the
performing average-case analysis, one sub-problems produced by division may
often needs to make assumptions on the be the same and thus avoids solving the
statistical distribution of inputs. The third same problems again and again. This
type of analysis is the best-caseanalysis, elimination of redundant subproblems can
in which one determines the minimum dramatically improve efficiency.
time or resources required by the The greedyselectionstrategy further
algorithm on any input of size n. Among improves on dynamic programming by
the three types of analysis, average-case recognizing that not all of the sub-
analysis is the most relevant but also the problems contribute to the solution of the
most difficult to perform. big problem. By eliminating all but one
Besides the basic analysis methods, sub-problem, the greedy selection strategy
there are also the amortizedanalysis, in achieves the highest efficiency among all
which one determines the maximum time algorithm design strategies. Sometimes the
required by an algorithm over a sequence use of randomization can improve on the
of operations; and the competitive greedy selection strategy by eliminating
analysis, in which one determines the the complexity in determining the greedy
relative performance merit of an algorithm choice through coin flipping or
against the optimal algorithm (which may randomization.
not be known) in the same category (for
the same operations). 7.5. AlgorithmicAnalysis
7.4. AlgorithmicDesign Strategies
Strategies
The analysis strategies of algorithms 8.1.EmergentSystemProperties

include basic counting analysis, in which
one actually counts the number of steps an A system is more than simply the sum of
algorithm takes to complete its task; its parts. Thus, the properties of a system
asymptoticanalysis, in which one only are not simply the sum of the properties of
considers the order of magnitude of the its components. Instead, a system often
number of steps an algorithm takes to exhibits properties that are properties of
complete its task; probabilistic analysis, the system as a whole. These properties
in which one makes use of probabilities in are called emergentproperties because
analyzing the average performance of an they develop only after the integration of
algorithm; amortizedanalysis, in which constituent parts in the system. Emergent
one uses the methods of aggregation, system properties can be either functional
potential, and accounting to analyze the or nonfunctional. Functional properties
worst performance of an algorithm on a describe the things that a system does. For
sequence of operations; and competitive example, an aircrafts functional
analysis, in which one uses methods such properties include flotation on air,
as potential and accounting to analyze the carrying people or cargo, and use as a
relative performance of an algorithm to weapon of mass destruction.
the optimal algorithm. Nonfunctional properties describe how the
For complex problems and algorithms, system behaves in its operational
one may need to use a combination of the environment. These can include such
aforementioned analysis strategies. qualities as consistency, capacity, weight,
security, etc.
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 system 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
sociotechnical 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.
Figure 13.3. Basic Components of a Computer System Based on the von Neumann Model
8.2.SystemsEngineering
Systems engineering is the

interdisciplinary approach governing the
total technical and managerial effort
required to transform a set of customer
needs, expectations, and constraints into a
solution and to support that solution
throughout 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
development, system integration, system
testing, system installation, system
evolution, and system decommissioning.
Many practical guidelines have been
produced in the past to aid people in
performing the activities of each phase.
For example, system design can be broken
into smaller tasks of identification of
subsystems, assignment of system
requirements to subsystems, specification
of subsystem functionality, definition of
sub-system interfaces, and so forth.
8.3.OverviewofaComputerSystem
Among all the systems, one that is From the perspective of a computer, a
obviously relevant to the software wide semantic gap exists between its
engineering community is the computer intended behavior and the workings of the
system. A computer is a machine that underlying electronic devices that actually
executes programs or software. It consists do the work within the computer. This gap
of a purposeful collection of mechanical, is bridged through computer organization,
electrical, and electronic components with which meshes various electrical,
each component performing a preset electronic, and mechanical devices into
function. Jointly, these components are one device that forms a computer. The
able to execute the instructions that are objects that computer organization deals
given by the program. with are the devices, connections, and
Abstractly speaking, a computer controls. The abstraction built in computer
receives some input, stores and organization is the computer.
manipulates some data, and provides some
output. The most distinct feature of a 9.1.ComputerOrganizationOverview
computer is its ability to store and execute
sequences of instructions called programs. A computer generally consists of a CPU,
An interesting phenomenon concerning memory, input devices, and output
the computer is the universal equivalence devices. Abstractly speaking, the
in functionality. According to Turing, all organization of a computer can be divided
computers with a certain minimum into four levels (Figure 13.4). The macro
capability are equivalent in their ability to architecture level is the formal
perform computation tasks. In other specification of all the functions a
words, given enough time and memory, all particular machine can carry out and is
computers ranging from a netbook to a known as the instruction set architecture
supercomputerare capable of computing (ISA). The microarchitecture level is the
exactly the same things, irrespective of implementation of the ISA in a specific
speed, size, cost, or anything else. CPUin other words, the way in which
Most computer systems have a structure the ISAs specifications are actually
that is known as the von Neumann carried out. The logiccircuits level is the
model, which consists of five level where each functional component of
components: a memory for storing the micro architecture is built up of
instructions and data, a centralprocessing circuits that make decisions based on
unitfor performing arithmetic and logical simple rules. The deviceslevel is the level
operations, a control unit for sequencing where, finally, each logic circuit is
and interpreting instructions, input for actually built of electronic devices such as
getting external information into the complementary metal-oxide
memory, and output for producing results semiconductors (CMOS), n-channel metal
for the user. The basic components of a oxide semiconductors (NMOS), or
computer system based on the von gallium arsenide (GaAs) transistors, and
Neumann model are depicted in Figure so forth.
13.3. Macro Architecture Level (ISA)
9.Computer Organization
Micro Architecture Level
[8*, c1c4]
Logic Circuits Level
Devices Level
Figure 13.4. Machine Architecture Levels building various digital devices from the
simplest elements (such as transistors) and
Each level provides an abstraction to the for governing the operation of digital
level above and is dependent on the level devices. For example, digital logic spells
below. To a programmer, the most out what the value will be if a zero and
important abstraction is the ISA, which one is ANDed, ORed, or exclusively
specifies such things as the native data ORed together. It also specifies how to
types, instructions, registers, addressing build decoders, multiplexers (MUX),
modes, the memory architecture, interrupt memory, and adders that are used to
and exception handling, and the I/Os. assemble the computer.
Overall, the ISA specifies the ability of a
computer and what can be done on the 9.4.ComputerExpressionofData
computer with programming.
As mentioned before, a computer
9.2.DigitalSystems expresses data with electrical signals or
digital zeros and ones. Since there are only
At the lowest level, computations are two different digits used in data
carried out by the electrical and electronic expression, such a system is called a
devices within a computer. The computer binaryexpressionsystem. Due to the
uses circuits and memory to hold charges inherent nature of a binary system, the
that represents the presence or absence of maximum numerical value expressible by
voltage. The presence of voltage is equal an n-bits binary code is 2n 1.
to a 1 while the absence of voltage is a Specifically, binary number anan1a1a0
zero. On disk the polarity of the voltage is corresponds to an 2n + an1 2n1 + +
represented by 0s and 1s that in turn a1 21 + a0 20. Thus, the numerical
represents the data stored. Everything value of the binary expression of 1011 is 1
including instruction and datais 8 + 0 4 + 1 2 + 1 1 = 11. To
expressed or encoded using digital zeros express a nonnumerical value, we need to
and ones. In this sense, a computer decide the number of zeros and ones to
becomes a digital system. For example, use and the order in which those zeros and
decimal value 6 can be encoded as 110, ones are arranged.
the addition instruction may be encoded as Of course, there are different ways to do
0001, and so forth. The component of the the encoding, and this gives rise to
computer such as the control unit, ALU, different data expression schemes and
memory and I/O use the information to subschemes. For example, integers can be
compute the instructions. expressed in the form of unsigned, ones
complement, or twos complement. For
9.3.DigitalLogic characters, there are ASCII, Unicode, and
IBMs EBCDIC standards. For floating
Obviously, logics are needed to point numbers, there are IEEE-754 FP 1,
manipulate data and to control the 2, and 3 standards. 9.5.TheCentral
operation of computers. This logic, which ProcessingUnit(CPU)
is behind a computers proper function, is
called digitallogic because it deals with The central processing unit is the place
the operations of digital zeros and ones. where instructions (or programs) are
Digital logic specifies the rules both for actually executed. The execution usually
takes several steps, including fetching the interface between the memory system and
program instruction, decoding the other parts of the computer.
instruction, fetching operands, performing
arithmetic and logical operations on the 9.7.InputandOutput(I/O)
operands, and storing the result. The main
components of a CPU consist of registers A computer is useless without I/O.
where instructions and data are often read Common input devices include the
from and written to, the arithmetic and keyboard and mouse; common output
logic unit (ALU) that performs the actual devices include the disk, the screen, the
arithmetic (such as addition, subtraction, printer, and speakers. Different I/O
multiplication, and division) and logic devices operate at different data rates and
(such as AND, OR, shift, and so forth) reliabilities. How computers connect and
operations, the control unit that is manage various input and output devices
responsible for producing proper signals to facilitate the interaction between
to control the operations, and various computers and humans (or other
(data, address, and control) buses that link computers) is the focus of topics in I/O.
the components together and transport The main issues that must be resolved in
data to and from these components. input and output are the ways I/O can and
should be performed.
9.6.MemorySystemOrganization In general, I/O is performed at both
hardware and software levels. Hardware
Memory is the storage unit of a computer. I/O can be performed in any of three ways.
It concerns the assembling of a large-scale DedicatedI/O dedicates the CPU to the
memory system from smaller and single- actual input and output operations during
digit storage units. The main topics I/O;memory-mappedI/O treats I/O
covered by memory system architecture operations as memory operations; and
include the following: hybridI/O combines dedicated I/O and
Memory cells and chips memory-mapped I/O into a single holistic
Memory boards and modules Memory I/O operation mode.
hierarchy and cache Memory as a Coincidentally, software I/O can also be
subsystem of the computer. performed in one of three ways.
ProgrammedI/O lets the CPU wait while
Memorycellsandchips deal with the I/O device is doing I/O; interrupt-
single-digital storage and the assembling drivenI/O lets the CPUs handling of I/O
of single-digit units into one-dimensional be driven by the I/O device; and direct
memory arrays as well as the assembling memoryaccess (DMA) lets I/O be handled
by a secondary CPU embedded in a DMA
of one-dimensional storage arrays into
device (or channel). (Except during the
multi-dimensional storage memory chips.
initial setup, the main CPU is not
Memoryboardsandmodules concern the
disturbed during a DMA I/O
assembling of memory chips into memory
operation.)
systems, with the focus being on the
Regardless of the types of I/O scheme
organization, operation, and management
being used, the main issues involved in
of the individual chips in the system.
I/O include I/Oaddressing (which deals
Memoryhierarchyandcache are used to
with the issue of how to identify the I/O
support efficient memory operations.
device for a specific I/O operation),
Memoryasasub-system deals with the
synchronization (which deals with the
issue of how to make the CPU and I/O image is needed to run the program. Most
device work in harmony during I/O), and application software is sold in this form.
errordetectionandcorrection (which While both compilation and
deals with the occurrence of transmission interpretation convert high level language
errors). code into machine code, there are some
important differences between the two
10. Compiler Basics methods. First, a compiler makes the
[4*, s6.4] conversion just once, while an interpreter
typically converts it every time a program
[8*, s8.4] 10.1.Compiler/Interpreter is executed. Second, interpreting code is
slower than running the compiled code,
Overview because the interpreter must analyze each
statement in the program when it is
Programmers usually write programs in executed and then perform the desired
high level language code, which the CPU
action, whereas the compiled code just
cannot execute; so this source code has to
performs the action within a fixed context
be converted into machine code to be
determined by the compilation. Third,
understood by a computer. Due to the
access to variables is also slower in an
differences between different ISAs, the
interpreter because the mapping of
translation must be done for each ISA or
identifiers to storage locations must be
specific machine language under
done repeatedly at runtime rather than at
consideration.
compile time.
The translation is usually performed by
The primary tasks of a compiler may
a piece of software called a compiler or an
include preprocessing, lexical analysis,
interpreter. This process of translation
parsing, semantic analysis, code
from a high-level language to a machine
generation, and code optimization.
language is called compilation, or,
Program faults caused by incorrect
sometimes, interpretation.
compiler behavior can be very difficult to
10.2.InterpretationandCompilation track down. For this reason, compiler
implementers invest a lot of time ensuring
There are two ways to translate a program the correctness of their software. 10.3.
written in a higher-level language into TheCompilationProcess
machine code: interpretation and
compilation. Interpretationtranslates the Compilation is a complex task. Most
source code one statement at a time into compilers divide the compilation process
machine language, executes it on the spot, into many phases. A typical breakdown is
as follows:
and then goes back for another statement.
Both the high-level-language source code
Lexical Analysis
and the interpreter are required every time
Syntax Analysis or Parsing
the program is run.
Semantic Analysis
Compilation translates the high-level-
Code Generation
language source code into an entire
machine-language program (an executable
Lexicalanalysis partitions the input text
image) by a program called a compiler.
(the source code), which is a sequence of
After compilation, only the executable
characters, into separate comments, which
are to be ignored in subsequent actions, It is often possible to combine multiple

and basicsymbols,whichhave lexical phases into one pass over the code in a
meanings. These basic symbols must compiler implementation. Some compilers
correspond to some terminal symbols of also have a preprocessing phase at the
the grammar of the particular beginning or after the lexical analysis that
programming language. Here terminal does necessary housekeeping work, such
symbols refer to the elementary symbols as processing the program instructions for
(or tokens) in the grammar that cannot be the compiler (directives). Some compilers
changed. provide an optional optimization phase at
Syntaxanalysis is based on the results of the end of the entire compilation to
the lexical analysis and discovers the optimize the code (such as the
structure in the program and determines rearrangement of instruction sequence) for
whether or not a text conforms to an efficiency and other desirable objectives
expected format. Isthisatextually requested by the users.
correctC++program? or Isthisentry
textuallycorrect? are typical questions 11. Operating Systems Basics
that can be answered by syntax analysis. [4*, c3]
Syntax analysis determines if the source
code of a program is correct and converts Every system of meaningful complexity
it into a more structured representation needs to be managed. A computer, as a
(parse tree) for semantic analysis or rather complex electrical-mechanical
transformation. system, needs its own manager for
Semanticanalysis adds semantic managing the resources and activities
information to the parse tree built during occurring on it. That manager is called an
the syntax analysis and builds the symbol operatingsystem(OS).
table. It performs various semantic checks 11.1. OperatingSystems
that include type checking, object binding Overview
(associating variable and function
references with their definitions), and Operating systems is a collection of
definite assignment (requiring all local software and firmware, that controls the
variables to be initialized before use). If execution of computer programs and
mistakes are found, the semantically provides such services as computer
incorrect program statements are rejected resource allocation, job control,
and flagged as errors. input/output control, and file management
Once semantic analysis is complete, the in a computer system. Conceptually, an
phase of code generation begins and operating system is a computer program
transforms the intermediate code produced that manages the hardware resources and
in the previous phases into the native makes it easier to use by applications by
machine language of the computer under presenting nice abstractions. This nice
consideration. This involves resource and abstraction is often called the virtual
storage decisionssuch as deciding which machine and includes such things as
variables to fit into registers and memory processes, virtual memory, and file
and the selection and scheduling of systems. An OS hides the complexity of
appropriate machine instructions, along the underlying hardware and is found on
with their associated addressing modes. all modern computers.
The principal roles played by OSs are The arsenal of OSs is abstraction.
management and illusion. Management Corresponding to the five physical tasks,
refers to the OSs management (allocation OSs use five abstractions: process/thread,
and recovery) of physical resources among virtual memory, file systems, input/output,
multiple competing users/ and protection domains. The overall OS
applications/tasks. Illusion refers to the abstraction is the virtual machine.
nice abstractions the OS provides. For each task area of OS, there is both a
physical reality and a conceptual
11.2. TasksofanOperating abstraction. The physical reality refers to
System the hardware resource under management;
the conceptual abstraction refers to the
The tasks of an operating system differ interface the OS presents to the
significantly depending on the machine users/programs above. For example, in the
and time of its invention. However, thread model of the OS, the physical
modern operating systems have come to reality is the CPU and the abstraction is
agreement as to the tasks that must be multiple CPUs. Thus, a user doesnt have
performed by an OS. These tasks include to worry about sharing the CPU with
CPU management, memory management, others when working on the abstraction
disk management (file system), I/O device provided by an OS. In the virtual memory
management, and security and protection. abstraction of an OS, the physical reality is
Each OS task manages one type of the physical RAM or ROM (whatever),
physical resource. the abstraction is multiple unlimited
Specifically, CPU management deals memory space. Thus, a user doesnt have
with the allocation and releases of the to worry about sharing physical memory
CPU among competing programs (called with others or about limited physical
processes/threads in OS jargon), including memory size.
the operating system itself. The main Abstractions may be virtual or
abstraction provided by CPU management transparent; in this context virtual applies
is the process/thread model. Memory to something that appears to be there, but
management deals with the allocation and isnt (like usable memory beyond
release of memory space among physical), whereas transparent applies to
competing processes, and the main something that is there, but appears not to
abstraction provided by memory be there (like fetching memory contents
management is virtual memory. Disk from disk or physical memory).
management deals with the sharing of
magnetic or optical or solid state disks 11.4. OperatingSystems
among multiple programs/users and its Classification
main abstraction is the file system. I/O
device management deals with the Different operating systems can have
allocation and releases of various I/O different functionality implementation. In
devices among competing processes. the early days of the computer era,
Security and protection deal with the operating systems were relatively simple.
protection of computer resources from As time goes on, the complexity and
illegal use. sophistication of operating systems
increases significantly. From a historical
11.3. OperatingSystem perspective, an operating system can be
Abstractions classified as one of the following.
BatchingOS:organizes and processes include such examples of iOS,

work in batches. Examples of such Android, Symbian, etc.
OSs include IBMs FMS, IBSYS, and
University of Michigans UMES. 12. Database Basics and Data
Multiprogrammed batching OS: adds Management
multitask capability into earlier simple [4*, c9]
batching OSs. An example of such an
OS is IBMs OS/360. A database consists of an organized
Time-sharingOS:adds multi-task and collection of data for one or more uses. In
interactive capabilities into the OS. a sense, a database is a generalization and
Examples of such OSs include UNIX, expansion of data structures. But the
Linux, and NT. difference is that a database is usually
Real-time OS: adds timing external to individual programs and
predictability into the OS by permanent in existence compared to data
scheduling individual tasks according structures. Databases are used when the
to each tasks completion deadlines. data volume is large or logical relations
Examples of such OS include between data items are important. The
VxWorks (WindRiver) and DART factors considered in database design
(EMC). include performance, concurrency,
DistributedOS: adds the capability of integrity, and recovery from hardware
managing a network of computers into failures.
the OS.
EmbeddedOS: has limited 12.1. EntityandSchema
functionality and is used for
embedded systems such as cars and The things a database tries to model and
PDAs. Examples of such OSs include store are called entities. Entities can be
Palm OS, Windows CE, and TOPPER. real-world objects such as persons, cars,
houses, and so forth, or they may be
Alternatively, an OS can be classified by abstract concepts such as persons, salary,
its applicable target machine/environment names, and so forth. An entity can be
into the following. primitive such as a name or composite
such as an employee that consists of a
MainframeOS: runs on the mainframe name, identification number, salary,
computers and include OS/360, address, and so forth.
OS/390, AS/400, MVS, and VM. The single most important concept in a
ServerOS: runs on workstations or database is the schema, which is a
servers and includes such systems as description of the entire database structure
UNIX, Windows, Linux, and VMS. from which all other database activities are
Multicomputer OS: runs on multiple built. A schema defines the relationships
computers and include such examples between the various entities that compose
as Novell Netware. a database. For example, a schema for a
Personal computers OS: runs on company payroll system would consist of
personal computers and include such such things as employee ID, name, salary
examples as DOS, Windows, Mac OS, rate, address, and so forth. Database
and Linux. software maintains the database according
MobiledeviceOS: runs on personal to the schema.
devices such as cell phones, IPAD and
Another important concept in database Language (DML), and Data Control

is the databasemodel that describes the Language (DCL). An example of an DML
type of relationship among various query may look like the following:
entities. The commonly used models
include relational, network, and object SELECT Component_No, Quantity
models. FROM COMPONENT
WHERE Item_No = 100
12.2. DatabaseManagementSystems
(DBMS) The above query selects all the
Component_No and its corresponding
Database Management System (DBMS) quantity from a database table called
components include database applications COMPONENT, where the Item_No equals
for the storage of structured and to 100.
unstructured data and the required
database management functions needed to 12.4. TasksofDBMSPackages
view, collect, store, and retrieve data from
the databases. A DBMS controls the A DBMS system provides the following
creation, maintenance, and use of the capabilities:
database and is usually categorized
according to the database model it Databasedevelopment is used to
supportssuch as the relational, network, define and organize the content,
or object model. For example, a relational relationships, and structure of the data
database management system (RDBMS) needed to build a database.
implements features of the relational Databaseinterrogation is used for
model. An object database management accessing the data in a database for
system (ODBMS) implements features of information retrieval and report
the object model. generation. End users can selectively
12.3. DatabaseQueryLanguage retrieve and display information and
produce printed reports. This is the
Users/applications interact with a database operation that most users know about
through a database query language, which databases.
is a specialized programming language DatabaseMaintenance is used to add,
tailored to database use. The database delete, update, and correct the data in
model tends to determine the query a database.
languages that are available to access the ApplicationDevelopmentis used to
database. One commonly used query develop prototypes of data entry
language for the relational database is the screens, queries, forms, reports, tables,
structured query language, more and labels for a prototyped
commonly abbreviated as SQL. A application. It also refers to the use of
common query language for object 4th Generation Language or
databases is the object query language application generators to develop or
(abbreviated as OQL). There are three generate program code.
components of SQL: Data 12.5. DataManagement
Definition Language (DDL), Data
Manipulation A database must manage the data stored in
it. This management includes both
organization and storage.
The organization of the actual data in a connected computers and may give the
database depends on the database model. illusion of a single, omnipresent computer.
In a relational model, data are organized as Every computer or device connected to a
tables with different tables representing network is called a networknode.
different entities or relations among a set A number of computing paradigms have
of entities. The storage of data deals with emerged to benefit from the functions and
the storage of these database tables on capabilities provided by computer
disks. The common ways for achieving networks. These paradigms include
this is to use files. Sequential, indexed, distributed computing, grid computing,
and hash files are all used in this purpose Internet computing, and cloud computing.
with different file structures providing
different access performance and 13.1. TypesofNetwork
convenience.
Computer networks are not all the same
12.6. DataMining and may be classified according to a wide
variety of characteristics, including the
One often has to know what to look for networks connection method, wired
before querying a database. This type of technologies, wireless technologies, scale,
pinpointing access does not make full network topology, functions, and speed.
use of the vast amount of information But the classification that is familiar to
stored in the database, and in fact reduces most is based on the scale of networking.
the database into a collection of discrete
records. To take full advantage of a PersonalAreaNetwork/Home
database, one can perform statistical Networkis a computer network used
analysis and pattern discovery on the for communication among
content of a database using a technique computer(s) and different information
called datamining. Such operations can technological devices close to one
be used to support a number of business person. The devices connected to such
activities that include, but are not limited a network may include PCs, faxes,
to, marketing, fraud detection, and trend PDAs, and TVs. This is the base on
analysis. which the Internet of Things is built.
Numerous ways for performing data LocalAreaNetwork (LAN) connects
mining have been invented in the past computers and devices in a limited
decade and include such common geographical area, such as a school
techniques as class description, class campus, computer laboratory, office
discrimination, cluster analysis, building, or closely positioned group
association analysis, and outlier analysis. of buildings.
CampusNetwork is a computer
13. Network Communication Basics network made up of an
[8*, c12] interconnection of local area networks
(LANs) within a limited geographical
A computer network connects a collection area.
of computers and allows users of different Wide area network (WAN) is a
computers to share resources with other computer network that covers a large
users. A network facilitates the geographic area, such as a city or
communications between all the country or even across
intercontinental distances. A WAN Computers communicate with each other

limited to a city is sometimes called a using protocols, which specify the format
Metropolitan Area Network. and regulations used to pack and un-pack
Internet is the global network that data. To facilitate easier communication
connects computers located in many and better structure, network protocols are
(perhaps all) countries. divided into different layers with each
layer dealing with one aspect of the
Other classifications may divide communication. For example, the physical
networks into control networks, storage layers deal with the physical connection
networks, virtual private networks (VPN), between the parties that are to
communicate, the data link layer deals
wireless networks, pointto-point networks,
with the raw data transmission and flow
and Internet of Things. 13.2. Basic control, and the network layer deals with
NetworkComponents the packing and un-packing of data into a
particular format that is understandable by
All networks are made up of the same the relevant parties. The most commonly
basic hardware components, including used OSI networking model organizes
computers, network interface cards network protocols into seven layers, as
(NICs), bridges, hubs, switches, and depicted in Figure 13.5.
routers. All these components are called One thing to note is that not all network
nodes in the jargon of networking. Each protocols implement all layers of the OSI
component performs a distinctive function model. For example, the TCP/IP protocol
that is essential for the packaging, implements neither the presentation layer
connection, transmission, amplification, nor the session layer.
controlling, unpacking, and interpretation There can be more than one protocol for
of the data. For example, a repeater each layer. For example, UDP and TCP
amplifies the signals, a switch performs both work on the transport layer above
many-to-many connections, a hub IPs network layer, providing best-effort,
performs one-to-many connections, an unreliable transport (UDP) vs. reliable
interface card is attached to the computer transport function (TCP). Physical layer
and performs data packing and protocols include token ring, Ethernet, fast
transmission, a bridge connects one Ethernet, gigabit Ethernet, and wireless
network with another, and a router is a Ethernet. Data link layer protocols include
computer itself and performs data analysis frame-relay, asynchronous transfer mode
and flow control to regulate the data from (ATM), and Point-toPoint Protocol (PPP).
the network. Application layer protocols include Fibre
The functions performed by various channel, Small Computer System Interface
network components correspond to the (SCSI), and Bluetooth. For each layer or
functions specified by one or more levels even each individual protocol, there may
of the seven-layer Open Systems be standards established by national or
Interconnect (OSI) networking model, international organizations to guide the
which is discussed below. design and development of the
corresponding protocols.
13.3. NetworkingProtocolsandStandards
Application Layer
Presentation Layer
Session Layer common affinity for each other such as all

users in the same organization, or
Transport Layer workgroup. This circuit type may improve
Network Layer performance and security between nodes
Data link Layer and allows for easier maintenance of
circuits when troubleshooting.
Physical Layer
Figure 13.5. The Seven-Layer OSI Networking
Model 14. Parallel and Distributed Computing
[8*, c9]
13.4. TheInternet Parallel computing is a computing

paradigm that emerges with the
The Internet is a global system of development of multi-functional units
interconnected governmental, academic, within a computer. The main objective of
corporate, public, and private computer parallel computing is to execute several
networks. In the public domain access to tasks simultaneously on different
the internet is through organizations functional units and thus improve
known as internet service providers (ISP). throughput or response or both.
The ISP maintains one or more switching Distributed computing, on the other hand,
centers called a point of presence, which is a computing paradigm that emerges
actually connects the users to the Internet. with the development of computer
networks. Its main objective is to either
13.5. InternetofThings make use of multiple computers in the
network to accomplish things otherwise
The Internet of Things refers to the not possible within a single computer or
networking of everyday objectssuch as improve computation efficiency by
cars, cell phones, PDAs, TVs, harnessing the power of multiple
refrigerators, and even buildings using computers.
wired or wireless networking
technologies. The function and purpose of 14.1. ParallelandDistributed
InternetofThings is to interconnect all ComputingOverview
things to facilitate autonomous and better
living. Technologies used in the Internet of Traditionally, parallel computing
Things include RFID, wireless and wired investigates ways to maximize
networking, sensor technology, and much concurrency (the simultaneous execution
software of course. As the paradigm of of multiple tasks) within the boundary of a
Internet of Things is still taking shape, computer. Distributed computing studies
much work is needed for Internet of distributed systems, which consists of
Things to gain wide spread acceptance. multiple autonomous computers that
13.6. VirtualPrivateNetwork(VPN) communicate through a computer
network. Alternatively, distributed
A virtual private network is a preplanned computing can also refer to the use of
virtual connection between nodes in a distributed systems to solve computational
LAN/WAN or on the internet. It allows the or transactional problems. In the former
network administrator to separate network definition, distributed computing
traffic into user groups that have a investigates the protocols, mechanisms,
and strategies that provide the foundation Based on the above discussion, it is
for distributed computation; in the latter possible to classify concurrent systems as
definition, distributed computing studies being parallel or distributed based on
the ways of dividing a problem into many the existence or nonexistence of shared
tasks and assigning such tasks to various memory among all the processor: parallel
computers involved in the computation. computing deals with computations within
Fundamentally, distributed computing is a single computer; distributed computing
another form of parallel computing, albeit deals with computations within a set of
on a grander scale. In distributed computers. According to this view,
computing, the functional units are not multicore computing is a form of parallel
ALU, FPU, or separate cores, but computing.
individual computers. For this reason,
some people regard distributed computing 14.3. ParallelandDistributed
as being the same as parallel computing. ComputingModels
Because both distributed and parallel
computing involve some form of Since multiple computers/processors/cores
concurrency, they are both also called are involved in distributed/parallel
concurrent computing. computing, some coordination among the
involved parties is necessary to ensure
14.2. Differencebetween correct behavior of the system.
ParallelandDistributed Different ways of coordination give rise to
Computing different computing models. The most
common models in this regard are the
Though parallel and distributed computing shared memory (parallel) model and the
resemble each other on the surface, there message-passing (distributed) model.
is a subtle but real distinction between In a sharedmemory(parallel)model, all
them: parallel computing does not computers have access to a shared central
necessarily refer to the execution of memory where local caches are used to
programs on different computers speed up the processing power. These
instead, they can be run on different caches use a protocol to insure the
processors within a single computer. In localized data is fresh and up to date,
fact, consensus among computing typically the MESI protocol. The
professionals limits the scope of parallel algorithm designer chooses the program
computing to the case where a shared for execution by each computer. Access to
memory is used by all processors involved the central memory can be synchronous or
in the computing, while distributed asynchronous, and must be coordinated
computing refers to computations where such that coherency is maintained.
private memory exists for each processor Different access models have been
involved in the computations. invented for such a purpose.
Another subtle difference between In a message-passing(distributed)
parallel and distributed computing is that model, all computers run some programs
parallel computing necessitates concurrent that collectively achieve some purpose.
execution of several tasks while The system must work correctly regardless
distributed computing does not have this of the structure of the network. This model
necessity. can be further classified into client-server
(C/S), browser-server (B/S), and n-tier
models. In the C/S model, the server handling of error messages, and the
provides services and the client requests robustness of the software in general.
services from the server. In the B/S model,
the server provides services and the client 15.1. InputandOutput
is the browser. In the n-tier model, each
tier (i.e. layer) provides services to the tier Input and output are the interfaces
immediately above it and requests services between users and software. Software is
from the tier immediately below it. In fact, useless without input and output. Humans
the n-tier model can be seen as a chain of design software to process some input and
client-server models. Often, the tiers produce desirable output. All software
between the bottommost tier and the engineers must consider input and output
topmost tier are called middleware, which as an integral part of the software product
is a distinct subject of study in its own they engineer or develop. Issues
right. considered for input include (but are not
limited to):
14.4. MainIssuesinDistributed
Computing What input is required?
How is the input passed from users to
Coordination among all the components in computers?
a distributed computing environment is What is the most convenient way for
often complex and time-consuming. As users to enter input?
the number of cores/ CPUs/computers What format does the computer
increases, the complexity of distributed require of the input data?
computing also increases. Among the
many issues faced, memory coherency and The designer should request the
consensus among all computers are the minimum data from human input, only
most difficult ones. Many computation when the data is not already stored in the
paradigms have been invented to solve system. The designer should format and
these problems and are the main edit the data at the time of entry to reduce
discussion issues in distributed/parallel errors arising from incorrect or malicious
computing. data entry.
15. Basic User Human Factors For output, we need to consider what
[3*, c8] [9*, c5] the users wish to see:
Software is developed to meet human In what format would users like to see
desires or needs. Thus, all software design output?
and development must take into What is the most pleasing way to
consideration human-user factors such as display output?
how people use software, how people If the party interacting with the software
view software, and what humans expect isnt human but another software or
from software. There are numerous factors computer or control system, then we need
in the human-machine interaction, and to consider the input/ output type and
ISO 9241 document series define all the format that the software should produce to
detailed standards of such interactions. ensure proper data exchange between
[10] But the basic human-user factors systems.
considered here include input/output, the
There are many rules of thumb for However, messages relating to security
developers to follow to produce good access errors should not provide extra
input/output for a software. These rules of information that would help unauthorized
thumb include simple and natural persons break in.
dialogue, speaking users language, 15.3. SoftwareRobustness
minimizing user memory load,
consistency, minimal surprise, Software robustness refers to the ability of
conformance to standards (whether agreed software to tolerate erroneous inputs.
to or not: e.g., automobiles have a standard Software is said to be robust if it continues
interface for accelerator, brake, steering). to function even when erroneous inputs
are given. Thus, it is unacceptable for
15.2. ErrorMessages software to simply crash when
encountering an input problem as this may
It is understandable that most software cause unexpected consequences, such as
contains faults and fails from time to time. the loss of valuable data. Software that
But users should be notified if there is exhibits such behavior is considered to
anything that impedes the smooth lack robustness.
execution of the program. Nothing is more Nielsen gives a simpler description of
frustrating than an unexpected termination software robustness: The software should
or behavioral deviation of software have a low error rate, so that users make
without any warning or explanation. To be few errors during the use of the system
user friendly, the software should report and so that if they do make errors they can
all error conditions to the users or upper- easily recover from them. Further,
level applications so that some measure catastrophic errors must not occur [9*].
can be taken to rectify the situation or to There are many ways to evaluate the
exit gracefully. There are several robustness of software and just as many
guidelines that define what constitutes a ways to make software more robust. For
good error message: error messages example, to improve robustness, one
should be clear, to the point, and timely. should always check the validity of the
First, error messages should clearly inputs and return values before
explain what is happening so that users progressing further; one should always
know what is going on in the software. throw an exception when something
Second, error messages should pinpoint unexpected occurs, and one should never
the cause of the error, if at all possible, so quit a program without first giving
that proper actions can be taken. Third, users/applications a chance to correct the
error messages should be displayed right condition.
when the error condition occurs.
According to Jakob Nielsen, Good error 16. Basic Developer Human Factors
messages should be expressed in plain [3*, c3132]
language (no codes), precisely indicate the
problem, and constructively suggest a Developer human factors refer to the
solution [9*]. Fourth, error messages considerations of human factors taken
should not overload the users with too when developing software. Software is
much information and cause them to developed by humans, read by humans,
ignore the messages all together. and maintained by humans. If anything is
wrong, humans are responsible for
correcting those wrongs. Thus, it is The types of comments include repeat

essential to write software in a way that is of the code, explanation of the code,
easily understandable by humans or, at the marker of the code, summary of the code,
very least, by other software developers. A description of the codes intent, and
program that is easy to read and information that cannot possibly be
understand exhibits readability. expressed by the code itself. Some
The means to ensure that software meet comments are good, some are not. The
this objective are numerous and range good ones are those that explain the intent
from proper architecture at the macro level of the code and justify why this code looks
to the particular coding style and variable the way it does. The bad ones are repeat of
usage at the micro level. But the two the code and stating irrelevant
prominent factors are structure (or information. The best comments are
program layouts) and comments selfdocumenting code. If the code is
(documentation). written in such a clear and precise manner
16.1. Structure that its meaning is selfproclaimed, then no
comment is needed. But this is easier said
Well-structured programs are easier to than done. Most programs are not self-
understand and modify. If a program is explanatory and are often hard to read and
poorly structured, then no amount of understand if no comments are given.
explanation or comments is sufficient to Here are some general guidelines for
make it understandable. The ways to writing good comments:
organize a program are numerous and
range from the proper use of white space, Comments should be consistent across
indentation, and parentheses to nice the entire program.
arrangements of groupings, blank lines, Each function should be associated
and braces. Whatever style one chooses, it with comments that explain the
should be consistent across the entire purpose of the function and its role in
program. the overall program.
Within a function, comments should
16.2. Comments be given for each logical section of
coding to explain the meaning and
To most people, programming is coding. purpose (intention) of the section.
These people do not realize that Comments should stipulate what
programming also includes writing freedom does (or does not) the
comments and that comments are an maintaining programmers have with
integral part of programming. True, respect to making changes to that
comments are not used by the computer code.
and certainly do not constitute final Comments are seldom required for
instructions for the computer, but they individual statements. If a statement
improve the readability of the programs by needs comments, one should
explaining the meaning and logic of the reconsider the statement.
statements or sections of code. It should
be remembered that programs are not only
meant for computers, they are also read, 17. Secure Software Development and
written, and modified by humans. Maintenance
[11*, c29]
Due to increasing malicious activities 17.2.SoftwareDesignSecurity

targeted at computer systems, security has
become a significant issue in the Software Design security deals with the
development of software. In addition to design of software modules that fit
the usual correctness and reliability, together to meet the security objectives
software developers must also pay specified in the security requirements.
attention to the security of the software This step clarifies the details of security
they develop. Secure software considerations and develops the specific
development builds security in software steps for implementation. Factors
by following a set of established and/or considered may include frameworks and
recommended rules and practices in access modes that set up the overall
software development. Secure software security monitoring/enforcement
maintenance complements secure software strategies, as well as the individual policy
development by ensuring the no security enforcement mechanisms.
problems are introduced during software
maintenance. 17.3.SoftwareConstructionSecurity
A generally accepted view concerning
software security is that it is much better Software construction security concerns
to design security into software than to the question of how to write actual
patch it in after software is developed. To programming code for specific situations
design security into software, one must such that security considerations are taken
take into consideration every stage of the care of. The term Software Construction
software development lifecycle. In Security could mean different things for
particular, secure software development different people. It can mean the way a
involves software requirementssecurity, specific function is coded, such that the
coding itself is secure, or it can mean the
software designsecurity, software
coding of security into software.
constructionsecurity,and software testing
Most people entangle the two together
security. In addition, security must also be
without distinction. One reason for such
taken into consideration when performing
entanglement is that it is not clear how one
software maintenance as security faults
can make sure that a specific coding is
and loopholes can be and often are
secure. For example, in C programming
introduced during maintenance. 17.1.
language, the expression of i<<1 (shift the
SoftwareRequirementsSecurity
binary representation of is value to the
Software requirements security deals with left by one bit) and 2*i (multiply the value
the clarification and specification of of variable i by constant 2) mean the same
security policy and objectives into thing semantically, but do they have the
software requirements, which lays the same security ramification? The answer
foundation for security considerations in could be different for different
the software development. Factors to combinations of ISAs and compilers. Due
consider in this phase include software to this lack of understanding, software
requirements and threats/risks. The former construction securityin its current state
refers to the specific functions that are of existencemostly refers to the second
required for the sake of security; the latter aspect mentioned above: the coding of
refers to the possible ways that the security into software.
security of software is threatened.
Coding of security into software can be security of software, security must be built
achieved by following recommended into the software engineering process. One
rules. A few such rules follow: trend that emerges in this regard is the
Structure the process so that all Secure Development Lifecycle (SDL)
sections requiring extra privileges are concept, which is a classical spiral model
modules. The modules should be as that takes a holistic view of security from
small as possible and should perform the perspective of software lifecycle and
only those tasks that require those ensures that security is inherent in
privileges. software design and development, not an
Ensure that any assumptions in the afterthought later in production. The SDL
program are validated. If this is not process is claimed to reduce software
possible, document them for the maintenance costs and increase reliability
installers and maintainers so they of software concerning software security
know the assumptions that attackers related faults.
will try to invalidate.
Ensure that the program does not 17.6. SoftwareSecurity
share objects in memory with any Guidelines
other program.
The error status of every function Although there are no bulletproof ways for
must be checked. Do not try to secure software development, some
recover unless neither the cause of the general guidelines do exist that can be
error nor its effects affect any security used to aid such effort. These guidelines
considerations. The program should span every phase of the software
restore the state of the software to the development lifecycle. Some reputable
state it had before the process began, guidelines are published by the Computer
and then terminate. Emergency Response Team (CERT) and
below are its top 10 software security
17.4. SoftwareTesting practices (the details can be found in [12]:
Security 1. Validate input.
2. Heed compiler warnings.
Software testing security determines that 3. Architect and design for security
software protects data and maintains policies.
security specification as given. For more 4. Keep it simple.
information, please refer to the Software 5. Default deny.
Testing KA. 6. Adhere to the principle of least
privilege.
17.5. BuildSecurityinto 7. Sanitize data sent to other software.
SoftwareEngineering 8. Practice defense in depth.
Process 9. Use effective quality assurance
techniques. 10. Adopt a software
Software is only as secure as its construction security standard.
development process goes. To ensure the
Voland [2*]
2003 NielsenBishop
[9*] 2
1993 [1
McConnell 2004 2008
Brookshear Sommerville 2011
[3*]Horowitz
[4*] et al.
Null2007
and Lobur 2006
[6*]
[5*] [8*]
1. Problem Solving s3.2,

Techniques s4.2
1.1. Definition of
s3.2
Problem Solving
1.2. Formulating the
s3.2
Real Problem
1.3. Analyze the
s3.2
Problem
1.4. Design a
Solution Search s4.2
Strategy
1.5. Problem Solving
c5
Using Programs
s5.2
2. Abstraction
5.4
2.1. Levels of s5.2
Abstraction 5.3
2.2. Encapsulation s5.3
2.3. Hierarchy s5.2
3. Programming
c619
Fundamentals
3.1. The
Programming c6c19
Process
3.2. Programming
c6c19
Paradigms
3.3. Defensive
c8
Programming
4. Programming
c6
Language Basics
4.1. Programming
s6.1
Language Overview
4.2. Syntax and
Semantics of
s6.2
Programming
Language
Voland [2*]
2003 NielsenBishop
[9*] 2
1993 [1
McConnell 2004 2008
[3*]Horowitz
[4*] et al.
Null2007
and Lobur 2006
[6*]
[5*] [8*]
4.3. Low Level

s6.5
Programming
6.7
Language
4.4. High Level
s6.5
Programing
6.7
Language
4.5. Declarative
vs. Imperative s6.5
Programming 6.7
Language
5. Debugging Tools
c23
and Techniques
5.1. Types of Errors s23.1
5.2. Debugging
s23.2
Techniques:
5.3. Debugging
s23.5
Tools
6. Data Structure s2.1
and 2.6
Representation
6.1. Data Structure s2.1

Overview 2.6
6.2. Types of Data s2.1
Structure 2.6
6.3. Operations on s2.1
Data Structures 2.6
s1.1
1.3,
s3.3
3.6,
s4.1
4.8,
7. Algorithms and s5.1
Complexity 5.7,
s6.1
6.3,
s7.1
7.6,
s11.1,
s12.1
Voland [2*]
2003 NielsenBishop
[9*] 2
1993 [1
McConnell 2004 2008
Brookshear
[4*]Sommerville
[3*]Horowitz et al.
Null20072011
and Lobur 2006
[6*]
[5*] [8*]
7.1. Overview of s1.1

Algorithms 1.2
7.2. Attributes of
s1.3
Algorithms
7.3. Algorithmic
s1.3
Analysis
s3.3
3.6,
s4.1
4.8,
s5.1
7.4. Algorithmic 5.7,
Design Strategies s6.1
6.3,
s7.1
7.6,
s11.1,
s12.1
s3.3
3.6,
s4.1
4.8,
s5.1
7.5. Algorithmic 5.7,
Analysis Strategies s6.1
6.3,
s7.1
7.6,
s11.1,
s12.1
8. Basic Concept of a
c10
System
8.1. Emergent
s10.1
System Properties
8.2. System
s10.2
Engineering
8.3. Overview of a
Computer System
Voland [2*]
2003 NielsenBishop
[9*] 2
1993 [1
McConnell 2004 2008
[3*]Horowitz
[4*] et al.
Null2007
and Lobur 2006
[6*]
[5*] [8*]
9. Computer
c14
Organization
9.1. Computer
s1.1
Organization
1.2
Overview
9.2. Digital Systems c3
9.3. Digital Logic c3
9.4. Computer
c2
Expression of Data
9.5. The Central
s4.1
Processing Unit
4.2
(CPU)
9.6. Memory System
s4.6
Organization
9.7. Input and Output
s4.5
(I/O)
10. Compiler Basics s6.4 s8.4
10.1. Compiler
s8.4
Overview
10.2. Interpretation
s8.4
and Compilation
10.3. The
s6.4 s8.4
Compilation Process
11. Operating
c3
Systems Basics
11.1. Operating
s3.2
Systems Overview
11.2. Tasks of
s3.3
Operating System
11.3. Operating
s3.2
System Abstractions
11.4. Operating
Systems s3.1
Classification
Voland [2*]
2003 NielsenBishop
[9*] 2
1993 [1
McConnell 2004 2008
[3*]Horowitz
[4*] et al.
Null2007
and Lobur 2006
[6*]
[5*] [8*]
12. Database
Basics and Data c9
Management
12.1. Entity and
s9.1
Schema
12.2. Database
Management s9.1
Systems (DBMS)
12.3. Database
s9.2
Query Language
12.4. Tasks of
s9.2
DBMS Packages
12.5. Data
s9.5
Management
12.6. Data Mining s9.6
13. Network
Communication c12
Basics
13.1. Types of s12.2
Network 12.3
13.2. Basic Network

s12.6
Components
13.3. Networking
s12.4
Protocols and
12.5
Standards
13.4. The Internet
13.5. Internet of
s12.8
Things
13.6. Virtual
Private
Network
14. Parallel and
Distributed c9
Computing
14.1. Parallel
s9.4.1
and Distributed

Computing
9.4.3
Overview
Voland [2*]
2003 NielsenBishop
[9*] 2
1993 [1
McConnell 2004 2008
[3*]Horowitz
[4*] et al.
Null2007
and Lobur 2006
[6*]
[5*] [8*]
14.2. Differences
between Parallel s9.4.4
and Distributed 9.4.5
Computing
14.3. Parallel
s9.4.4
and Distributed
9.4.5
Computing Models
14.4. Main Issues
in Distributed
Computing
15. Basic User

c8 c5
Human Factors
15.1. Input and s5.1,
Output s5.3
s5.2,
15.2. Error Messages
s5.8
15.3. Software s5.5
Robustness 5.6
16. Basic Developer
c3132
Human Factors
16.1. Structure c31
16.2. Comments c32
17. Secure Software
Development and c29
Maintenance
17.1. Two Aspects of
s29.1
Secure Coding
17.2. Coding
Security into s29.4
Software
17.3. Requirement
s29.2
Security
17.4. Design
s29.3
Security
17.5. Implementation
s29.5
Security
REFERENCES [3*] S. McConnell, CodeComplete, 2nd
[1] Joint Task Force on Computing ed., Microsoft Press, 2004.
Curricula, IEEE Computer Society
[4*] J.G. Brookshear, ComputerScience:
and Association for Computing
AnOverview, 10th ed., Addison-
Machinery, SoftwareEngineering
Wesley, 2008.
2004:CurriculumGuidelinesfor
UndergraduateDegreeProgramsin
[5*] E. Horowitz et al., Computer
SoftwareEngineering, 2004;
Algorithms, 2nd ed., Silicon Press,
http://sites.
2007.
computer.org/ccse/SE2004Volume.pdf
. [6*] I. Sommerville, Software
Engineering, 9th ed., Addison-
[2*] G. Voland, EngineeringbyDesign, Wesley, 2011.
2nd ed., Prentice Hall, 2003.
[7] ISO/IEC/IEEE24765:2010Systems
Vocabulary, ISO/ IEC/IEEE, 2010.
[8*] L. Null and J. Lobur, TheEssentials [10] ISO 9241-420:2011 Ergonomics of

of HumanSystem Interaction, ISO, 2011.
ComputerOrganizationandArchitecture,
2nd ed., Jones and Bartlett Publishers, [11*] M. Bishop, ComputerSecurity:Art
2006. andScience, Addison-Wesley, 2002.
[9*] J. Nielsen, UsabilityEngineering, [12] R.C. Seacord, TheCERTCSecure

Morgan Kaufmann, 1993. CodingStandard, Addison-Wesley
Professional, 2008.
CHAPTER 14 MATHEMATICAL
FOUNDATIONS
INTRODUCTION abstraction on a diverse application

domain.
Software professionals live with programs. The SWEBOK Guides Mathematical
In a very simple language, one can Foundations KA covers basic techniques
program only for something that follows a to identify a set of rules for reasoning in
well-understood, nonambiguous logic. The the context of the system under study.
Mathematical Foundations knowledge Anything that one can deduce following
area (KA) helps software engineers these rules is an absolute certainty within
comprehend this logic, which in turn is the context of that system. In this KA,
translated into programming language techniques that can represent and take
code. The mathematics that is the primary forward the reasoning and judgment of a
focus in this KA is quite different from software engineer in a precise (and
typical arithmetic, where numbers are therefore mathematical) manner are
dealt with and discussed. Logic and defined and discussed. The language and
reasoning are the essence of mathematics methods of logic that are discussed here
that a software engineer must address. allow us to describe mathematical proofs
Mathematics, in a sense, is the study of to infer conclusively the absolute truth of
formal systems. The word formal is certain concepts beyond the numbers. In
associated with preciseness, so there short, you can write a program for a
cannot be any ambiguous or erroneous problem only if it follows some logic. The
interpretation of the fact. Mathematics is objective of this KA is to help you develop
therefore the study of any and all certain the skill to identify and describe such
truths about any concept. This concept can logic. The emphasis is on helping you
be about numbers as well as about understand the basic concepts rather than
symbols, images, sounds, videoalmost on challenging your arithmetic abilities.
anything. In short, not only numbers and
numeric equations are subject to BREAKDOWN OF TOPICS FOR
preciseness. On the contrary, a software MATHEMATICAL FOUNDATIONS
engineer needs to have a precise
The breakdown of topics for the In a more compact representation of set

Mathematical Foundations KA is shown in using set builder notation, {x | P(x)} is the
Figure 14.1. set of all x such that P(x) for any
proposition P(x) over any universe of
1. Set, Relations, Functions discourse. Examples for some important
[1*, c2] sets include the following:
Set. A set is a collection of objects, called N = {0, 1, 2, 3, } = the set of

elements of the set. A set can be nonnegative integers.
represented by listing its elements between Z = {, 3, 2, 1, 0, 1, 2, 3, } = the
braces, e.g., S = {1, 2, 3}. set of integers.
The symbol is used to express that an
element belongs to a set, orin other FiniteandInfiniteSet. A set with a finite
wordsis a member of the set. Its number of elements is called a finite set.
negation is represented by , e.g., 1 S, Conversely, any set that does not have a
but 4 S. finite number of elements in it is an
infiniteset. The set of all natural numbers,
for example, is an infinite set.
14-1
Figure 14.1. Breakdown of Topics for the Mathematical Foundations KA

Cardinality. The cardinality of a finite X = Y p (p X p Y).
set S is the number of elements in S. This
is represented |S|, e.g., if S = {1, 2, 3}, Subset. X is a subset of set Y, or X is
then |S| = 3. contained in Y, if all elements of X are
UniversalSet. In general S = {x U | included in Y. This is denoted by X Y.
p(x)}, where U is the universe of discourse In other words, X Y if and only if p (p
in which the predicate P(x) must be X p Y).
interpreted. The universe of discourse For example, if X = {1, 2, 3} and Y =
for a given predicate is often referred to as {1, 2, 3, 4, 5}, then X Y.
the universal set. Alternately, one may If X is not a subset of Y, it is denoted as X
define universal set as the set of all Y.
elements. ProperSubset. X is a proper subset of Y
SetEquality. Two sets are equal if and (denoted by X Y) if X is a subset of Y
only if they have the same elements, i.e.: 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 Intersection. The intersection of two sets

Y). X and Y, denoted by X Y, is the set of
For example, if X = {1, 2, 3}, Y = {1, 2, common elements in both X and Y.
3, 4}, and Z = {1, 2, 3}, then X Y, but X In other words, X Y = {p | (p X) (p
is not a proper subset of Z. Sets X and Z Y)}.
are equal sets. As, for example, {1, 2, 3} {3, 4, 6} =
If X is not a proper subset of Y, it is {3}
denoted as X Y.
If X Y = f, then the two sets X and Y
Superset. If X is a subset of Y, then Y is are said to be a disjoint pair of sets.
called a superset of X. This is denoted by A Venn diagram for set intersection is
Y X, i.e., Y X if and only if X Y. shown in Figure 14.3. The common
portion of the two sets represents the set
For example, if X = {1, 2, 3} and Y =
intersection.
{1, 2, 3, 4, 5}, then Y X.
EmptySet. A set with no elements is
called an emptyset. An empty set, denoted
by , is also referred to as a null or void
set.
PowerSet. 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) = Figure 14.3. Intersection of Sets X and Y
{,
{a}, {b}, {c}, {a, b}, {a, c}, {b, c}, {a, b, Union. The union of two sets X and Y,
c}}. If |X| = n, then |(X)| = 2n. denoted by X Y, is the set of all elements
VennDiagrams. Venn diagrams are either in X, or in Y, or in both.
graphic representations of sets as enclosed In other words, X Y = {p | (p X)
areas in the plane. (p Y)}. As, for example, {1, 2, 3} {3,
For example, in Figure 14.2, the 4, 6} = {1, 2, 3, 4, 6}.
rectangle represents the universal set and
the shaded region represents a set X.
Figure 14.4. Union of Sets X and Y It

may be noted that |X Y| = |X| + |Y| |X
Y|.
Figure 14.2. Venn Diagram for Set X
A Venn diagram illustrating the union of
two sets is represented by the shaded
region in Figure 14.4.
1.1. SetOperations
Complement. The set of elements in the CartesianProduct. An ordinary pair {p,

universal set that do not belong to a given q} is a set with two elements. In a set, the
set X is called its complement set X'. order of the elements is irrelevant, so {p,
In other words, X' ={p | (p U) (p q} = {q, p}.
X)}. In an ordered pair (p, q), the order of
occurrences 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,
Figure 14.5. Venn Diagram for Complement Set of X
1), (a, 2),
(b, 1), (b, 2)}
The shaded portion of the Venn diagram
in Figure 14.5 represents the complement 1.2. PropertiesofSet
set of X.
SetDifferenceorRelativeComplement. Some of the important properties and laws
The set of elements that belong to set X of sets are mentioned below.
but not to set Y builds the set difference of
Y from X. This is represented by X Y. 1. Associative Laws:
In other words, X Y = {p | (p X) X (Y Z) = (X Y) Z
(p Y)}. X (Y Z) = (X Y) Z
As, for example, {1, 2, 3} {3, 4, 6} = 2. Commutative Laws:
{1, 2}. XY=YX X Y=Y X
It may be proved that X Y = X Y.
Set difference X Y is illustrated by the 3. Distributive Laws:
shaded region in Figure 14.6 using a Venn X (Y Z) = (X Y) (X Z)
diagram. X (Y Z) = (X Y) (X Z)
4. Identity Laws:
X=X XU=X
5. Complement Laws:
X X' = U X
X' =
6. Idempotent Laws: X
X=X X
X=X
7. Bound Laws: X U
Figure 14.6. Venn Diagram for X Y
=U X=
8. Absorption Laws: X A: {(3, 9), (5, 8), (7, 6), (3, 9), (6,
(X Y) = X 3)}. B: {(5, 8), (7, 8), (3, 8), (6, 8)}.
X (X Y)
=X Are these functions as well?
In case of relation A, the domain is all
9. De Morgans Laws: the x-values, i.e., {3, 5, 6, 7}, and the
(X Y)' = X' Y' (X Y)' = X' Y' range is all the y-values, i.e., {9, 6, 3, 8,
9}.
1.3. RelationandFunction Relation A is not a function, as there are
two different range values, 9 and 9, for
A relation is an association between two the same x-value of 3.
sets of information. For example, lets In case of relation B, the domain is same
consider a set of residents of a city and as that for A, i.e., {3, 5, 6, 7}. However,
their phone numbers. The pairing of the range is a single element {8}. This
names with corresponding phone numbers qualifies as an example of a function even
is a relation. This pairing is orderedfor the if all the x-values are mapped to the same
entire relation. In the example being y-value. Here, each x-value is distinct and
considered, for each pair, either the name hence the function is well behaved.
comes first followed by the phone number Relation B may be represented by the
or the reverse. The set from which the first equation y = 8.
element is drawn is called the domainset The characteristic of a function may be
and the other set is called the rangeset. verified using a vertical line test, which is
The domain is what you start with and the stated below:
range is what you end up with. Giventhegraphofarelation,ifonecan
A function is a well-behaved relation. A drawaverticallinethatcrossesthegraph
relation R(X, Y) is well behaved if the inmorethanoneplace,thentherelation
function maps every element of the isnotafunction.
domain set X to a single element of the
range set Y. Lets 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 Figure 14.7. Vertical Line Test for Function
relation and hence a function. This means
that, while all functions are relations, not In this example, both lines L1 and L2
all relations are functions. In case of a cut the graph for the relation thrice. This
function given an x, one gets one and signifies that for the same x-value, there
exactly one y for each ordered pair (x, y). are three different y-values for each of
For example, lets consider the case. Thus, the relation is not a function.
following two relations. 2. Basic Logic
[1*, c1] 2.1. PropositionalLogic
A proposition is a statement that is either pTp pFp

true or false, but not both. Lets consider
declarative sentences for which it is Domination laws: p
meaningful to assign either of the two TT p
status values: true or false. Some FF
examples of propositions are given below. Idempotent laws: p
pp p
1. The sun is a star pp
2. Elephants are
mammals. Double negation law:
3. 2 + 3 = 5. ( p) p
However, a + 3 = b is not a proposition, Commutative laws: p

as it is neither true nor false. It depends on qqp p q
the values of the variables a and b. qp
TheLawofExcludedMiddle: For every
Associative laws:
proposition p, either p is true or p is false.
TheLawofContradiction: For every (p q) r p (q r)
proposition p, it is not the case that p is (p q) r p (q r)
both true and false.
Distributive laws:
Propositional logic is the area of logic
that deals with propositions. A truth table p (q r) (p q)
displays the relationships between the (p r) p (q r) (p
truth values of propositions. q) (p r)
A Boolean variable is one whose value
De Morgans laws:
is either true or false. Computer bit
operations correspond to logical (p q) p q (p q) p
operations of Boolean variables. q
The basic logical operators including
2.2. PredicateLogic
negation ( p), conjunction (p q),
disjunction (p q), exclusive or (p q), A predicate is a verb phrase template that
and implication (p q) are to be studied. describes a property of objects or a
Compound propositions may be formed relationship among objects represented by
using various logical operators. the variables. For example, in the
A compound proposition that is always sentence, Theflowerisred, the template
true is a tautology. A compound is red is a predicate. It describes the
proposition that is always false is a property of a flower. The same predicate
contradiction. A compound proposition may be used in other sentences too.
that is neither a tautology nor a Predicates are often given a name, e.g.,
contradiction is a contingency. Red or simply R can be used to
Compound propositions that always represent the predicate isred. Assuming R
have the same truth value are called as the name for the predicate isred,
logically equivalent (denoted by ). Some sentences that assert an object is of the
of the common equivalences are: color red can be represented as R(x),
where x represents an arbitrary object.
Identity laws: R(x) reads as xisred.
Quantifiers allow statements about logical equivalences cannot be captured by

entire collections of objects rather than propositional logic: Notallmenare
having to enumerate the objects by name. smokers and Somemendont smoke.
The Universal quantifier x asserts that Each of these two propositions is treated
a sentence is true for all values of variable independently in propositional logic.
x. There is no mechanism in propositional
logic to find out whether or not the two are
For example, x Tiger(x)
equivalent to one another. Hence, in
Mammal(x) means all tigers are mammals.
propositional logic, each equivalent
The Existential quantifier x asserts that proposition is treated individually rather
a sentence is true for at least one value of than dealing with a general formula that
variable x. covers all equivalences collectively.
For example, x Tiger(x) Man- Predicate logic is supposed to be a more
eater(x) means there exists at least one powerful logic that addresses these issues.
tiger that is a man-eater. In a sense, predicate logic (also known as
Thus, while universal quantification first-order logic or predicate calculus) is
uses implication, the existential an extension of propositional logic to
quantification naturally uses conjunction. formulas involving terms and predicates.
A variable x that is introduced into a
logical expression by a quantifier is bound 3. Proof Techniques
to the closest enclosing quantifier. [1*, c1]
A variable is said to be a free variable if
it is not bound to a quantifier. A proof is an argument that rigorously
Similarly, in a block-structured establishes the truth of a statement. Proofs
programming language, a variable in a can themselves be represented formally as
logical expression refers to the closest discrete structures.
quantifier within whose scope it appears. Statements used in a proof include
For example, in x (Cat(x) x axioms and postulates that are essentially
(Black(x))), x in Black(x) is universally the underlying assumptions about
quantified. The expression implies that mathematical structures, the hypotheses of
cats exist and everything is black. the theorem to be proved, and previously
Propositional logic falls short in proved theorems.
representing many assertions that are used A theorem is a statement that can be
in computer science and mathematics. It shown to be true.
also fails to compare equivalence and A lemma is a simple theorem used in the
some other types of relationship between proof of other theorems.
propositions. A corollary is a proposition that can be
For example, the assertion a is greater established directly from a theorem that
than1 is not a proposition because one has been proved.
cannot infer whether it is true or false A conjecture is a statement whose truth
without knowing the value of a. Thus, value is unknown.
propositional logic cannot deal with such When a conjectures proof is found, the
sentences. However, such assertions conjecture becomes a theorem. Many
appear quite often in mathematics and we
want to infer on those assertions. Also, the times conjectures are shown to be false
pattern involved in the following two
and, hence, are not theorems. 3.1. established if P(1) is true, and secondly,
MethodsofProvingTheorems k [2 ... n] if P(k) P(k + 1).
It may be noted here that, for a proof by
DirectProof. Direct proof is a technique to mathematical induction, it is not assumed
establish that the implication p q is true that P(k) is true for all positive integers k.
by showing that q must be true when p is Proving a theorem or proposition only
true. requires us to establish that if it is assumed
For example, to show that if n is odd P(k) is true for any arbitrary positive
then n21 is even, suppose n is odd, i.e., n integer k, then P(k + 1) is also true. The
= 2k + 1 for some integer k: correctness of mathematical induction as a
valid proof technique is beyond discussion
n2 = (2k + 1)2 = 4k2 + 4k + 1. of the current text. Let us prove the
following proposition using induction.
As the first two terms of the Right Hand Proposition: Thesumofthefirstn
Side (RHS) are even numbers irrespective positiveoddintegersP(n)isn2.
of the value of k, the Left Hand Side Basis Step: The proposition is true for n
(LHS) (i.e., n2) is an odd number. = 1 as P(1) = 1 2 = 1. The basis step is
Therefore, n21 is even. complete.
ProofbyContradiction. A proposition p Inductive Step: The induction
is true by contradiction if proved based on hypothesis (IH) is that the proposition is
the truth of the implication p q where true for n = k, k being an arbitrary positive
q is a contradiction. integer k.
For example, to show that the sum of 2x
+ 1 and 2y 1 is even, assume that the 1 + 3 + 5+ + (2k 1) = k2
sum of 2x + 1 and 2y 1is odd. In other
words, 2(x + y), which is a multiple of 2, Now, its to be shown that P(k) P(k +
is odd. This is a contradiction. Hence, the 1).
sum of 2x + 1 and 2y 1 is even.
An inference rule is a pattern P(k + 1) = 1 + 3 + 5+ +(2k 1) + (2k
establishing that if a set of premises are all + 1)
true, then it can be deduced that a certain = P(k) + (2k + 1)
conclusion statement is true. The reference = k2 + (2k + 1) [using IH]
rules of addition, simplification, and = k2 + 2k
conjunction need to be studied. + 1 = (k
ProofbyInduction. Proof by induction + 1)2
is done in two phases. First, the
proposition is established to be true for a Thus, it is shown that if the proposition
base casetypically for the positive is true for n = k, then it is also true for n =
integer 1. In the second phase, it is k + 1.
established that if the proposition holds for The basis step together with the
an arbitrary positive integer k, then it must inductive step of the proof show that P(1)
also hold for the next greater integer, k+ is true and the conditional statement P(k)
1. In other words, proof by induction is P(k + 1) is true for all positive integers
based on the rule of inference that tells us k. Hence, the proposition is proved.
that the truth of an infinite sequence of
propositions P(n), n [1 ] is 4. Basics of Counting
[1*c6] the total number of ways the two tasks can

be done, subtract the number of ways to do
The sum rule states that if a task t 1 can be both tasks from n1 + n2.
done in n1 ways and a second task t 2 can be
done in n2 ways, and if these tasks cannot If A and B are not disjoint, |A B| = |
be done at the same time, then there are A| + |B| |A B|.
n1+ n2 ways to do either task.
In other words, the principle of
If A and B are disjoint sets, then |A inclusionexclusion aims to ensure that the
B|=|A| + |B|. objects in the intersection of two sets are
In general if A1, A2, . , An are not counted more than once.
disjoint sets, then |A1 A2 Recursion is the general term for the
An| = |A1| + |A2| + + |An|. practice of defining an object in terms of
itself. There are recursive algorithms,
For example, if there are 200 athletes recursively defined functions, relations,
doing sprint events and 30 athletes who sets, etc.
participate in the long jump event, then A recursive function is a function that
how many ways are there to pick one calls itself. For example, we define f(n) =
athlete who is either a sprinter or a long 3 * f(n 1) for all n N and n 0 and
jumper? f(0) = 5.
Using the sum rule, the answer would be An algorithm is recursive if it solves a
200 + 30 = 230. problem by reducing it to an instance of
The product rule states that if a task t 1 the same problem with a smaller input.
can be done in n1 ways and a second task t2 A phenomenon is said to be random if
can be done in n2 ways after the first task individual outcomes are uncertain but the
has been done, then there are n1 * n2 ways long-term pattern of many individual
to do the procedure. outcomes is predictable.
The probability of any outcome for a
If A and B are disjoint sets, then |A random phenomenon is the proportion of
B| = |A| * |B|. times the outcome would occur in a very
In general if A1, A2, , An are long series of repetitions.
disjoint sets, then |A1 A2 An| The probability P(A) of any event A
= |A1| * |A2| * . * |An|. satisfies 0 P(A) 1. Any probability is a
number between 0 and 1. If S is the sample
For example, if there are 200 athletes space in a probability model, the P(S) = 1.
doing sprint events and 30 athletes who All possible outcomes together must have
participate in the long jump event, then probability of 1.
how many ways are there to pick two Two events A and B are disjoint if they
athletes so that one is a sprinter and the have no outcomes in common and so can
other is a long jumper? Using the product never occur together. If A and B are two
rule, the answer would be 200 * 30 = disjoint events, P(A or B) = P(A) + P(B).
6000. This is known as the addition rule for
The principleofinclusion-exclusion disjoint events.
states that if a task t 1 can be done in n1 If two events have no outcomes in
ways and a second task t2 can be done in n2 common, the probability that one or the
ways at the same time with t1, then to find
other occurs is the sum of their individual = (V, E) where V = {A, B, C}, E = {e1, e2,
probabilities. e3}, and F = {(e1, (A, C)), (e2, (C, B)),
Permutation is an arrangement of (e3, (B, A))}.
objects in which the order matters without The graph in Figure 14.8 is a simple
repetition. One can choose r objects in a graph that consists of a set of vertices or
particular order from a total of n objects nodes and a set of edges connecting
by using nPr ways, where, npr = n! / (n r)!. unordered pairs.
Various notations like nPr and P(n, r) are The edges in simple graphs are
used to represent the number of undirected. Such graphs are also referred
permutations of a set of n objects taken r at to as undirected graphs.
a time. For example, in Figure 14.8, (e1, (A, C))
Combination is a selection of objects in may be replaced by (e1, (C, A)) as the pair
which the order does not matter without between vertices A and C is unordered.
repetition. This is different from a This holds good for the other two edges
permutation because the order does not too.
matter. If the order is only changed (and In a multigraph, more than one edge
not the members) then no new may connect the same two vertices. Two
combination is formed. One can choose r or more connecting edges between the
objects in any order from a total of n same pair of vertices may reflect multiple
objects by using nCr ways, where, nCr = n! / associations between the same two
[r! * (n r)!]. vertices. Such edges are called parallel or
5. Graphs and Trees multiple edges.
[1*, For example, in Figure 14.9, the edges
e3 and e4 are both between A and B.
c10, c11] 5.1. Graphs Figure 14.9 is a multigraph where edges e3
and e4 are multiple edges.
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.9. Example of a Multigraph
In a pseudograph, edges connecting a

Figure 14.8. Example of a Graph node to itself are allowed. Such edges are
called loops.
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
Figure 14.10. Example of a Pseudograph Figure 14.12. Example of a Weighted Graph
For example, in Figure 14.10, the edge In a weighted graph G = (V, E), each
e4 both starts and ends at B. Figure 14.10 edge has a weight associated with it. The
is a pseudograph in which e4 is a loop. 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
Figure 14.11. Example of a Directed Graph where e = {u, v}, the following
terminologies are often used:
A directed graph G = (V, E) consists of a
set of vertices V and a set of edges E that u, v are said to be adjacentor
neighborsor connected.
are ordered pairs of elements of V. A
edge e is incident with vertices u and
directed graph may contain loops.
v.
For example, in Figure 14.11, G = (V, E)
edge e connects u and v.
where V = {A, B, C}, E = {e1, e2, e3},
and F = {(e1, (A, C)), (e2, (B, C)), (e3, (B, vertices u and v are endpoints for edge
A))}. e.
If vertex v V, the set of vertices in the

undirected graph G(V, E), then:
the degree of v, deg(v), is its number

of incident edges, except that any self-
loops are counted twice.
a vertex with degree 0 is called an A cycle on n vertices Cn for any n 3 is

isolatedvertex. a simple graph where V = {v1, v2, , vn}
a vertex of degree 1 is called a
and E = {{v1, v2}, {v2, v3}, , {vn1, vn},
pendantvertex.
{vn, v1}}.
Let G(V, E) be a directed graph. If e(u, For example, Figure 14.13 illustrates
v) is an edge of G, then the following two cycles of length 3 and 4.
terminologies are often used:
u is adjacentto v, and v is adjacent

from u.
e comesfrom u and goesto v.
e connects u to v, or e goesfrom u to
v.
the initialvertex of e is u.
the terminalvertex of e is v. Figure 14.13. Example of Cycles C3 and C4
If vertex v is in the set of vertices for the An adjacency list is a table with one row
directed graph G(V, E), then
per vertex, listing its adjacent vertices. The
adjacency listing for a directed graph
in-degree of v, deg(v), is the number
maintains a listing of the terminal nodes
of edges going to v, i.e., for which v is
for each of the vertex in the graph.
the terminal vertex.
out-degree of v, deg+(v), is the number Adjacency
Vertex
of edges coming from v, i.e., for which List
v is the initial vertex. A B, C
degree of v, deg(v) = deg(v) + deg+
(v), is the sum of vs in-degree and out- B A, B, C
degree.
a loop at a vertex contributes 1 to both C A, B
indegree and out-degree of this vertex. Figure 14.14. Adjacency Lists for Graphs in Figures
14.10
and 14.11
It may be noted that, following the
definitions above, the degree of a node is
unchanged whether we consider its edges For example, Figure 14.14 illustrates the
to be directed or undirected. adjacency lists for the pseudograph in
In an undirected graph, a path of length Figure 14.10 and the directed graph in
n from u to v is a sequence of n adjacent Figure 14.11. As the out-degree of vertex
C in Figure 14.11 is zero, there is no entry
edges from vertex u to vertex v.
against C in the adjacency list.
A path is a circuit if u=v. Different representations for a graph
A path traversesthe vertices along it. like adjacency matrix, incidence matrix,
A path is simple if it contains no edge and adjacency listsneed to be studied.
more than once.
5.2. Trees
A tree T(N, E) is a hierarchical data to v. Each node in the tree has a unique
structure of n = |N| nodes with a specially parent node except the root of the tree.
designated root node R while the For example, in Figure 14.15, root node
remaining n 1 nodes form subtrees under A is the parent node for nodes B, C, and D.
the root node R. The number of edges |E| Similarly, B is the parent of E, F, G, and so
in a tree would always be equal to |N| 1. on. The root node A does not have any
The subtree at node X is the subgraph of parent.
the tree consisting of node X and its A node that has children is called an
descendants and all edges incident to those internal node.
descendants. As an alternate to this For example, in Figure 14.15, node A or
recursive definition, a tree may be defined node B are examples of internal nodes.
as a connected undirected graph with no The degree of a node in a tree is the
simple circuits. 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
Figure 14.15. Nodes B, C, and D are at
Figure 14.15. Example of a Tree level 1. The remaining nodes in Figure
14.15 are all at level 2.
However, one should remember that a The height of a tree is the maximum of
tree is strictly hierarchical in nature as the levels of nodes in the tree.
compared to a graph, which is flat. In case For example, in Figure 14.15, the height
of a tree, an ordered pair is built between of the tree is 2.
two nodes as parent and child. Each child A node is called a leaf if it has no
node in a tree is associated with only one children. The degree of a leaf node is 0.
parent node, whereas this restriction For example, in Figure 14.15, nodes E
becomes meaningless for a graph where through K are all leaf nodes with degree 0.
no parent-child association exists. The ancestors or predecessors of a
An undirected graph is a tree if and only nonroot node X are all the nodes in the
if there is a unique simple path between path from root to node X.
any two of its vertices. For example, in Figure 14.15, nodes A
Figure 14.15 presents a tree T(N, E) and D form the set of ancestors for J.
where the set of nodes N = {A, B, C, D, E, The successors or descendents of a node
F, G, H, I, J, K}. The edge set E is {(A, B), X are all the nodes that have X as its
(A, C), (A, D), (B, E), (B, F), (B, G), (C, ancestor. For a tree with n nodes, all the
H), (C, I), (D, J), (D, K)}. remaining n 1 nodes are successors of
The parent of a nonroot node v is the the root node.
unique node u with a directed edge from u
For example, in Figure 14.15, node B For example, in Figure 14.16, the two
has successors in E, F, and G. binary trees are different as the positions
IfnodeXisanancestorofnodeY,then of occurrences of the children of A are
nodeYisasuccessorofX. different in the two trees.
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.
Twosiblingnodesareofthesamelevel,
buttwonodesinthesamelevelarenot
necessarilysiblings.
A tree is called an ordered tree if the
relative position of occurrences of children
nodes is significant. Figure 14.17. Example of a Full Binary Tree
For example, a family tree is an ordered
tree if, as a rule, the name of an elder According to [1*], a binary tree is called
sibling appears always before (i.e., on the a full binary tree if every internal node has
left of) the younger sibling. exactly two children.
In an unordered tree, the relative For example, the binary tree in Figure
position of occurrences between the 14.17 is a full binary tree, as both of the
siblings does not bear any significance and two internal nodes A and B are of degree
may be altered arbitrarily.
2.
A binary tree is formed with zero or
A full binary tree following the
more nodes where there is a root node R
definition above is also referred to as a
and all the remaining nodes form a pair of strictlybinarytree.
ordered subtrees under the root node. For example, both binary trees in Figure
In a binary tree, no internal node can 14.18 are complete binary trees. The tree
have more than two children. However, in Figure 14.18(a) is a complete as well as
one must consider that besides this a full binary tree. A complete binary tree
criterion in terms of the degree of internal has all its levels, except possibly the last
nodes, a binary tree is always ordered. If one, filled up to capacity. In case the last
the positions of the left and right subtrees level of a complete binary tree is not full,
for any node in the tree are swapped, then nodes occur from the leftmost positions
a new tree is derived. available.
Figure 14.16. Examples of Binary Trees

Tree traversals may be defined recursively.

If T is binary tree with root R and the
remaining 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
Figure 14.18. Example of Complete Binary Trees The recursive process of finding the
preorder traversal of the subtrees continues
Interestingly, following the definitions till the subtrees are found to be Null. Here,
above, the tree in Figure 14.18(b) is a commas have been used as delimiters for
complete but not full binary tree as node B the sake of improved readability.
has only one child in D. On the contrary, The postorder and in-order may be
the tree in Figure 14.17 is a full but not similarly defined using eqn. 2 and eqn. 3
completebinary tree, as the children of respectively.
B occur in the tree while the children of C
do not appear in the last level. PostOrder(T) = PostOrder(TL),
A binary tree of height H is balanced if PostOrder(TR), R eqn 2
all its leaf nodes occur at levels H or H InOrder(T) = InOrder(TL), R,
1. For example, all three binary trees in InOrder(TR) eqn 3
Figures 14.17 and 14.18 are balanced
binary trees.
There are at most 2H leaves in a binary
tree of height H. In other words, if a binary
tree with L leaves is full and balanced,
then its height is H = log2L.
For example, this statement is true for
the two trees in Figures 14.17 and 14.18(a)
as both trees are full and balanced.
However, the expression 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
Figure 14.19. A Binary Search Tree
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 For example, the tree in Figure 14.19 is
every key value in its right subtree and a binary search tree (BST). The preorder,
greater than every key value in its left postorder, and in-order traversal outputs
subtree. for the BST are given below in their
A traversal algorithm is a procedure for respective order.
systematically visiting every node of a
binary tree.
Preorder output: 9, 5, 2, 1, 4, 7, 6, 8, 13, although it might take an infinite amount

11, of time.
10, 15 A continuous random variable is used to
Postorder output: 1, 4, 2, 6, 8, 7, 5, 10, measure an uncountable number of values
11, 15, even if an infinite amount of time is given.
13, 9 For example, if a random variable X
In-order output: 1, 2, 4, 5, 6, 7, 8, 9, 10, represents an outcome that is a real
11, number between 1 and 100, then X may
13, 15 have an infinite number of values. One can
never list all possible outcomes for X even
Further discussion on trees and their if an infinite amount of time is allowed.
usage has been included in section 6, Data Here, X is a continuous random variable.
Structure and Representation, of the On the contrary, for the same interval of 1
Computing Foundations KA. to 100, another random variable Y can be
used to list all the integer values in the
6. Discrete Probability range. Here, Y is a discrete random
[1*, c7] variable.
An upper-case letter, say X, will
Probability is the mathematical description represent the nameof the random variable.
of randomness. Basic definition of Its lower-case counterpart, x, will
probability and randomness has been represent the value of the random variable.
defined in section 4 of this KA. Here, let The probability that the random variable
us start with the concepts behind X will equal x is:
probability distribution and discrete
probability. P(X = x) or, more simply, P(x).
A probability model is a mathematical
description of a random phenomenon A probability distribution (density)
consisting of two parts: a sample space S function is a table, formula, or graph that
and a way of assigning probabilities to describes the values of a random variable
events. The sample space defines the set of and the probability associated with these
all possible outcomes, whereas an event is values.
a subset of a sample space representing a Probabilities associated with discrete
possible outcome or a set of outcomes. random variables have the following
A random variable is a function or rule properties:
that assigns a number to each outcome.
Basically, it is just a symbol that i. 0 P(x) 1 for
represents the outcome of an experiment. all x ii. P(x) = 1
For example, let X be the number of
heads when the experiment is flipping a A discrete probability distribution can
coin n times. Similarly, let S be the speed be represented as a discrete random
of a car as registered on a radar detector. variable.
The values for a random variable could X 1 2 3 4 5 6
be discrete or continuous depending on the
experiment. P(x 1/6 1/6 1/6 1/6 1/6 1/6
A discrete random variable can hold all )
possible outcomes without missing any, Figure 14.20. A Discrete Probability Function for a
Rolling Die
The mean of a probability distribution is likely to be close to the expected value

model is the sum of the product terms for of one experiment. Moreover, the average
individual events and its outcome value is more likely to be closer to the
probability. In other words, for the expected value of any one experiment as
possible outcomes x1, x2, , xn in a the number of experiments increases.
sample space S if pk is the probability of
outcome xk, the mean of this probability 7. Finite State Machines
would be [1*, c13]
= x1p1 + x2p2 + + xnpn.
A computer system may be abstracted as a
For example, the mean of the probability
density for the distribution in Figure 14.20 mapping from state to state driven by
inputs. In other words, a system may be
would be
considered as a transition function T: S I
1 * (1/6) + 2 * (1/6) + 3 * (1/6) + 4 * S O, where S is the set of states and I,
(1/6) + 5 O are the input and output functions.
* (1/6) + 6 * (1/6) If the state set S is finite (not infinite),
= 21 * (1/6) = 3.5 the system is called a finitestatemachine
(FSM).
Here, the sample space refers to the set Alternately, a finite state machine
of all possible outcomes. (FSM) is a mathematical abstraction
The variance s2 of a discrete probability composed of a finite number of states and
model is: s2 = (x1 )2p1 + (x2 )2p2 + transitions between those states. If the
+ (xk )2pk. The standarddeviations is domain S I is reasonably small, then one
can specify T explicitly using diagrams
the square root of the variance.
similar to a flow graph to illustrate the way
For example, for the probability
logic flows for different inputs. However,
distribution in Figure 14.20, the variation
this is practical only for machines that
2 would be
have a very small information capacity.
An FSM has a finite internal memory,
s2 = [(1 3.5)2 * (1/6) + (2 3.5)2 * (1/6)
an input feature that reads symbols in a
+
sequence and one at a time, and an output
(3 3.5)2 * (1/6) + (4 3.5)2 * (1/6) +
feature.
(5
3.5)2 * (1/6) + (6 3.5)2 * (1/6)] The operation of an FSM begins from a
start state, goes through transitions
= (6.25 + 2.25 + 0.25 + 0.5 + 2.25 +
depending on input to different states, and
6.25) *
can end in any valid state. However, only a
(1/6)
few of all the states mark a successful flow
= 17.5 *
of operation. These are called accept
(1/6) =
states.
2.90
The information capacity of an FSM is
C = log |S|. Thus, if we represent a
standard deviation s = machine having an information capacity of
These numbers indeed aim to derive the C bits as an FSM, then its state transition
average value from repeated experiments. graph will have |S| = 2C nodes. A finite
This is based on the single most important state machine is formally defined as M=
phenomenon of probability, i.e., the (S, I, O, f, g, s0).
average value from repeated experiments
S is the state set; Input Input

I is the set of input State
symbols; O is the set of 0 1 0 1
output symbols; f is the S0 3 2 S2 S1
state transition function;
S1 3 2 S2 S2
g is the output function;
and s0 is the initial state. S2 2 3 S2 S0
(b)
Given an input x I on state Sk, the

Figure 14.22. Tabular Representation of an FSM
FSM makes a transition to state S h
following state transition function f and
The state transition and output values
produces an output y O using the output
for different inputs on different states may
function g.
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 Figure 14.21.
8. Grammars
[1*, c13]
The grammar of a natural language tells us

Figure 14.21. Example of an FSM whether a combination of words makes a
valid sentence. Unlike natural languages, a
For example, Figure 14.21 illustrates an formal language is specified by a well-
FSM with S0 as the start state and S1 as the defined set of rules for syntaxes. The valid
final state. Here, S = {S0, S1, S2}; I = {0, sentences of a formal language can be
1}; O = {2, 3}; f(S0, 0) = S2, f(S0, 1) = S1, described by a grammar with the help of
f(S1, 0) = S2, f(S1, 1) = S2, f(S2, 0) = S2, these rules, referred to as productionrules.
f(S2, 1) = S0; g(S0, 0) = 3, g(S0, 1) = 2, g(S1, A formal language is a set of finite-
0) = 3, g(S1, 1) = 2, g(S2, 0) = 2, g(S2, 1) = length words or strings over some finite
3. alphabet, and a grammar specifies the
Current Input rules for formation of these words or
State strings. The entire set of words that are
0 1
valid for a grammar constitutes the
S0 S2 S1 language for the grammar. Thus, the
S1 S2 S2 grammar G is any compact, precise
mathematical definition of a language L as
S2 S2 S0 opposed to just a raw listing of all of the
(a) languages legal sentences or examples of
those sentences.
Current Output State A grammar implies an algorithm that
would generate all legal sentences of the
language. There are different types of 8.1.LanguageRecognition

grammars. A phrase-structure or Type-0
grammar G = (V, T, S, P) is a 4-tuple in Formal grammars can be classified
which: according to the types of productions that
are allowed. The Chomsky hierarchy
V is the vocabulary, i.e., set of words. (introduced by Noam Chomsky in 1956)
T V is a set of words called describes such a classification scheme.
terminals.
S N is a special word called the
start symbol.
P is the set of productions rules for
substituting 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 Figure 14.23. Chomsky Hierarchy of Grammars
strings containing nonterminals until no
more nonterminal symbols are present in As illustrated in Figure 14.23, we infer
the string. The start symbol S is a the following on different types of
nonterminal. grammars:
The language generated by a formal
grammar G, denoted by L(G), is the set of 1. Every regular grammar is a context-
all strings over the set of alphabets V that free grammar (CFG).
can be generated, starting with the start 2. Every CFG is a context-sensitive
symbol, by applying production rules until grammar (CSG).
all the nonterminal symbols are replaced 3. Every CSG is a phrase-structure
in the string. grammar (PSG).
For example, let G = ({S, A, a, b}, {a,
Context-Sensitive Grammar: All
b}, S, {S aA, S b, A aa}). Here,
fragments in the RHS are either longer
the set of terminals are N = {S, A}, where
than the corresponding fragments in the
S is the start symbol. The three production
LHS or empty, i.e., if b a, then |b| < |a|
rules for the grammar are given as P1: S
or a = .
aA; P2: S b; P3: A aa.
A formal language is context-sensitive if
Applying the production rules in all
a context-sensitive grammar generates it.
possible ways, the following words may
Context-Free Grammar: All fragments
be generated from the start symbol.
in the LHS are of length 1, i.e., if A a,
then |A| = 1 for all A N.
S aA (using P1 on start symbol)
The term context-free derives from the
aaa (using P3)
fact that A can always be replaced by a,
S b (using P2 on start symbol)
regardless of the context in which it
occurs.
Nothing else can be derived for G. Thus,
A formal language is context-free if a
the language of the grammar G consists of
contextfree grammar generates it. Context-
only two words: L(G) = {aaa, b}.
free languages are the theoretical basis for 9. Numerical Precision, Accuracy, and
the syntax of most programming Errors
languages. [2*, c2]
RegularGrammar. All fragments in the
RHS are either single terminals or a pair The main goal of numerical analysis is to
built by a terminal and a nonterminal; i.e., develop efficient algorithms for computing
if A a, then either a T, or a = cD, or a precise numerical values of functions,
= Dc for c T, D N. solutions of algebraic and differential
If a = cD, then the grammar is called a equations, optimization problems, etc.
right linear grammar. On the other hand, if A matter of fact is that all digital
a = Dc, then the grammar is called a left computers can only store finite numbers.
linear grammar. Both the right linear and In other words, there is no way that a
left linear grammars are regular or Type-3 computer can represent an infinitely large
grammar. numberbe it an integer, rational number,
The language L(G) generated by a or any real or all complex numbers (see
regular grammar G is called a regular section 10, Number Theory). So the
language. mathematics of approximation becomes
A regular expression A is a string (or very critical to handle all the numbers in
pattern) formed from the following six the finite range that a computer can
pieces of information: a S, the set of handle.
alphabets, e, 0 and the operations, OR (+), Each number in a computer is assigned
PRODUCT (.), CONCATENATION (*). a location or word, consisting of a
The language of G, L(G) is equal to all specified number of binary digits or bits. A
those strings that match G, L(G) = {x k bit word can store a total of N = 2 k
S*|x matches G}. different numbers.
For example, a computer that uses 32 bit
For any a S, L(a) = a; L(e) = {}; arithmetic can store a total of N = 2 32 4.3
L(0) = 0. 109 different numbers, while another one
+ functions as an or, L(A + B) = L(A) that uses 64 bits can handle N = 2 64 1.84
L(B). 1019 different numbers. The question is
. creates a product structure, L(AB) = how to distribute these N numbers over the
L(A) . real line for maximum efficiency and
L(B). accuracy in practical computations.
* denotes concatenation, L(A*) = One evident choice is to distribute them
{x1x2xn | xi L(A) and n 0} evenly, leading to fixed-point arithmetic.
In this system, the first bit in a word is
For example, the regular expression used to represent a sign and the remaining
(ab)* matches the set of strings: {e, ab, bits are treated for integer values. This
abab, ababab, abababab, }. allows representation of the integers from
For example, the regular expression 1 N, i.e., = 1 2k1 to 1. As an
(aa)* matches the set of strings on one approximating method, this is not good for
letter athat have even length. noninteger numbers.
For example, the regular expression Another option is to space the numbers
(aaa)* + (aaaaa)* matches the set of closely togethersay with a uniform gap
strings of length equal to a multiple of 3 or of 2nand so distribute the total N
5. numbers uniformly over the interval
2n1N < x 2n1N. Real numbers lying determiner of the size of the error. The
between the gaps are represented by either present convention is that errors are
rounding (meaning the closest exact always 0, and are = 0 if and only if the
representative) or chopping (meaning the approximation is exact.
exact representative immediately below An approximation x* has k significant
or above, if negativethe number). decimal digits if its relative error is < 5
Numbers lying beyond the range must 10k1. This means that the first k digits of
be represented by the largest (or largest x* following its first nonzero digit are the
negative) number that can be represented. same as those of x.
This becomes a symbol for overflow. Significant digits are the digits of a
Overflow occurs when a computation number that are known to be correct. In a
produces a value larger than the maximum measurement, one uncertain digit is
value in the range. included.
When processing speed is a significant For example, measurement of length
bottleneck, the use of the fixed-point with a ruler of 15.5 mm with 0.5 mm
representations is an attractive and faster maximum allowable error has 2 significant
alternative to the more cumbersome digits, whereas a measurement of the same
floating-point arithmetic most commonly length using a caliper and recorded as
used in practice. 15.47 mm with 0.01 mm maximum
Lets define a couple of very important allowable error has 3 significant digits.
terms: accuracy and precision as
associated with numerical analysis. 10. Number Theory
Accuracy is the closeness with which a [1*, c4]
measured or computed value agrees with
the true value. Number theory is one of the oldest
Precision, on the other hand, is the branches of pure mathematics and one of
closeness with which two or more the largest. Of course, it concerns
measured or computed values for the same questions about numbers, usually meaning
physical substance agree with each other. whole numbers and fractional or rational
In other words, precision is the closeness numbers. The different types of numbers
with which a number represents an exact include integer, real number, natural
value. number, complex number, rational
Let x be a real number and let x* be an number, etc.
approximation. The absoluteerror in the
approximation x* x is defined as | x* x 10.1.Divisibility
|. The relativeerror is defined as the ratio
of the absolute error to the size of x, i.e., | Lets start this section with a brief
x* x| / | x |, which assumes x 0; description of each of the above types of
otherwise, relative error is not defined. numbers, starting with the natural
For example, 1000000 is an numbers.
approximation to 1000001 with an NaturalNumbers. This group of
absolute error of 1 and a relative error of numbers starts at 1 and continues: 1, 2, 3,
106, while 10 is an approximation of 11 4, 5, and so on. Zero is not in this group.
with an absolute error of 1 and a relative There are no negative or fractional
error of 0.1. Typically, relative error is numbers in the group of natural numbers.
more intuitive and the preferred The common mathematical symbol for the
set of all natural numbers is N.
WholeNumbers. This group has all of Any real number multiple of i is an

the natural numbers in it plus the number imaginary number, e.g., i, 5i, 3.2i, 2.6i,
0. etc.
Unfortunately, not everyone accepts the Complex Numbers. A complex number
above definitions of natural and whole is a combination of a real number and an
numbers. There seems to be no general imaginary number in the form a + bi. The
agreement about whether to include 0 in real part is a, and b is called the imaginary
the set of natural numbers. part. The common mathematical symbol
Many mathematicians consider that, in for the set of all complex numbers is C.
Europe, the sequence of natural numbers For example, 2 + 3i, 35i, 7.3 + 0i, and 0
traditionally started with 1 (0 was not even + 5i.
considered to be a number by the Greeks). Consider the last two examples:
In the 19th century, set theoreticians and 7.3 + 0i is the same as the real number
other mathematicians started the 7.3. Thus, all real numbers are complex
convention of including 0 in the set of numbers with zero for the imaginary part.
natural numbers. Similarly, 0 + 5i is just the imaginary
Integers. This group has all the whole number 5i. Thus, all imaginary numbers
numbers in it and their negatives. The are complex numbers with zero for the real
common mathematical symbol for the set part.
of all integers is Z, i.e., Z = {, 3, 2, Elementary number theory involves
1, 0, 1, 2, 3, }. divisibility among integers. Let a, b Z
RationalNumbers. These are any with a 0.The expression a|b, i.e., a
numbers that can be expressed as a ratio of dividesbif c Z: b = ac, i.e., there is an
two integers. The common symbol for the integer c such that c times a equals b.
set of all rational numbers is Q. For example, 3|12 is true, but 3|7 is
Rational numbers may be classified into false.
three types, based on how the decimals If a divides b, then we say that ais a
act. The decimals either do not exist, e.g., factor of bor ais a divisor of b, and b is a
15, or, when decimals do exist, they may multiple of a. b is even if and only if 2|b.
terminate, as in 15.6, or they may repeat
Let a,d Z with d > 1. Then amodd
with a pattern, as in 1.666..., (which is
denotes that the remainder r from the
5/3).
division algorithm with dividend a and
Irrational Numbers. These are numbers
divisor d, i.e., the remainder when a is
that cannot be expressed as an integer
divided by d. We can compute (amodd)
divided by an integer. These numbers have
by: ad*a/d, where a/d represents
decimals that never terminate and never
the floor of the real number.
repeat with a pattern, e.g., PI or 2.
RealNumbers. This group is made up of Let Z+ = {n Z | n > 0} and a,b Z, m
all the rational and irrational numbers. The Z+, then a is congruent to bmodulom,
numbers that are encountered when written as a b(modm), if and only if m|
studying algebra are real numbers. The ab.
common mathematical symbol for the set Alternately, a is congruent to bmodulo
of all real numbers is R. mif and only if (ab)modm=0.
ImaginaryNumbers. These are all based
10.2.PrimeNumber,GCD
on the imaginary number i. This imaginary
number is equal to the square root of 1.
An integer p > 1 is prime if and only if it is structures. Each of these is defined in this
not the product of any two integers greater section.
than 1, i.e., p is prime if p > 1 a, b 11.1. Group
N: a > 1, b > 1, a * b = p.
The only positive factors of a prime p A set S closed under a binary operation
are 1 and p itself. For example, the forms a group if the binary operation
numbers 2, 13, 29, 61, etc. are prime satisfies the following four criteria:
numbers. Nonprime integers greater than 1
are called composite numbers. A Associative: a, b, c S, the
composite number may be composed by equation (a b)
multiplying two integers greater than 1. c = a (b c) holds.
There are many interesting applications Identity: There exists an identity
of prime numbers; among them are the element I S such that for all a S,
publickey cryptography scheme, which I a = a I = a.
involves the exchange of public keys Inverse: Every element a S, has an
containing the product p*q of two random inverse a' S with respect to the
large primes p and q (a private key) that binary operation, i.e., a a' = I; for
must be kept secret by a given party. example, the set of integers Z with
The greatest common divisor gcd(a, b) respect to the addition operation is a
of integers a, b is the greatest integer d that group. The identity element of the set
is a divisor both of a and of b, i.e., d = is 0 for the addition operation. x
Z, the inverse of x would be x, which
gcd(a, b) for max(d: d|a d|b) is also included in Z.
For example, gcd(24, 36) = 12. Closure property: a, b S, the
Integers a and b are called relatively result of the operation a b S.
prime or coprime if and only if their GCD A group that is commutative, i.e., a b
is 1. = b a, is known as a commutative or
For example, neither 35 nor 6 are prime, Abelian group.
but they are coprime as these two numbers
have no common factors greater than 1, so The set of natural numbers N (with the
their GCD is 1. operation of addition) is not a group, since
A set of integers X = {i1, i2, } is there is no inverse for any x > 0 in the set
relatively prime if all possible pairs ih, ik, h of natural numbers. Thus, the third rule (of
k drawn from the set X are relatively inverse) for our operation is violated.
prime. However, the set of natural number has
some structure.
11. Algebraic Structures Sets with an associative operation (the
first condition above) are called
This section introduces a few semigroups; if they also have an identity
representations used in higher algebra. An element (the second condition), then they
algebraic structure consists of one or two are called monoids.
sets closed under some operations and Our set of natural numbers under
satisfying a number of axioms, including addition is then an example of a monoid, a
none. structure that is not quite a group because
For example, group, monoid, ring, and it is missing the requirement that every
lattice are examples of algebraic
element have an inverse under the A group G is cyclic if G = {an for any
operation. integer n}.
A monoid is a set S that is closed under Since any group generated by an
a single associative binary operation and element in a group is a subgroup of that
has an identity element I S such that for group, showing that the only subgroup of a
all a S, I a = a I = a. A monoid must group G that contains a is G itself suffices
contain at least one element. to show that G is cyclic.
For example, the set of natural numbers For example, the group G = {0, 2, 4, 6,
N forms a commutative monoid under 1, 3, 5, 7}, with respect to addition modulo
addition with identity element 0. The same 8 operation, is cyclic. The subgroups J=
set of natural numbers N also forms a {0, 4} and H= {0, 2, 4, 6} are also cyclic.
monoid under multiplication with identity 11.2. Rings
element 1. The set of positive integers P
forms a commutative monoid under If we take an Abelian group and define a
multiplication with identity element 1. second operation on it, a new structure is
It may be noted that, unlike those in a found that is different from just a group. If
group, elements of a monoid need not this second operation is associative and is
have inverses. A monoid can also be distributive over the first, then we have a
thought of as a semigroup with an identity ring.
element. A ring is a triple of the form (S, +, ),
A subgroup is a group H contained where (S, +) is an Abelian group, (S, ) is a
within a bigger one, G,such that the semigroup, and is distributive over +;
identity element of G is contained in H, i.e., a, b, c S, the equation a (b + c) =
and whenever h1 and h2 are in H, then so (a b) + (a c) holds. Further, if is
are h1 h2 and h11. Thus, the elements of H, commutative, then the ring is said to be
equipped with the group operation on G commutative. If there is an identity
restricted to H, indeed form a group. element for the operation, then the ring is
Given any subset S of a group G, the said to have an identity.
subgroup generated by S consists of For example, (Z, +, *), i.e., the set of
products of elements of S and their integers Z, with the usual addition and
inverses. It is the smallest subgroup of G multiplication operations, is a ring. As (Z,
containing S. *) is commutative, this ring is a
For example, let G be the Abelian group commutative or Abelian ring. The ring has
whose elements are G = {0, 2, 4, 6, 1, 3, 5, 1 as its identity element.
7} and whose group operation is addition Lets note that the second operation may
modulo 8. This group has a pair of not have an identity element, nor do we
nontrivial subgroups: J= {0, 4} and H= need to find an inverse for every element
{0, 2, 4, 6}, where J is also a subgroup of with respect to this second operation. As
for what distributive means, intuitively it
H.
is what we do in elementary mathematics
In group theory, a cyclic group is a
when performing the following change: a
group that can be generated by a single
* (b + c) = (a * b) + (a * c).
element, in the sense that the group has an
A field is a ring for which the elements
element a (called the generator of the
of the set, excluding 0, form an Abelian
group) such that, when written
group with the second operation.
multiplicatively, every element of the
group is a power of a.
A simple example of a field is the field R, where a,b are integers and b 0.
of rational numbers (R, +, *) with the The additive inverse of such a fraction is
usual addition and multiplication simply a/b, and the multiplicative inverse
operations. The numbers of the format a/b is b/a provided that a 0.
Rosen [1*]
2011
Cheney and
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
REFERENCES ACKNOWLEDGMENTS
[1*] K. Rosen, DiscreteMathematicsand The author thankfully acknowledges the

ItsApplications, 7th ed., McGraw- contribution of Prof. Arun Kumar
Hill, 2011. Chatterjee, Ex-Head, Department of
Mathematics, Manipur University, India,
[2*] E.W. Cheney and D.R. Kincaid, and Prof. Devadatta Sinha, Ex-Head,
NumericalMathematicsand Department of Computer Science and
Computing, 6th ed., Brooks/Cole, Engineering, University of Calcutta,
2007.
India, in preparing this chapter on

Mathematical Foundations.
CHAPTER 15 ENGINEERING
FOUNDATIONS
ACRONYMS measurement; engineering design;

CAD Computer-Aided Design modeling, prototyping, and simulation;
standards; and root cause analysis.
Capability Maturity Model Application of this knowledge, as
CMMI
Integration appropriate, will allow software engineers
pdf Probability Density Function to develop and maintain software more
pmf Probability Mass Function efficiently and effectively. Completing
their engineering work efficiently and
RCA Root Cause Analysis
effectively is a goal of all engineers in all
SDLC Software Development Life Cycle engineering disciplines.
INTRODUCTION
IEEE defines engineering as the ENGINEERING FOUNDATIONS
application of a systematic, disciplined,
quantifiable approach to structures, The breakdown of topics for the
machines, products, systems or processes Engineering Foundations KA is shown in
[1]. This chapter outlines some of the Figure 15.1.
engineering foundational skills and
techniques that are useful for a software1. Empirical Methods and Experimental
engineer. The focus is on topics that Techniques
support other KAs while minimizing [2*, c1]
duplication of subjects covered elsewhere
in this document. An engineering method for problem
As the theory and practice of software solving involves proposing solutions or
engineering matures, it is increasingly models of solutions and then conducting
apparent that software engineering is an experiments or tests to study the proposed
engineering discipline that is based on solutions or models. Thus, engineers must
knowledge and skills common to all understand how to create an experiment
engineering disciplines. This Engineering and then analyze the results of the
Foundations knowledge area (KA) is experiment in order to evaluate the
concerned with the engineering proposed solution. Empirical methods and
foundations that apply to software experimental techniques help the engineer
engineering and other engineering to describe and understand variability in
disciplines. Topics in this KA include their observations, to identify the sources
empirical methods and experimental of variability, and to make decisions.
techniques; statistical analysis;
Three different types of empirical A designed or controlled experiment is an

studies commonly used in engineering investigation of a testable hypothesis
efforts are designed experiments, where one or more independent variables
observational studies, and retrospective are manipulated to measure their effect on
studies. Brief descriptions of the one or more dependent variables. A
commonly used methods are given below. precondition for conducting an experiment
is the existence of a clear hypothesis. It is
1.1. DesignedExperiment important for an engineer to understand
how to formulate clear hypotheses.
15-1
Figure 15.1. Breakdown of Topics for the Engineering Foundations KA

Designed experiments allow engineers contextual conditions are relevant and the
to determine in precise terms how the boundaries between the phenomena and
variables are related and, specifically, context are not clear. 1.3. Retrospective
whether a cause-effect relationship exists Study
between them. Each combination of values
of the independent variables is a treatment. A retrospective study involves the analysis
The simplest experiments have just two of historical data. Retrospective studies
treatments representing two levels of a are also known as historical studies. This
single independent variable (e.g., using a type of study uses data (regarding some
tool vs. not using a tool). More complex phenomenon) that has been archived over
experimental designs arise when more time. This archived data is then analyzed
than two levels, more than one in an attempt to find a relationship
independent variable, or any dependent between variables, to predict future events,
variables are used. or to identify trends. The quality of the
analysis results will depend on the quality
1.2. ObservationalStudy of the information contained in the
archived data. Historical data may be
An observational or case study is an incomplete, inconsistently measured, or
empirical inquiry that makes observations incorrect.
of processes or phenomena within a real- 2.Statistical Analysis
life context. While an experiment [2*, c9s1, c2s1] [3*, c10s3]
deliberately ignores context, an
observational or case study includes In order to carry out their responsibilities,
context as part of the observation. A case engineers must understand how different
study is most useful when the focus of the product and process characteristics vary.
study is on how and why questions, when Engineers often come across situations
the behavior of those involved in the study where the relationship between different
cannot be manipulated, and when variables needs to be studied. An
important point to note is that most of the samples must be drawn in a manner so as
studies are carried out on the basis of to ensure that the draws are independent,
samples and so the observed results need and the rules of drawing the samples must
to be understood with respect to the full be predefined so that the probability of
population. Engineers must, therefore, selecting a particular sampling unit is
develop an adequate understanding of known beforehand. This method of
statistical techniques for collecting reliable selecting samples is called probability
data in terms of sampling and analysis to sampling.
arrive at results that can be generalized. Random variable. In statistical
These techniques are discussed below. terminology, the process of making
observations or measurements on the
2.1. UnitofAnalysis(SamplingUnits), sampling units being studied is referred to
Population,andSample as conducting the experiment. For
example, if the experiment is to toss a coin
Unitofanalysis.While carrying out any 10 times and then count the number of
empirical study, observations need to be times the coin lands on heads, each 10
made on chosen units called the units of tosses of the coin is a sampling unit and
analysis or sampling units. The unit of the number of heads for a given sample is
analysis must be identified and must be the observation or outcome for the
appropriate for the analysis. For example, experiment. The outcome of an experiment
when a software product company wants is obtained in terms of real numbers and
to find the perceived usability of a defines the random variable being studied.
software product, the user or the software Thus, the attribute of the items being
function may be the unit of analysis. measured at the outcome of the
Population. The set of all respondents or experiment represents the random variable
items (possible sampling units) to be being studied; the observation obtained
studied forms the population. As an from a particular sampling unit is a
example, consider the case of studying the particular realization of the random
perceived usability of a software product. variable. In the example of the coin toss,
In this case, the set of all possible users the random variable is the number of
forms the population. heads observed for each experiment. In
While defining the population, care statistical studies, attempts are made to
must be exercised to understand the study understand population characteristics on
and target population. There are cases the basis of samples.
when the population studied and the The set of possible values of a random
population for which the results are being variable may be finite or infinite but
generalized may be different. For example, countable (e.g., the set of all integers or
when the study population consists of only the set of all odd numbers). In such a case,
past observations and generalizations are the random variable is called a discrete
required for the future, the study randomvariable. In other cases, the
population and the target population may random variable under consideration may
not be the same. take values on a continuous scale and is
Sample. A sample is a subset of the called a continuousrandomvariable.
population. The most crucial issue towards Event. A subset of possible values of a
the selection of a sample is its random variable is called an event.
representativeness, including size. The Suppose X denotes some random variable;
then, for example, we may define different random variable can be computed through
events such as X x or X < x and so on. the probability mass function, called the
Distributionofarandomvariable. The pmf. The pmf is defined at discrete points
range and pattern of variation of a random and gives the point massi.e., the
variable is given by its distribution. When probability that the random variable will
the distribution of a random variable is take that particular value. Likewise, for a
known, it is possible to compute the continuous random variable, we have the
chance of any event. Some distributions probability density function, called the
are found to occur commonly and are used pdf. The pdf is very much like density and
to model many random variables occurring needs to be integrated over a range to
in practice in the context of engineering. A obtain the probability that the continuous
few of the more commonly occurring random variable lies between certain
distributions are given below. values. Thus, if the pdf or pmf is known,
the chances of the random variable taking
Binomial distribution: used to model certain set of values may be computed
random variables that count the theoretically.
number of successes in n trials carried Conceptofestimation[2*, c6s2, c7s1,
out independently of each other, where c7s3]. The true values of the parameters of
each trial results in success or failure. a distribution are usually unknown and
We make an assumption that the need to be estimated from the sample
chance of obtaining a success remains observations. The estimates are functions
constant [2*, c3s6]. of the sample values and are called
Poisson distribution: used to model statistics. For example, the sample mean is
the count of occurrence of some event a statistic and may be used to estimate the
over time or space [2*, c3s9]. population mean. Similarly, the rate of
Normal distribution: used to model occurrence of defects estimated from the
continuous random variables or sample (rate of defects per line of code) is
discrete random variables by taking a a statistic and serves as the estimate of the
very large number of values [2*, population rate of rate of defects per line
c4s6]. of code. The statistic used to estimate
some population parameter is often
Conceptofparameters. A statistical referred to as the estimator of the
distribution is characterized by some parameter.
parameters. For example, the proportion of A very important point to note is that the
success in any given trial is the only results of the estimators themselves are
parameter characterizing a binomial random. If we take a different sample, we
distribution. Similarly, the Poisson are likely to get a different estimate of the
distribution is characterized by a rate of population parameter. In the theory of
occurrence. A normal distribution is estimation, we need to understand
characterized by two parameters: namely, different properties of estimators
its mean and standard deviation. particularly, how much the estimates can
Once the values of the parameters are vary across samples and how to choose
known, the distribution of the random between different alternative ways to
variable is completely known and the obtain the estimates. For example, if we
chance (probability) of any event can be wish to estimate the mean of a population,
computed. The probabilities for a discrete we might use as our estimator a sample
mean, a sample median, a sample mode, or we decideon the basis of sample

the midrange of the sample. Each of these observationswhether a proposed
estimators has different statistical hypothesis should be accepted or rejected.
properties that may impact the standard For testing hypotheses, the null and
error of the estimate. alternative hypotheses are formed. The
Typesofestimates [2*, c7s3, null hypothesis is the hypothesis of no
c8s1].There are two types of estimates: change and is denoted as H0. The
namely, point estimates and interval alternative hypothesis is written as H 1. It is
estimates. When we use the value of a important to note that the alternative
statistic to estimate a population hypothesis may be one-sided or two-sided.
parameter, we get a point estimate. As the For example, if we have the null
name indicates, a point estimate gives a hypothesis that the population mean is not
point value of the parameter being less than some given value, the alternative
estimated. hypothesis would be that it is less than that
Although point estimates are often used, value and we would have a one-sided test.
they leave room for many questions. For However, if we have the null hypothesis
instance, we are not told anything about that the population mean is equal to some
the possible size of error or statistical given value, the alternative hypothesis
properties of the point estimate. Thus, we would be that it is not equal and we would
might need to supplement a point estimate have a two-sided test (because the true
with the sample size as well as the value could be either less than or greater
variance of the estimate. Alternately, we than the given value).
might use an interval estimate. An interval In order to test some hypothesis, we first
estimate is a random interval with the compute some statistic. Along with the
lower and upper limits of the interval computation of the statistic, a region is
being functions of the sample observations defined such that in case the computed
as well as the sample size. The limits are value of the statistic falls in that region,
computed on the basis of some the null hypothesis is rejected. This region
assumptions regarding the sampling is called the critical region (also known as
distribution of the point estimate on which the confidence interval). In tests of
the limits are based. hypotheses, we need to accept or reject the
Properties of estimators. Various null hypothesis on the basis of the
statistical properties of estimators are used evidence obtained. We note that, in
to decide about the appropriateness of an general, the alternative hypothesis is the
estimator in a given situation. The most hypothesis of interest. If the computed
important properties are that an estimator value of the statistic does not fall inside
is unbiased, efficient, and consistent with the critical region, then we cannot reject
respect to the population. the null hypothesis. This indicates that
Testsofhypotheses[2*, c9s1].A there is not enough evidence to believe
hypothesis is a statement about the that the alternative hypothesis is true.
possible values of a parameter. For As the decision is being taken on the
example, suppose it is claimed that a new basis of sample observations, errors are
method of software development reduces possible; the types of such errors are
the occurrence of defects. In this case, the summarized in the following table.
hypothesis is that the rate of occurrence of Nature Statistical Decision
defects has reduced. In tests of hypotheses,
Accept H0 Reject H0 between 1 to +1. The values 1 and +1

indicate a situation when the association
H0 is Type I error between the variables is perfecti.e.,
OK
true (probability = a) given the value of one variable, the other
H0 is Type II error can be estimated with no error. A positive
OK
false (probability = b) correlation coefficient indicates a positive
In test of hypotheses, we aim at relationshipthat is, if one variable
maximizing the power of the test (the increases, so does the other. On the other
value of 1b) while ensuring that the hand, when the variables are negatively
probability of a type I error (the value of a) correlated, an increase of one leads to a
is maintained within a particular value decrease of the other.
typically 5 percent. It is important to remember that
It is to be noted that construction of a correlation does not imply causation.
test of hypothesis includes identifying Thus, if two variables are correlated, we
statistic(s) to estimate the parameter(s) and cannot conclude that one causes the other.
defining a critical region such that if the Regression. The correlation analysis
computed value of the statistic falls in the only measures the degree of relationship
critical region, the null hypothesis is between two variables. The analysis to
rejected. find the relationship between two variables
is called regressionanalysis. The strength
2.2. ConceptsofCorrelationand of the relationship between two variables
Regression is measured using the coefficient of
[2*, c11s2, c11s8] determination. This is a value between 0
and 1. The closer the coefficient is to 1,
A major objective of many statistical
the stronger the relationship between the
investigations is to establish relationships
variables. A value of 1 indicates a perfect
that make it possible to predict one or
relationship.
more variables in terms of others.
Although it is desirable to predict a 3. Measurement
quantity exactly in terms of another [4*, c3s1, c3s2] [5*, c4s4] [6*, c7s5]
quantity, it is seldom possible and, in [7*, p442447]
many cases, we have to be satisfied with
estimating the average or expected values. Knowing what to measure and which
The relationship between two variables measurement method to use is critical in
is studied using the methods of correlation engineering endeavors. It is important that
and regression. Both these concepts are everyone involved in an engineering
explained briefly in the following project understand the measurement
paragraphs. methods and the measurement results that
Correlation. The strength of linear will be used.
relationship between two variables is Measurements can be physical,
measured using the correlation coefficient. environmental, economic, operational, or
While computing the correlation some other sort of measurement that is
coefficient between two variables, we meaningful for the particular project. This
assume that these variables measure two section explores the theory of
different attributes of the same entity. The measurement and how it is fundamental to
correlation coefficient takes a value engineering. Measurement starts as a
conceptualization then moves from define a circle as alineformingaclosed

abstract concepts to definitions of the loopsuchthatthedistancebetweenany
measurement method to the actual pointonthislineandafixedinterior
application of that method to obtain a pointcalledthecenterisconstant. We
measurement result. Each of these steps may further say that the fixed distance
must be understood, communicated, and from the center to any point on the closed
properly employed in order to generate loop gives the radius of the circle. It may
usable data. In traditional engineering, be noted that though the concept has been
direct measures are often used. In software defined, no means of measuring the radius
engineering, a combination of both direct has been proposed. The operational
and derived measures is necessary [6*, definition specifies the exact steps or
p273]. method used to carry out a specific
The theory of measurement states that measurement. This can also be called the
measurement is an attempt to describe an measurementmethod; sometimes a
underlying real empirical system. measurementprocedure may be required
Measurement methods define activities to be even more precise.
that allocate a value or a symbol to an The importance of operational
attribute of an entity. definitions can hardly be overstated. Take
Attributes must then be defined in terms the case of the apparently simple
of the operations used to identify and measurement of height of individuals.
measure them that is, the measurement Unless we specify various factors like the
methods. In this approach, a measurement time when the height will be measured (it
method is defined to be a precisely is known that the height of individuals
specified operation that yields a number vary across various time points of the
(called the measurementresult) when day), how the variability due to hair would
measuring an attribute. It follows that, to be taken care of, whether the measurement
be useful, the measurement method has to will be with or without shoes, what kind of
be well defined. Arbitrariness in the accuracy is expected (correct up to an
method will reflect itself in ambiguity in inch, 1/2 inch, centimeter, etc.)even this
the measurement results. simple measurement will lead to
In some casesparticularly in the substantial variation. Engineers must
physical worldthe attributes that we appreciate the need to define measures
wish to measure are easy to grasp; from an operational perspective.
however, in an artificial world like
software engineering, defining the 3.1. Levels(Scales)ofMeasurement
attributes may not be that simple. For [4*, c3s2] [6*, c7s5]
example, the attributes of height, weight,
distance, etc. are easily and uniformly Once the operational definitions are
understood (though they may not be very determined, the actual measurements need
easy to measure in all circumstances), to be undertaken. It is to be noted that
whereas attributes such as software size or measurement may be carried out in four
complexity require clear definitions. different scales: namely, nominal, ordinal,
interval, and ratio. Brief descriptions of
Operationaldefinitions. The definition
each are given below.
of attributes, to start with, is often rather
abstract. Such definitions do not facilitate Nominalscale: This is the lowest level
measurements. For example, we may of measurement and represents the most
unrestricted assignment of numerals. The
numerals serve only as labels, and words Measurement in ordinal scale satisfies
or letters would serve as well. The the transitivity property in the sense that if
nominal scale of measurement involves A > B and B > C, then A > C. However,
only classification and the observed arithmetic operations cannot be carried out
sampling units are put into any one of the on variables measured in ordinal scales.
mutually exclusive and collectively Thus, if we measure customer satisfaction
exhaustive categories (classes). Some on a 5-point ordinal scale of 5 implying a
examples of nominal scales are: very high level of satisfaction and 1
implying a very high level of
Job titles in a company dissatisfaction, we cannot say that a score
The software development life cycle of four is twice as good as a score of two.
(SDLC) model (like waterfall, So, it is better to use terminology such as
iterative, agile, etc.) followed by excellent, above average, average, below
different software projects average, and poor than ordinal numbers in
order to avoid the error of treating an
In nominal scale, the names of the ordinal scale as a ratio scale. It is
different categories are just labels and no important to note that ordinal scale
relationship between them is assumed. The measures are commonly misused and such
only operations that can be carried out on misuse can lead to erroneous conclusions
nominal scale is that of counting the [6*, p274]. A common misuse of ordinal
number of occurrences in the different scale measures is to present a mean and
classes and determining if two occurrences standard deviation for the data set, both of
have the same nominal value. However, which are meaningless. However, we can
statistical analyses may be carried out to find the median, as computation of the
understand how entities belonging to median involves counting only.
different classes perform with respect to Interval scales: With the interval scale,
some other response variable. we come to a form that is quantitative in
Ordinalscale:Refers to the the ordinary sense of the word. Almost all
measurement scale where the different the usual statistical measures are
values obtained through the process of applicable here, unless they require
measurement have an implicit ordering. knowledge of a true zero point. The zero
The intervals between values are not point on an interval scale is a matter of
specified and there is no objectively convention. Ratios do not make sense, but
defined zero element. Typical examples of the difference between levels of attributes
measurements in ordinal scales are: can be computed and is meaningful. Some
examples of interval scale of measurement
Skill levels (low, medium, high) follow:
Capability Maturity Model Integration
(CMMI) maturity levels of software Measurement of temperature in
development organizations different scales, such as Celsius and
Level of adherence to process as Fahrenheit. Suppose T1 and T2 are
measured in a 5-point scale of temperatures measured in some scale.
excellent, above average, average, We note that the fact that T1 is twice T2
below average, and poor, indicating does not mean that one object is twice
the range from total adherence to no as hot as another. We also note that the
adherence at all zero points are arbitrary.
Calendar dates. While the difference 3.2. DirectandDerived

between dates to measure the time Measures
elapsed is a meaningful concept, the [6*, c7s5]
ratio does not make sense.
Many psychological measurements Measures may be either direct or derived
aspire to create interval scales. (sometimes called indirect measures). An
Intelligence is often measured in example of a direct measure would be a
interval scale, as it is not necessary to count of how many times an event
define what zero intelligence would occurred, such as the number of defects
mean. found in a software product. A derived
measure is one that combines direct
If a variable is measured in interval measures in some way that is consistent
scale, most of the usual statistical analyses with the measurement method. An
like mean, standard deviation, correlation, example of a derived measure would be
and regression may be carried out on the calculating the productivity of a team as
measured values. the number of lines of code developed per
Ratioscale: These are quite commonly developermonth. In both cases, the
encountered in physical science. These measurement method determines how to
scales of measures are characterized by the make the measurement.
fact that operations exist for determining 3.3. ReliabilityandValidity
all 4 relations: equality, rank order, [4*, c3s4, c3s5]
equality of intervals, and equality of ratios.
Once such a scale is available, its A basic question to be asked for any
numerical values can be transformed from measurement method is whether the
one unit to another by just multiplying by proposed measurement method is truly
a constant, e.g., conversion of inches to measuring the concept with good quality.
feet or centimeters. When measurements Reliability and validity are the two most
are being made in ratio scale, existence of important criteria to address this question.
a nonarbitrary zero is mandatory. All The reliability of a measurement method
statistical measures are applicable to ratio is the extent to which the application of
scale; logarithm usage is valid only when the measurement method yields consistent
these scales are used, as in the case of measurement results. Essentially,
decibels. Some examples of ratio measures reliability refers to the consistency of the
are values obtained when the same item is
measured a number of times. When the
the number of statements in a software results agree with each other, the
program measurement method is said to be reliable.
temperature measured in the Kelvin Reliability usually depends on the
(K) scale or in Fahrenheit (F). operational definition. It can be quantified
by using the index of variation, which is
An additional measurement scale, the computed as the ratio between the
absolute scale, is a ratio scale with standard deviation and the mean. The
uniqueness of the measure; i.e., a measure smaller the index, the more reliable the
for which no transformation is possible measurement results.
(for example, the number of programmers Validity refers to whether the
working on a project). measurement method really measures
what we intend to measure. Validity of a Many disciplines engage in problem

measurement method may be looked at solving activities where there is a single
from three different perspectives: namely, correct solution. In engineering, most
construct validity, criteria validity, and problems have many solutions and the
content validity. focus is on finding a feasible solution
(among the many alternatives) that best
3.4. AssessingReliability meets the needs presented. The set of
[4*, c3s5] possible solutions is often constrained by
explicitly imposed limitations such as cost,
There are several methods for assessing available resources, and the state of
reliability; these include the test-retest discipline or domain knowledge. In
method, the alternative form method, the engineering problems, sometimes there are
split-halves method, and the internal also implicit constraints (such as the
consistency method. The easiest of these is physical properties of materials or laws of
the test-retest method. In the testretest physics) that also restrict the set of feasible
method, we simply apply the measurement solutions for a given problem.
method to the same subjects twice. The
correlation coefficient between the first 4.1. EngineeringDesigninEngineering
and second set of measurement results Education
gives the reliability of the measurement
method. The importance of engineering design in
engineering education can be clearly seen
4. Engineering Design by the high expectations held by various
[5*, c1s2, c1s3, c1s4] accreditation bodies for engineering
education. Both the Canadian Engineering
A products life cycle costs are largely Accreditation Board and the Accreditation
influenced by the design of the product. Board for Engineering and Technology
This is true for manufactured products as (ABET) note the importance of including
well as for software products. engineering design in education programs.
The design of a software product is guided The Canadian Engineering
by the features to be included and the Accreditation Board includes requirements
quality attributes to be provided. It is for the amount of engineering design
important to note that software engineers experience/coursework that is necessary
use the term design within their own for engineering students as well as
context; while there are some qualifications for the faculty members who
commonalities, there are also many teach such coursework or supervise design
differences between engineering design as projects. Their accreditation criteria states:
discussed in this section and software Design: An ability to design
engineering design as discussed in the solutions for complex, open-ended
Software Design KA. The scope of engineering problems and to design
engineering design is generally viewed as systems, components or processes
much broader than that of software design. that meet specified needs with
The primary aim of this section is to appropriate attention to health and
identify the concepts needed to develop a safety risks, applicable standards,
clear understanding regarding the process and economic, environmental,
of engineering design.
cultural and societal considerations. create a solution that works. This has been
[8, p12] an important insight for software designers
for several decades [10*, c5s1].
In a similar manner, ABET defines 4.3. StepsInvolvedinEngineeringDesign
engineering design as [7*, c4]
the process of devising a system, Engineering problem solving begins when

component, or process to meet a need is recognized and no existing
desired needs. It is a decision- solution will meet that need. As part of
making process (often iterative), in this problem solving, the design goals to
which the basic sciences, be achieved by the solution should be
mathematics, and the engineering identified. Additionally, a set of
sciences are applied to convert acceptance criteria must be defined and
resources optimally to meet these used to determine how well a proposed
stated needs. [9, p4] solution will satisfy the need. Once a need
for a solution to a problem has been
Thus, it is clear that engineering design identified, the process of engineering
is a vital component in the training and design has the following generic steps:
education for all engineers. The remainder
of this section will focus on various a) define the problem
aspects of engineering design. b) gather pertinent information
c) generate multiple solutions
4.2. DesignasaProblemSolvingActivity d) analyze and select a solution
[5*, c1s4, c2s1, c3s3] e) implement the solution
It is to be noted that engineering design is All of the engineering design steps are
primarily a problem solving activity. iterative, and knowledge gained at any
Design problems are open ended and more step in the process may be used to inform
vaguely defined. There are usually several earlier tasks and trigger an iteration in the
alternative ways to solve the same process. These steps are expanded in the
problem. Design is generally considered to subsequent sections.
be a wickedproblema term first coined
by Horst Rittel in the 1960s when designa. Definetheproblem. At this stage, the
methods were a subject of intense interest. customers requirements are gathered.
Rittel sought an alternative to the linear, Specific information about product
step-by-step model of the design process functions and features are also closely
being explored by many designers and examined. This step includes refining the
design theorists and argued that most of problem statement to identify the real
the problems addressed by the designers problem to be solved and setting the
are wicked problems. As explained by design goals and criteria for success.
Steve McConnell, a wicked problem is The problem definition is a crucial stage
one that could be clearly defined only by in engineering design. A point to note is
solving it or by solving part of it. This that this step is deceptively simple. Thus,
paradox implies, essentially, that a wicked enough care must be taken to carry out this
problem has to be solved once in order to step judiciously. It is important to identify
define it clearly and then solved again to needs and link the success criteria with the
required product characteristics. It is also friendliness of the proposed solution.

an engineering task to limit the scope of a Other aspects of the solutionsuch as
problem and its solution through product safety and liability, an economic
negotiation among the stakeholders. or market analysis to ensure a return
(profit) on the solution, performance
b. Gather pertinent information. At this predictions and analysis to meet quality
stage, the designer attempts to expand characteristics, opportunities for incorrect
his/her knowledge about the problem. This data input or hardware malfunctions, and
is a vital, yet often neglected, stage. so onmay be studied. The types and
Gathering pertinent information can reveal amount of analysis used on a proposed
facts leading to a redefinition of the solution are dependent on the type of
problemin particular, mistakes and false problem and the needs that the solution
starts may be identified. This step may must address as well as the constraints
also involve the decomposition of the imposed on the design.
problem into smaller, more easily solved
subproblems. e. Implementthesolution. The final phase of
While gathering pertinent information, the design process is implementation.
care must be taken to identify how a Implementation refers to development and
product may be used as well as misused. It testing of the proposed solution.
is also important to understand the Sometimes a preliminary, partial solution
perceived value of the product/ service called a prototype may be developed
being offered. Included in the pertinent initially to test the proposed design
information is a list of constraints that solution under certain conditions.
must be satisfied by the solution or that Feedback resulting from testing a
may limit the set of feasible solutions. prototype may be used either to refine the
design or drive the selection of an
c. Generatemultiplesolutions. During this alternative design solution. One of the
stage, different solutions to the same most important activities in design is
problem are developed. It has already been documentation of the design solution as
stated that design problems have multiple well as of the tradeoffs for the choices
solutions. The goal of this step is to made in the design of the solution. This
conceptualize multiple possible solutions work should be carried out in a manner
and refine them to a sufficient level of such that the solution to the design
detail that a comparison can be done problem can be communicated clearly to
among them. others.
The testing and verification take us back
d. Analyzeandselectasolution. Once to the success criteria. The engineer needs
alternative solutions have been identified, to devise tests such that the ability of the
they need to be analyzed to identify the design to meet the success criteria is
solution that best suits the current demonstrated. While designing the tests,
situation. The analysis includes a the engineer must think through different
functional analysis to assess whether the possible failure modes and then design
proposed design would meet the tests based on those failure modes. The
functional requirements. Physical engineer may choose to carry out designed
solutions that involve human users often experiments to assess the validity of the
include analysis of the ergonomics or user design.
5.Modeling, Simulation, and Prototyping structures such as bridges or highways. An

[5*, c6] [11*, c13s3] [12*, c2s3.1] iconic model actually resembles the
artifact modeled.
Modeling is part of the abstraction process In contrast, an analogic model is a
used to represent some aspects of a functionally equivalent but incomplete
system. Simulation uses a model of the representation. That is, the model behaves
system and provides a means of like the physical artifact even though it
conducting designed experiments with that may not physically resemble it. Examples
model to better understand the system, its of analogic models include a miniature
behavior, and relationships between airplane for wind tunnel testing or a
subsystems, as well as to analyze aspects computer simulation of a manufacturing
of the design. Modeling and simulation are process.
techniques that can be used to construct Finally, a symbolic model is a higher
theories or hypotheses about the behavior level of abstraction, where the model is
of the system; engineers then use those represented using symbols such as
theories to make predictions about the equations. The model captures the relevant
system. Prototyping is another abstraction aspects of the process or system in
process where a partial representation (that symbolic form. The symbols can then be
captures aspects of interest) of the product used to increase the engineers
or system is built. A prototype may be an understanding of the final system. An
initial version of the system but lacks the example is an equation such as F=Ma.
full functionality of the final version. Such mathematical models can be used to
describe and predict properties or behavior
5.1. Modeling of the final system or product.
A model is always an abstraction of some 5.2. Simulation

real or imagined artifact. Engineers use
models in many ways as part of their All simulation models are a specification
problem solving activities. Some models of reality. A central issue in simulation is
are physical, such as a made-to-scale to abstract and specify an appropriate
miniature construction of a bridge or simplification of reality. Developing this
building. Other models may be abstraction is of vital importance, as
nonphysical representations, such as a misspecification of the abstraction would
CAD drawing of a cog or a mathematical invalidate the results of the simulation
model for a process. Models help exercise. Simulation can be used for a
engineers reason and understand aspects variety of testing purposes.
of a problem. They can also help engineers Simulation is classified based on the
understand what they do know and what type of system under study. Thus,
they dont know about the problem at simulation can be either continuous or
hand. discrete. In the context of software
There are three types of models: iconic, engineering, the emphasis will be
analogic, and symbolic. An iconic model primarily on discrete simulation. Discrete
is a visually equivalent but incomplete 2- simulations may model event scheduling
dimensional or 3-dimensional or process interaction. The main
representationfor example, maps, components in such a model include
globes, or built-to-scale models of entities, activities and events, resources,
the state of the system, a simulation clock, finished product. In either case, prototype
and a random number generator. Output is construction must have a clear purpose
generated by the simulation and must be and be planned, monitored, and controlled
analyzed. it is a technique to study a specific
An important problem in the problem within a limited context [6*,
development of a discrete simulation is c2s8].
that of initialization. Before a simulation In conclusion, modeling, simulation,
can be run, the initial values of all the state and prototyping are powerful techniques
variables must be provided. As the for studying the behavior of a system from
simulation designer may not know what a given perspective. All can be used to
initial values are appropriate for the state perform designed experiments to study
variables, these values might be chosen various aspects of the system. However,
somewhat arbitrarily. For instance, it these are abstractions and, as such, may
might be decided that a queue should be not model all attributes of interest.
initialized as empty and idle. Such a 6. Standards
choice of initial condition can have a [5*, c9s3.2] [13*, c1s2]
significant but unrecognized impact on the
outcome of the simulation. Moore states that a
5.3. Prototyping standard can be; (a) an object or

measure of comparison that defines
Constructing a prototype of a system is or represents the magnitude of a
another abstraction process. In this case, unit; (b) a characterization that
an initial version of the system is establishes allowable tolerances for
constructed, often while the system is categories of items; and (c) a degree
being designed. This helps the designers or level of required excellence or
determine the feasibility of their design. attainment. Standards are
There are many uses for a prototype, definitional in nature, established
including the elicitation of requirements, either to further understanding and
the design and refinement of a user interaction or to acknowledge
interface to the system, validation of observed (or desired) norms of
functional requirements, and so on. The exhibited characteristics or
objectives and purposes for building the behavior. [13*, p8]
prototype will determine its construction
and the level of abstraction used. Standards provide requirements,
The role of prototyping is somewhat specifications, guidelines, or
different between physical systems and characteristics that must be observed by
software. With physical systems, the engineers so that the products, processes,
prototype may actually be the first fully and materials have acceptable levels of
functional version of a system or it may be quality. The qualities that various
a model of the system. In software standards provide may be those of safety,
engineering, prototypes are also an reliability, or other product characteristics.
abstract model of part of the software but Standards are considered critical to
are usually not constructed with all of the engineers and engineers are expected to be
architectural, performance, and other familiar with and to use the appropriate
quality characteristics expected in the standards in their discipline.
Compliance or conformance to a so that once a standard has been set, there

standard lets an organization say to the is a good chance that it will be widely
public that they (or their products) meet accepted. Most standards organizations
the requirements stated in that standard. have well-defined processes for their
Thus, standards divide organizations or efforts and adhere to those processes
their products into those that conform to carefully. Engineers must be aware of the
the standard and those that do not. For a existing standards but must also update
standard to be useful, conformance with their understanding of the standards as
the standard must add valuereal or those standards change over time.
perceivedto the product, process, or In many engineering endeavors,
effort. knowing and understanding the applicable
Apart from the organizational goals, standards is critical and the law may even
standards are used for a number of other require use of particular standards. In these
purposes such as protecting the buyer, cases, the standards often represent
protecting the business, and better defining minimal requirements that must be met by
the methods and procedures to be followed the endeavor and thus are an element in
by the practice. Standards also provide the constraints imposed on any design
users with a common terminology and effort. The engineer must review all
expectations. current standards related to a given
There are many internationally endeavor and determine which must be
recognized standards-making met. Their designs must then incorporate
organizations including the International any and all constraints imposed by the
Telecommunications Union (ITU), the applicable standard. Standards important
International Electrotechnical Commission to software engineers are discussed in
(IEC), IEEE, and the International more detail in an appendix specifically on
Organization for Standardization (ISO). In this subject.
addition, there are regional and
governmentally recognized organizations 7.Root Cause Analysis
that generate standards for that region or [4*, c5, c3s7, c9s8] [5*, c9s3, c9s4, c9s5]
country. For example, in the United States, [13*, c13s3.4.5]
there are over 300 organizations that
develop standards. These include Root cause analysis (RCA) is a process
organizations such as the American designed to investigate and identify why
National Standards Institute (ANSI), the and how an undesirable event has
American Society for Testing and happened. Root causes are underlying
Materials (ASTM), the Society of causes. The investigator should attempt to
Automotive Engineers (SAE), and identify specific underlying causes of the
Underwriters Laboratories, Inc. (UL), as event that has occurred. The primary
well as the US government. For more objective of RCA is to prevent recurrence
detail on standards used in software of the undesirable event. Thus, the more
engineering, see Appendix B on standards. specific the investigator can be about why
There is a set of commonly used an event occurred, the easier it will be to
principles behind standards. Standards prevent recurrence. A common way to
makers attempt to have consensus around identify specific underlying cause(s) is to
their decisions. There is usually an ask a series of whyquestions.
openness within the community of interest
7.1.TechniquesforConductingRoot process with tasks that must be completed.

CauseAnalysis As each task is completed, it is checked
[4*, c5] [5*, c3] off the list. If a problem occurs, then
sometimes the checklist can quickly
There are many approaches used for both identify tasks that may have been skipped
quality control and root cause analysis. or only partially completed.
The first step in any root cause analysis Finally, relations diagrams are a means
effort is to identify the real problem. for displaying complex relationships. They
Techniques such as statement-restatement, give visual support to cause-and-effect
why-why diagrams, the revision method, thinking. The diagram relates the specific
present state and desired state diagrams, to the general, revealing key causes and
and the fresh-eye approach are used to key effects.
identify and refine the real problem that Root cause analysis aims at preventing
needs to be addressed. the recurrence of undesirable events.
Once the real problem has been Reduction of variation due to common
identified, then work can begin to causes requires utilization of a number of
determine the cause of the problem. techniques. An important point to note is
Ishikawa is known for the seven tools for that these techniques should be used
quality control that he promoted. Some of offline and not necessarily in direct
those tools are helpful in identifying the response to the occurrence of some
causes for a given problem. Those tools undesirable event. Some of the techniques
are check sheets or checklists, Pareto that may be used to reduce variation due to
diagrams, histograms, run charts, scatter common causes are given below.
diagrams, control charts, and fishbone or
cause-and-effect diagrams. More recently, 1. Cause-and-effect diagrams may be
other approaches for quality improvement used to identify the sub and sub-sub
and root cause analysis have emerged. causes.
Some examples of these newer methods 2. Fault tree analysis is a technique that
are affinity diagrams, relations diagrams, may be used to understand the sources
tree diagrams, matrix charts, matrix data of failures.
analysis charts, process decision program 3. Designed experiments may be used to
charts, and arrow diagrams. A few of these understand the impact of various
techniques are briefly described below. causes on the occurrence of
A fishbone or cause-and-effect diagram undesirable events (see Empirical
is a way to visualize the various factors Methods and Experimental
that affect some characteristic. The main Techniques in this KA).
line in the diagram represents the problem 4. Various kinds of correlation analyses
and the connecting lines represent the may be used to understand the
factors that led to or influenced the relationship between various causes
problem. Those factors are broken down and their impact. These techniques
into subfactors and sub-subfactors until may be used in cases when conducting
root causes can be identified. controlled experiments is difficult but
A very simple approach that is useful in data may be gathered (see Statistical
quality control is the use of a checklist. Analysis in this KA).
Checklists are a list of key points in a
Kan 2002
[4*] Fairley Moore [1
2
Voland Tockey
2003
[5*] 2004
2009[7*]
[6*]McConnell 2004
[10*]
Sommerville
Null and Lobur 2006 [12*
[3*] Cheney and Kincai
Montgomery and Runger 2007 [11*]
[2*]
1. Empirical
Methods and
c1
Experimental
Techniques
1.1. Designed
Experiment
1.2.
Observational
Study
1.3.
Retrospective
Study
2. Statistical c9s1,
c10s3
Analysis c2s1
c3s6,
c3s9,
2.1. Concept of
c4s6,
Unit of Analysis
c6s2,
(Sampling
c7s1,
Units), Sample, c7s3,
and Population c8s1,
c9s1
2.2. Concepts of
c11s2,
Correlation and
c11s8
Regression
c3s1,
3. Measurement c4s4 c7s5
c3s2
3.1. Levels
p442
(Scales) of c3s2 c7s5
447
Measurement
3.2. Direct
and Derived
Measures
Kan 2002
[4*] Fairley Moore [1
2
Voland Tockey
2003
[5*] 2004
2009[7*]
[6*]McConnell 2004
[10*]
Sommerville
Null and Lobur 2006 [12*
[3*] Cheney and Kincai
Montgomery and Runger 2007 [11*]
[2*]
3.3. Reliability c3s4,

and Validity c3s5
3.4. Assessing
c3s5
Reliability
c1s2,
4. Engineering
c1s3,
Design
c1s4
4.1. Design in
Engineering
Education
4.2. Design as a c1s4,

Problem c2s1,
c5s1
Solving c3s3
Activity
4.3. Steps
Involved in
c4
Engineering
Design
5. Modeling,
c2
Prototyping, and c6 c13s3
s3.1
Simulation
5.1. Modeling
5.2. Simulation
5.3. Prototyping
c9
6. Standards c1s2
s3.2
c5, c9s3,
7. Root Cause c13
c3s7, c9s4,
Analysis s3.4.5
c9s8 c9s5
7.1. Techniques
for Conducting
c5 c3
Root Cause
Analysis
FURTHER READINGS
A. Abran, SoftwareMetricsandSoftware
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,WhatEngineersKnowand
HowTheyKnowIt. [15]
This book provides an interesting

introduction to engineering foundations
through a series of case studies that show
many of the foundational concepts as used
in real world engineering applications.
REFERENCES Professional Engineers, 2011; www.

[1] ISO/IEC/IEEE24765:2010Systems engineerscanada.ca/files/w_Accreditati
andSoftwareEngineering on_ Criteria_Procedures_2011.pdf.
[9] ABET Engineering Accreditation
[2*] D.C. Montgomery and G.C. Runger, Commission, Criteria for Accrediting
AppliedStatisticsandProbabilityfor Engineering Programs, 2012-2013,
Engineers, 4th ed., Wiley, 2007. ABET, 2011;
www.abet.org/uploadedFiles/
[3*] L. Null and J. Lobur, TheEssentials Accreditation/Accreditation_Process/
of Accreditation_Documents/Current/eac
ComputerOrganizationand criteria-2012-2013.pdf.
Architecture,
2nd ed., Jones and Bartlett Publishers, [10*] S. McConnell, CodeComplete, 2nd
2006. ed., Microsoft Press, 2004.
[4*] S.H. Kan, MetricsandModelsin [11*] E.W. Cheney and D.R. Kincaid,
SoftwareQualityEngineering, 2nd NumericalMathematicsand
ed., AddisonWesley, 2002. Computing, 6th ed., Brooks/Cole,
2007.
[5*] G. Voland, EngineeringbyDesign,
2nd ed., Prentice Hall, 2003. [12*] I. Sommerville, Software
Engineering, 9th ed., Addison-Wesley,
[6*] R.E. Fairley, ManagingandLeading 2011.
Computer Society Press, 2009. [13*] J.W. Moore, TheRoadMapto
SoftwareEngineering:AStandards-
[7*] S. Tockey, ReturnonSoftware: BasedGuide, Wiley-IEEE Computer
MaximizingtheReturnonYour Society Press, 2006.
SoftwareInvestment, Addison-Wesley,
2004. [14] A. Abran, SoftwareMetricsand
SoftwareMetrology, Wiley-IEEE
[8] Canadian Engineering Accreditation Computer Society Press, 2010.
Board, Engineers Canada,
Accreditation Criteria and [15] W.G. Vincenti, WhatEngineers
Procedures, Canadian Council of KnowandHowTheyKnowIt, John
Hopkins University Press, 1990.
APPENDIX A
KNOWLEDGE AREA DESCRIPTION

SPECIFICATIONS
INTRODUCTION
This document presents the specifications community at large notably through the
provided to the Knowledge Area Editors official recognition of the 2004 Version as
(KA Editors) regarding the Knowledge ISO/IEC Technical Report 19759:2005.
Area Descriptions (KA Descriptions) of The list of knowledge areas (KAs) and the
the Version 3 (V3) edition of the Guideto breakdown of topics within each KA is
theSoftwareEngineeringBodyof described and detailed in the introduction
Knowledge(SWEBOKGuide). This of this
document will also enable readers, SWEBOK Guide.
reviewers, and users to clearly understand Consequently, the SWEBOK Guide is
what specifications were used when foundational to other initiatives within the
developing this version of the SWEBOK IEEE Computer Society:
Guide.
This document begins by situating the a) The list of KAs and the breakdown of
SWEBOK Guide as a foundational topics within each KA are also
document for the IEEE Computer Society adopted by the software engineering
suite of software engineering products and certification and associated
more widely within the software professional development products
engineering community at large. The role offered by the IEEE Computer Society
of the baseline and the Change Control (see www. computer.org/certification).
Board is then described. Criteria and b) The list of KAs and the breakdown of
requirements are defined for the topics are also foundational to the
breakdowns of topics, for the rationale software engineering curricula
underlying these breakdowns and the guidelines developed or endorsed by
succinct description of topics, and for the IEEE Computer Society
reference materials. Important input (www.computer.org/portal/web/educat
documents are also identified, and their ion/ Curricula).
role within the project is explained. c) The Consolidated Reference List (see
Noncontent issues such as submission Appendix C), meaning the list of
format and style guidelines are also recommended reference materials (to
discussed. the level of section number) that
accompanies the breakdown of topics
THE SWEBOK GUIDE IS A within each KA is also adopted by the
FOUNDATIONAL DOCUMENT FOR software engineering certification and
THE associated professional development
IEEE COMPUTER SOCIETY SUITE products offered by the IEEE
OF Computer Society.
PRODUCTS BASELINE AND CHANGE CONTROL
BOARD
The SWEBOK Guide is an IEEE Computer
Society flagship and structural document A-
1
for the IEEE Computer Society suite of
Due to the structural nature of the
software engineering products. The
SWEBOK Guide and its adoption by other
SWEBOK Guide is also more widely
products, a baseline was developed at the
recognized as a foundational document
outset of the project comprised of the list
within the software engineering
of KAs, the breakdown of topics within
each KA, and the Consolidated Reference f) The breakdown of topics within a KA
List. must be compatible with the
A Change Control Board (CCB) has breakdown of software engineering
been in place for the development of this generally found in industry and in the
version to handle all change requests to software engineering literature and
this baseline coming from the KA Editors, standards.
arising during the review process, or g) The breakdown of topics is expected
otherwise. Change requests must be to be as inclusive as possible.
approved both by the SWEBOK Guide h) The SWEBOK Guide adopts the
Editors and by the CCB before being position that even though the
implemented. This CCB is comprised of following themes are common
members of the initiatives listed above and across all Knowledge Areas, they are
acting under the authority of the Software also an integral part of all Knowledge
and Systems Engineering Committee of Areas and therefore must be
the IEEE Computer Society Professional incorporated into the proposed
Activities Board. breakdown of topics of each
Knowledge Area. These common
CRITERIA AND REQUIREMENTS themes are measurement, quality (in
FOR general), and security.
THE BREAKDOWN OF TOPICS i) The breakdown of topics should be at
WITHIN A KNOWLEDGE AREA most two or three levels deep. Even
though no upper or lower limit is
a) KA Editors are instructed to adopt the imposed on the number of topics
baseline breakdown of topics. within each KA, a reasonable and
b) The breakdown of topics is expected manageable number of topics is
to be expected to be included in each KA.
reasonable, not perfect. Emphasis should also be put on the
c) The breakdown of topics within a KA selection of the topics themselves
must decompose the subset of the rather than on their organization in an
Software Engineering Body of appropriate hierarchy.
Knowledge that is generally j) Topic names must be significant
recognized. See below for a more enough to be meaningful even when
detailed discussion of this point. cited outside the SWEBOK Guide.
d) The breakdown of topics within a KA k) The description of a KA will include a
must not presume specific application chart (in tree form) describing the
domains, business needs, sizes of knowledge breakdown.
organizations, organizational
structures, management philosophies, CRITERIA AND REQUIREMENTS
software life cycle models, software FOR
technologies, or software development DESCRIBING TOPICS
methods.
e) The breakdown of topics must, as Topics need only be sufficiently described
much as possible, be compatible with so the reader can select the appropriate
the various schools of thought within reference material according to his/her
software engineering. needs. Topic descriptions must not be
prescriptive.
CRITERIA AND REQUIREMENTS Collectively the list of

FOR REFERENCE MATERIAL Recommended References should
be
a)KA Editors are instructed to use the
references (to the level of section i. complete: covering the entire
number) allocated to their KA by the scope of the SWEBOK Guide
Consolidated Reference List as their ii. sufficient: providing
Recommended References. enough
b) There are three categories of reference information to describe
material: generally accepted
knowledge
Recommended References. The iii. consistent: not providing
set of Recommended References contradictory knowledge nor
(to the level of section number) is conflicting practices
collectively known as the iv. credible: recognized as
Consolidated Reference List. providing expert treatment
Further Readings. v. current: treating the subject
in a manner that is
Additional references cited in the
commensurate with currently
KA Description (for example, the
generally accepted
source of a quotation or reference
knowledge
material in support of a rationale
vi. succinct: as short as possible
behind a particular argument).
(both in number of reference
c)The SWEBOK Guide is intended by
items and in total page count)
definition to be selective in its choice of
without failing other
topics and associated reference material.
objectives.
The list of reference material should be
clearly viewed as an informed and
Recommended reference material
reasonable selection rather than as a
must be identified for each topic.
definitive list.
Each recommended reference item
d) Reference material can be book
may of course cover multiple topics.
chapters, refereed journal papers,
Exceptionally, a topic may be self-
refereed conference papers, refereed
descriptive and not cite a reference
technical or industrial reports, or any
material item (for example, a topic
other type of recognized artifact.
that is a definition or a topic for
References to another KA, subarea, or
which the description itself without
topic are also permitted.
any cited reference material is
e)Reference material must be generally
sufficient for the objectives of the
available and must not be confidential in
SWEBOK Guide).
nature.
f) Reference material must be in English. Each reference to the recommended
g) Criteria and requirements for reference material should be as
recommended reference material or precise as possible by identifying
Consolidated Reference List: what specific chapter or section is
relevant.
A matrix of reference material (to h) Additional reference material can be

the level of section number) versus included by the KA Editor in a Further
topics must be provided. Readings list:
A reasonable amount of These further readings must be
recommended reference material related to the topics in the
must be identified for each KA. The breakdown rather than, for
following guidelines should be used example, to more advanced
in determining how much is topics.
reasonable: The list must be annotated (within
1 paragraph per reference) as to
i. If the recommended why this reference material was
reference material were included in the list of further
written in a coherent manner readings. Further readings could
that followed the proposed include: new versions of an
breakdown of topics and in a existing reference already
uniform style (for example, included in the recommended
in a new book based on the references, alternative viewpoints
proposed KA description), on a KA, or a seminal treatment
an average target across all of a KA.
KAs for the number of pages A general guideline to be
would be 750. However, this followed is 10 or fewer further
target may not be attainable readings per KA.
when selecting existing There is no matrix of the
reference material due to reference materials listed in
differences in style and further readings and the
overlap and redundancy breakdown of topics.
between the selected
reference materials. i) Criteria and requirements regarding
ii. In other words, the target for additional references cited in the KA
the number of pages for the Description:
entire collection of
recommended references of The SWEBOK Guide is not a
the SWEBOK Guide is in the research document and its
range of 10,000 to 15,000 readership will be varied.
pages. Therefore, a delicate balance
iii. Another way of viewing this must be maintained between
is that the amount of ensuring a high level of
recommended reference readability within the document
material would be while maintaining its technical
reasonable if it consisted of excellence. Additional reference
the study material on this material should therefore only be
KA for a software brought in by the KA Editor if it
engineering licensing exam is necessary to the discussion.
that a graduate would pass Examples are to identify the
after completing four years source of a quotation or to cite
of work experience. reference item in support of a
rationale behind a particular and is consensus about their value and

important argument. usefulness. Good practice means
there is general agreement that the
COMMON STRUCTURE application of these skills, tools, and
techniques can enhance the chances
KA descriptions should use the following of success over a wide range of
structure: projects. Good practice does not
mean that the knowledge described
Acronyms should always be applied uniformly
Introduction to all projects; the organization
Breakdown of Topics of the KA and/or project management team is
(including a figure describing the responsible for determining what is
breakdown) appropriate for any given project.
[1]
Matrix of Topics vs. Reference
Material
Generally accepted knowledge could
List of Further Readings
also be viewed as knowledge to be
References
included in the study material of a
WHAT DO WE MEAN BY
software engineering licensing exam (in
GENERALLY RECOGNIZED
the USA) that a graduate would take after
KNOWLEDGE?
completing four years of work experience.
These two definitions should be seen as
The Software Engineering Body of
complementary.
Knowledge is an all-inclusive term that
KA Editors are also expected to be
describes the sum of knowledge within the
somewhat forward looking in their
profession of software engineering.
interpretation by taking into consideration
However, the SWEBOK Guide seeks to
not only what is generally recognized
identify and describe that subset of the
today and but what they expect will be
body of knowledge that is generally
generally recognized in a 3- to 5-year
recognized or, in other words, the core
timeframe.
body of knowledge. To better illustrate
what generally recognized knowledge is Generally Recognized
relative to other types of knowledge, Established traditional
Figure A.1 proposes a three-category practices recommended by
schema for classifying knowledge. many
The Project Management Institute in its organizations
Guide totheProjectManagementBodyof Advanced and Research
Knowledge defines generally recognized Innovative practices tested
knowledge for project management as and used only by some
being: organizations and concepts
still
that subset of the project being developed and tested in
management body of knowledge research organizations
generally recognized as good
practice. Generally recognized
means the knowledge and practices
described are applicable to most
projects most of the time, and there
curricula of a professional masters level

program in software engineering. The
SWEBOK Guide is identified as a
Certain Types ofprimary
Software 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.
Practices Used Only for
2.IEEEStd.12207-2008(a.k.a.ISO/IEC
12207:2008)StandardforSystems
andSoftwareEngineeringSoftware
LifeCycleProcesses, IEEE, 2008 [3].
This standard is considered the key

Specialized 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
Figure A.1. Categories of Knowledge
Committees. It also has been designated as
a pivotal standard by the Software and
System Engineering Standards Committee
LENGTH OF KA DESCRIPTION (S2ESC) of the IEEE.
Even though we do not intend that the
KA Descriptions are to be roughly 10 to
GuidetotheSoftwareEngineeringBody
20 pages using the formatting template for
ofKnowledge be fully 12207-conformant,
papers published in conference
this standard remains a key input to the
proceedings of the IEEE Computer
SWEBOK Guide, and special care will be
Society. This includes text, references,
taken throughout the SWEBOK Guide
appendices, tables, etc. This, of course,
regarding the compatibility of the Guide
does not include the reference materials
with the 12207 standard.
themselves.
3.J.W. Moore, TheRoadMaptoSoftware
IMPORTANT RELATED
Engineering:AStandards-Based
DOCUMENTS
Guide, Wiley-IEEE Computer Society
Press, 2006.
1. GraduateSoftwareEngineering2009
[4*]
(GSwE2009):CurriculumGuidelinesfor
GraduateDegreeProgramsinSoftware
This book describes the scope, roles, uses,
Engineering, 2009;
and development trends of the most
www.gswe2009.org. [2]
widely used software engineering
standards. It concentrates on important
This document provides guidelines and
software engineering activitiesquality
recommendations for defining the
and project management, system
engineering, dependability, and safety. The in the field of software engineering can be
analysis and regrouping of the standard found on this website. The SWEBOK
collections exposes the reader to key Guide is foundational to these products.
relationships between standards.
Even though the SWEBOK Guide is not STYLE AND TECHNICAL
a software engineering standard per se, GUIDELINES
special care will be taken throughout the
document regarding the compatibility of KA Descriptions should conform to
the Guide with the current IEEE and the Word template available at
ISO/IEC Systems and Software www.computer.
Engineering Standards Collection. org/portal/web/cscps/formatting.
KA Descriptions are expected to
4.SoftwareEngineering2004:Curriculum follow the IEEE Computer Society
GuidelinesforUndergraduateDegree Style Guide (www.
ProgramsinSoftwareEngineering, computer.org/portal/web/publications/
IEEE Computer Society and styleguide).
Association for Computing Machinery, Files are to be submitted in Microsoft
2004; http://sites. Word format.
computer.org/ccse/SE2004Volume.pdf. All citations of reference material are
[5] to be produced using EndNote Web as
indicated in the instructions provided
This document describes curriculum to KA Editors in this regard.
guidelines for an undergraduate degree in
software engineering. The SWEBOK OTHER DETAILED GUIDELINES
Guide is identified as being one of the
primary sources in developing the body When referencing the Guide to the
of knowledge underlying these guidelines. SoftwareEngineering Body of
Knowledge, use the title SWEBOK
5.ISO/IEC/IEEE24765:2010Systemsand Guide.
SoftwareEngineeringVocabulary, For the purpose of simplicity, avoid
ISO/ IEC/IEEE, 2010; footnotes and try to include their content
www.computer.org/ sevocab. [6] in the main text.
The hierarchy of references for Use explicit references to standards, as
terminology is MerriamWebsters opposed to simply inserting numbers
CollegiateDictionary (11th ed.) [7], referencing items in the bibliography. We
IEEE/ISO/IEC 24765 [6], and new believe this approach allows the reader to
proposed definitions if required. be better exposed to the source and scope
of a standard.
6.Certification and Training for Software The text accompanying figures and
Professionals, IEEE Computer Society, tables should be self-explanatory or have
2013; www.computer.org/certification. enough related text. This would ensure
[8] that the reader knows what the figures and
tables mean.
Information on the certification and To make sure that some information in
associated professional development the SWEBOK Guide does not become
products developed and offered by the rapidly obsolete and due to its generic
IEEE Computer Society for professionals nature, please avoid directly naming tools
and products. Instead, try to name their [2] Integrated Software and Systems
functions. Engineering Curriculum (iSSEc)
Project,
EDITING GraduateSoftwareEngineering
2009(GSwE2009):Curriculum
Editors of the SWEBOK Guide as well as GuidelinesforGraduateDegree
professional copy editors will edit KA ProgramsinSoftwareEngineering,
Descriptions. Editing includes copy Stevens Institute of Technology,
editing (grammar, punctuation, and 2009; www.gswe2009.org.
capitalization), style editing (conformance
to the Computer Society style guide), and [3] IEEEStd.12207-2008(a.k.a.ISO/IEC
content editing (flow, meaning, clarity, 12207:2008)StandardforSystems
directness, and organization). The final andSoftwareEngineeringSoftware
editing will be a collaborative process in LifeCycleProcesses,IEEE,2008.
which the Editors of the SWEBOK Guide
and the KA Editors work together to [4*] J.W. Moore, TheRoadMapto
achieve a concise, well-worded, and useful Software
KA Description. Engineering:AStandards-Based
Guide,
RELEASE OF COPYRIGHT Wiley-IEEE Computer Society Press,
2006.
All intellectual property rights associated [5] Joint Task Force on Computing
with the SWEBOK Guide will remain with Curricula, IEEE Computer Society and
the IEEE. KA Editors must sign a Association for Computing Machinery,
copyright release form. SoftwareEngineering2004:
It is also understood that the SWEBOK CurriculumGuidelinesfor
Guide will continue to be available free of UndergraduateDegreeProgramsin
charge in the public domain in at least one SoftwareEngineering, 2004;
format, provided by the IEEE Computer http://sites.
Society through web technology or by computer.org/ccse/SE2004Volume.pdf.
other means.
[6] ISO/IEC/IEEE24765:2010Systems
For more information, see
www.computer.org/ copyright.htm.
REFERENCES
[1] Project Management Institute, A [7] Merriam-WebstersCollegiate
Guidetothe Dictionary, 11th ed., 2003.
ProjectManagementBodyof
Knowledge(PMBOK(R)Guide), 5th [8] IEEE Computer Society, Certification
ed., Project Management Institute, and Training for Software
2013. Professionals, 2013;
www.computer.org/certification.
APPENDIX B
IEEE AND ISO/IEC STANDARDS

SUPPORTING THE SOFTWARE
ENGINEERING BODY OF KNOWLEDGE
(SWEBOK)
Some might say that the supply of from databases. Like any database,
software engineering standards far these sometimes contain errors,
exceeds the demand. One seldom listens particularly for the titles. So this
to a briefing on the subject without article will often paraphrase the
suffering some apparently obligatory joke
that there are too many of them. However, B-1
the existence of standards takes a very title of the standard or simply use its
large (possibly infinite) trade space of number. In obtaining a standard of
alternatives and reduces that space to a interest, the reader should rely on the
smaller set of choicesa huge advantage number, not the title, given in this
for users. Nevertheless, it can still be article. For reasons of consistency, the
difficult to choose from dozens of article will use the IEEEs convention
alternatives, so supplementary guidance, for the capitalization of titlesnouns,
like this appendix, can be helpful. A pronouns, adjectives, verbs, adverbs,
summary list of the standards mentioned and first and last words have an initial
in this appendix appears at the end. capital letterdespite the fact that
To reduce tedium in reading, a few IEEE and ISO/IEC use differing
simplifications and abridgements are made conventions.
in this appendix: Because these standards are being
continually revised to take account of
ISO/IEC JTC 1/SC 7 maintains nearly two new technologies and usage patterns,
hundred standards on the subject. IEEE this article will be obsolescent before
maintains about fifty. The two it is published. Therefore, it will
organizations are in the tenth year of a occasionally discuss standards that
systematic program to coordinate and have not yet been published, if they
integrate their collections. In general, this are likely to assume significant
article will focus on the standards that are importance.
recognized by both organizations, taking Explicit trademarks are omitted. Suffice
this condition as evidence that wide it to say that IEEE places a trademark
agreement has been obtained. Other on all of its standards designations.
standards will be mentioned briefly.
Standards tend to have long, taxonomical There are some other conventions of
titles. If there were a single standard for interest:
building an automobile, the one for your
Camry probably would be titled In both IEEE and ISO/IEC, standards for
something like, Vehicle, internal systems engineering are maintained
combustion, fourwheel, passenger, by the same committee as those for
sedan. Also, modern standards software engineering. Many of the
organizations provide their standards standards apply to both. So, instead
of making fine distinctions, this article matter and, occasionally, added

will deal with both. informational material.
On the other hand, both S2ESC and SC 7
(see below for descriptions of these A summary list of all of the mentioned
organizations) are responsible for standards is provided at the end of this
standards that dont qualify as appendix.
engineering. In the US and many other
countries, the services of a licensed ISO/IEC JTC 1/SC 7, SOFTWARE
engineer are required when a product AND SYSTEMS ENGINEERING
might affect public safety, health, and
welfare as opposed to affecting merely ISO/IEC JTC 1/SC 7 is the major source
the pocketbook of the client. This of international standards on software
appendix will respect that distinction and and systems engineering. Its name is
ignore standards that appear to be merely formed taxonomically. Joint Technical
economic in consequence. Committee 1 (JTC 1) is a child of the
User documentation is assumed to be International Organization for
developed similarly to software. For Standardization (ISO) and the
example, a standard concerning the International Electrotechnical
design of user documentation is described Commission (IEC); it has the scope of
in the Software Design KA. information technology and
subdivides its work among a number of
Some jointly developed standards are
subcommittees; Subcommittee 7 (SC 7)
explicitly labeled as joint developments,
is the one responsible for software and
e.g., ISO/ IEC/IEEE 24765. In other
systems engineering. SC 7, and its
cases, the standards have different
working groups, meets twice a year,
designations in the two organizations.
attracting delegations representing the
Examples include
national standards bodies of
participating nations. Each nation
IEEE Std. 12207:2008 (a.k.a. follows its own procedures for
ISO/IEC 12207:2008), where determining national positions and each
a.k.a. (also known as) is this nation has the responsibility of
appendixs abbreviation to note the determining whether an ISO/IEC
designation in the other standard should be adopted as a national
organization; standard.
IEEE Std. 15939:2008 Standard SC 7 creates three types of documents:
Adoption of ISO/IEC 15939:2007,
an adoption by IEEE of a standard International Standards: Documents
developed in ISO/IEC; containing requirements that must
IEEE Std. 1220:2005 (a.k.a. be satisfied in order to claim
ISO/IEC 26702:2007), a fast- conformance.
track by ISO/IEC of a standard Technical Specifications (formerly
developed in IEEE. called Technical Reports, type 1 and
type 2): Documents published in a
In each of these cases, the standards preliminary manner while work
are substantively identical in the two continues.
organizations, differing only in front Technical Reports (formerly called
Technical Reports, type 3):
Documents inherently unsuited to be Specification. However, it has nothing

standards, usually because they are comparable to an ISO/IEC Technical
descriptive rather than prescriptive. Report; one would look elsewhere in
IEEE for documents of this ilk.
The key thing to remember is that only the
first category counts as a consensus THE STANDARDS
standard. The reader can easily recognize the
others by the suffix TS or TR prepended to The remainder of this article allocates
the number of the document. the selected standards to relevant
knowledge areas (KAs) of the SWEBOK
IEEE SOFTWARE AND SYSTEMS Guide. There is a section for each KA.
ENGINEERING STANDARDS Within each section, the relevant
COMMITTEE (S2ESC) standards are listedthe ones that
principally apply to the KA as well as
IEEE is the worlds largest organization of others that principally apply to other
technical professionals, with about 400,000 KAs but which are also related to the
members in more than 160 countries. The current one. Following each standard is
publication of standards is performed by the a brief summary. In most cases, the
IEEE Standards Association (IEEE-SA), but summary is a quotation or paraphrase of
the committees that draft and sponsor the the abstract or other introductory
standards are in the various IEEE societies; material from the text of the standard.
S2ESC is a part of the IEEE Computer Most of the standards easily fit into
Society. IEEE is a global standards maker one KA. Some fit into more than one; in
because its standards are used in many such cases, a cross-reference is provided.
different countries. Despite its international Two standards apply to all KAs, so they
membership (about 50% non-US), though, are listed in a category called General.
the IEEE-SA routinely submits its standards All of the standards related to computer-
to the American National Standards Institute aided software engineering (CASE)
(ANSI) for endorsement as American tools and environments are listed in the
National Standards. Some S2ESC standards Software Engineering Models and
are developed within S2ESC, some are Methods KA section.
developed jointly with SC 7, and some are
adopted after being developed by SC 7. GENERAL
IEEE-SA publishes three types of
standards: The first two standards are so central
that they could be slotted into all of the
Standards, with a preponderance of the KAs. Two more are described in the
verb shall Software Engineering Process KA, but
Recommended Practices, with a are mentioned here because they provide
preponderance of the verb should a helpful framework and because the
Guides, with a preponderance of the descriptions of several other standards
verb may. refer to them.
ISO/IEC TR 19759 is the SWEBOK
All three of these compare to ISO/IEC Guide itself. Its not an IEEE standard
standards. IEEE-SA does have the concept because, lacking prescriptive verbs, it
of a TrialUse standard, which is roughly doesnt satisfy the criteria for any of the
comparable to an ISO/IEC Technical IEEE categories. In ISO/IEC, it is a
technical reportdefined as a document ISO/IEC/IEEE 24765:2010 provides a

inherently unsuited to be a standard. The common vocabulary applicable to all
2004 IEEE SWEBOK Guide was adopted by systems and software engineering work.
ISO/IEC without change. Presumably, It was prepared to collect and support
ISO/IEC will adopt Version 3 of the the standardization of terminology. ISO/
SWEBOK Guide. IEC/IEEE 24765:2010 is intended to
serve as a useful reference for those in
the information technology field and to
ISO/IEC TR 19759:2005 Software Engineering encourage the use of systems and
Guide to the Software Engineering Body of software engineering standards prepared
Knowledge by ISO and liaison organizations IEEE
(SWEBOK) Computer
Applies to all KAs Society and Project Management
Institute. ISO/
ISO/IEC 19759:2005, a Guide to the IEC/IEEE 24765:2010 includes
SoftwareEngineering Body of Knowledge references to the active source standards
(SWEBOK), identifies and describes that for each definition so that the use of the
subset of the body of knowledge that is term can be further explored.
generally accepted, even though software
engineers must be knowledgeable not only
in software engineering, but also, of course,
in other related disciplines. SWEBOK is an The vocabulary is descriptive, rather
all-inclusive term that describes the sum of than prescriptive; it gathers up all of the
knowledge within the profession of software definitions from all of the relevant
engineering. standards, as well as a few other sources,
rather than choosing among competing
definitions.
The content of the 24765 standard is
The text of the SWEBOK Guide is freely freely accessible online at
available at www.swebok.org/. The ISO/IEC www.computer.org/sevocab.
adoption of the Guide is freely available at Two standards, 12207 and 15288,
http://standards. provide a complete set of processes for
iso.org/ittf/PubliclyAvailableStandards/index the entire life cycle of a system or a
. html. software product. The two standards are
ISO/IEC/IEEE 24765 provides a shared aligned for concurrent use on a single
vocabulary for the systems and software project or in a single organization. They
engineering standards of both SC 7 and are mentioned here because they are
S2ESC. often used as a framework for explaining
or localizing the role of other standards
in the life cycle.
ISO/IEC/IEEE 24765:2010 Systems and
Software
EngineeringVocabulary IEEE Std. 12207-2008 (a.k.a. ISO/IEC
Applies to all KAs 12207:2008)
Standard for Systems and Software
Engineering
Software Life Cycle Processes
See Software Engineering Process KA 12207:2008 or ISO/IEC 15288:2008, or

it can be used independently.
IEEE Std. 15288-2008 (a.k.a. ISO/IEC
15288:2008)
Engineering A multipart ISO/IEC standard
System Life Cycle Processes provides principles and methods for
See Software Engineering Process KA sizing software based on its
requirements. The functional size is
often useful in the denominator of
measurements of quality and
SOFTWARE REQUIREMENTS productivity in software development. It
may also play a role in contracting for
The primary standard for software and servicelevel agreements.
systems requirements engineering is a new
one that replaced several existing IEEE
standards. It provides a broad view of ISO/IEC 14143 [six parts] Information
requirements engineering across the entire TechnologySoftware Measurement
life cycle. Functional Size Measurement
ISO/IEC 14143 describes FSM

ISO/IEC/IEEE 29148:2011 Systems and (functional size measurement). The
Software EngineeringLife Cycle Processes concepts of functional size measurement
Requirements Engineering (FSM) are designed to overcome the
limitations of earlier methods of sizing
ISO/IEC/IEEE 29148:2011 contains software by shifting the focus away
provisions for the processes and products from measuring how the software is
related to the engineering of requirements implemented to measuring size in terms
for systems and software products and of the functions required by the user.
services throughout the life cycle.
It defines the construct of a good
requirement, provides attributes and
characteristics of requirements, and FSM is often known as function
discusses the iterative and recursive point counting. The four standards
application of requirements processes listed below are alternative methods for
throughout the life cycle. ISO/IEC/IEEE function point countingall meet the
29148:2011 provides additional guidance in requirements of ISO/IEC 14143. The
the application of requirements engineering dominant method, in terms of market
and management processes for share, is the IFPUG method, described
requirements-related activities in ISO/IEC in ISO/IEC 20926. Other methods are
12207:2008 and ISO/IEC 15288:2008. variations intended to improve the
Information items applicable to the validity of the count in various
engineering of requirements and their circumstances.
content are defined. The content of For example, ISO/IEC 19761
ISO/IEC/IEEE 29148:2011 can be added to COSMIC is notably intended to be used
the existing set of requirementsrelated life on software with a real-time component.
cycle processes defined by ISO/IEC
See Software Engineering Models and

Methods KA
ISO/IEC 19761:2011 Software Engineering
COS-
MIC: A Functional Size Measurement Method
SOFTWARE DESIGN
ISO/IEC 20926:2009 Software and Systems

The software design KA includes both
EngineeringSoftware Measurement software architectural design (for
IFPUG Functional Size Measurement Method determining the relationships among the
items of the software and detailed design
ISO/IEC 20968:2002 Software Engineering (for describing the individual items).
Mk II Function Point AnalysisCounting ISO/ IEC/IEEE 42010 concerns the
Practices Manual description of architecture for systems
and software.
ISO/IEC 24570:2005 Software Engineering
NESMA Functional Size Measurement Method
Version 2.1Definitions and Counting
Guidelines for the Application of Function
Software
Point Analysis
EngineeringArchitecture Description
ISO/IEC/IEEE 42010:2011 addresses

the creation, analysis, and sustainment
Sometimes requirements are described in
of architectures of systems through the
natural language, but sometimes they are
use of architecture descriptions. A
described in formal or semiformal notations.
conceptual model of architecture
The objective of the Unified Modeling
description is established. The required
Language (UML) is to provide system
contents of an architecture description
architects, software engineers, and software
are specified. Architecture viewpoints,
developers with tools for analysis, design,
architecture frameworks and
and implementation of software-based
architecture description languages are
systems as well as for modeling business and
introduced for codifying conventions
similar processes. The two parts of ISO/IEC
and common practices of architecture
19505 define UML, revision 2. The older
description. The required content of
ISO/ IEC 19501 is an earlier version of
architecture viewpoints, architecture
UML. They are mentioned here because they
frameworks and architecture description
are often used to model requirements.
languages is specified. Annexes provide
the motivation and background for key
concepts and terminology and examples
ISO/IEC 19501:2005 Information Technology of applying ISO/IEC/IEEE 42010:2011.
Open Distributed ProcessingUnified
Modeling
Language (UML) Version 1.4.2
See Software Engineering Models and Like ISO/IEC/IEEE 42010, the next
Methods KA standard treats software design as an
abstraction, independent of its
ISO/IEC 19505:2012 [two parts] Information
TechnologyObject Management Group
representation in a document.
Unified Modeling Language (OMG UML) Accordingly, the standard places
provisions on the description of design, system. Therefore, the various aspects of

rather than on design itself. user documentation its design, its
testing, and so forthare allocated to
different KAs. The next standard deals
IEEE Std. 1016-2009 Standard for Information with the design of user documentation.
TechnologySystems DesignSoftware
Design Descriptions
IEEE Std. 26514-2010 Standard Adoption
This standard describes software designs and of ISO/ IEC 26514:2008 Systems and
establishes the information content and Software EngineeringRequirements for
organization of a software design description Designers and Developers of User
(SDD). An SDD is a representation of a Documentation
software design to be used for recording
design information and communicating that This standard provides requirements for
design information to key design the design and development of software
stakeholders. This standard is intended for user documentation as part of the life
use in design situations in which an explicit cycle processes. It defines the
software design description is to be documentation process from the
prepared. These situations include traditional viewpoint of the documentation
software construction activities (when developer and also covers the
design leads to code) and reverse documentation product. It specifies the
engineering situations (when a design structure, content, and format for user
description is recovered from an existing documentation and also provides
implementation). This standard can be informative guidance for user
applied to commercial, scientific, or military documentation style. It is independent of
software that runs on digital computers. the software tools that may be used to
Applicability is not restricted by the size, produce documentation and applies to
complexity, or criticality of the software. both printed documentation and
This standard can be applied to the onscreen documentation. Much of this
description of high-level and detailed standard is also applicable to user
designs. This standard does not prescribe documentation for systems including
specific methodologies for design, hardware.
configuration management, or quality
assurance. This standard does not require the
use of any particular design languages, but
establishes requirements on the selection of SOFTWARE CONSTRUCTION
design languages for use in an SDD. This
standard can be applied to the preparation of The term software construction refers
SDDs captured as paper documents, to the detailed creation of working,
automated databases, software development meaningful software through a
tools, or other media. combination of coding, verification, unit
testing, integration testing, and
debugging.
There are few standards on the details
By convention, this appendix treats user of software coding. It has been found
documentation as a part of a software through (mostly bad) experience that
coding conventions are not appropriate for are cooperating in the development of a
standardization because, in most cases, the four-part joint standard, 29119, that will
real benefit comes from the consistency of provide a comprehensive treatment of
applying an arbitrary convention rather than testing and supplant IEEE Std. 1008.
the convention itself. So, although coding
conventions are a good idea, it is generally
left to the organization or the project to IEEE Std. 1008-1987 Standard for
develop such a standard. Software Unit
Nevertheless, the subject of secure coding Testing
has attracted attention in recent years See Software Testing KA
because some coding idioms are insecure in
the face of attack. A Technical Report ISO/IEC/IEEE 29119 [four parts] (Draft)
prepared by ISO/IEC JTC 1/ SC 22 Software and Systems Engineering
(programming languages) describes Software Testing
vulnerabilities in programming languages See Software Testing KA
and how they can be avoided.
The next standard provides for the

ISO/IEC TR 24772:2013 Information
development of user documentation
Technology Programming Languages
during an agile development process. It
Guidance to Avoiding Vulnerabilities in
Programming Languages through is mentioned here because agile
Language Selection and Use development is sometimes regarded as
construction.
ISO/IEC TR 24772:2013 specifies software
programming language vulnerabilities to be
avoided in the development of systems ISO/IEC/IEEE 26515:2012 Systems and
where assured behavior is required for Software EngineeringDeveloping User
security, safety, mission-critical, and Documentation in an
business-critical software. In general, this Agile Environment
guidance is applicable to the software See Software Engineering Models and
developed, reviewed, or maintained for any Methods KA
application.
Vulnerabilities are described in a generic Coding is not the only way to create a
manner that is applicable to a broad range of software product. Often code (as well as
programming languages. Annexes relate the requirements and design) is reused from
generic guidance to a selection of specific previous projects or engineered for reuse
programming languages. in future projects. IEEE Std. 1517 is
mentioned here because it provides a
The Technical Report is freely available at common framework for extending the
http:// system and software life cycle processes
standards.iso.org/ittf/PubliclyAvailableStanda of IEEE Std. 12207:2008 to include the
rds/ index.html. systematic practice of reuse.
Two standards are mentioned here because
unit testing is often regarded as an activity of
software construction. IEEE and ISO/IEC
IEEE Std. 1517-2010 Standard for Information software engineering practice. A second
TechnologySystem and Software Life Cycle objective is to describe the software
ProcessesReuse Processes engineering concepts and testing
See Software Engineering Process KA assumptions on which the standard
SOFTWARE TESTING approach is based. A third objective is to
provide guidance and resource
Oddly, there are few standards for testing. information to assist with the
IEEE Std. 829 is the most comprehensive. implementation and usage of the
standard unit testing approach.
IEEE and ISO/IEC JTC 1/SC 7 are
IEEE Std. 829-2008 Standard for Software and cooperating in a project to develop a
System Test Documentation single comprehensive standard that
covers all aspects of testing. One can
Test processes determine whether the hope for publication of the four-part
development products of a given activity standard by 2014. Portions of the content
conform to the requirements of that activity remain controversial. One taxonomical
and whether the system and/or software issue is whether static methodssuch
satisfies its intended use and user needs. as inspection, review, and static analysis
Testing process tasks are specified for should fall within the scope of
different integrity levels. These process tasks testing or should be distinguished as
determine the appropriate breadth and depth verification and validation. Although
of test documentation. The documentation the resolution of the issue is probably of
elements for each type of test documentation little importance to users of the standard,
can then be selected. The scope of testing it assumes great importance to the
encompasses software-based systems, standards-writers who must manage an
computer software, hardware, and their integrated suite of interoperating
interfaces. This standard applies to software- standards.
based systems being developed, maintained,
or reused (legacy, commercial offthe-shelf,
nondevelopmental items). The term ISO/IEC/IEEE 29119 [four parts] (Draft)
software also includes firmware, Software and Systems Engineering
microcode, and documentation. Test Software Testing
processes can include inspection, analysis,
demonstration, verification, and validation The purpose of ISO/IEC 29119 Software
of software and software-based system Testing is to define an internationally
products. agreed standard for software testing that
can be used by any organization when
performing any form of software testing.
IEEE Std. 1008 focuses on unit testing.

IEEE Std. 1008-1987 Standard for Software
Testing of user documentation is
Unit Testing
described in the next standard, providing
requirements for the test and review of
The primary objective is to specify a
software user documentation as part of
standard approach to software unit testing
the life cycle processes. It defines the
that can be used as a basis for sound
documentation process from the viewpoint SOFTWARE MAINTENANCE

of the documentation tester and reviewer. It
is relevant to roles involved in testing and This standardthe result of
development of software and user harmonizing distinct IEEE and ISO/IEC
documentation, including project managers, standards on the subject describes a
usability experts, and information developers single comprehensive process for the
in addition to testers and reviewers. management and execution of software
maintenance. It expands on the
provisions of the software maintenance
IEEE Std. 26513-2010 Standard Adoption of
process provided in ISO/IEC/ IEEE
ISO/ IEC 26513:2009 Systems and Software 12207.
EngineeringRequirements for Testers and
Reviewers of Documentation
ISO/IEC 26513 provides the minimum 14764:2006) Standard for Software
requirements for the testing and reviewing EngineeringSoftware Life Cycle
of user documentation, including both ProcessesMaintenance
printed and onscreen documents used in the
work environment by the users of systems ISO/IEC 14764:2006 describes in
software. It applies to printed user manuals, greater detail management of the
online help, tutorials, and user reference maintenance process described in
documentation. ISO/IEC 12207, including amendments.
It specifies processes for use in testing and It also establishes definitions for the
reviewing of user documentation. It is not various types of maintenance. ISO/IEC
limited to the test and review phase of the 14764:2006 provides guidance that
applies to planning, execution and
life cycle, but includes activities throughout
control, review and evaluation, and
the information management and
closure of the maintenance process. The
documentation management processes.
scope of ISO/IEC 14764:2006 includes
maintenance for multiple software
products with the same maintenance
resources. Maintenance in ISO/IEC
Two standards are mentioned here because
14764:2006 means software
some sources consider software verification
maintenance unless otherwise stated.
and validation to be taxonomically included
ISO/IEC 14764:2006 provides the
in testing.
framework within which generic and
specific software maintenance plans may
be executed, evaluated, and tailored to
IEEE Std. 1012-2012 Standard for System and
the maintenance scope and magnitude of
Software Verification and Validation
given software products. It provides the
See Software Quality KA
framework, precise terminology, and
processes to allow the consistent
IEEE Std. 1044-2009 Standard for
Classification for application of technology (tools,
Software Anomalies techniques, and methods) to software
See Software Quality KA maintenance.
It does not address the operation of
software and the operational functions,
e.g., backup, recovery, and system the terminology in ISO/IEC/IEEE Std.

administration, which are normally 24765 and the information item
performed by those who operate the requirements of IEEE Std. 15939.
software.
ISO/IEC 14764:2006 is written primarily
for maintainers of software and additionally
for those responsible for development and ISO/IEC JTC 1/SC 7 has not yet
quality assurance. It may also be used by determined what action it should take
acquirers and users of systems containing regarding the new IEEE Std. 828. There
software, who may provide inputs to the are issues concerning the extent of
maintenance plan. 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 CONFIGURATION
MANAGEMENT SOFTWARE ENGINEERING
MANAGEMENT
There is one standard
for configuration management. Most readers will interpret the phrase
software engineering management to
mean the management of a project that
concerns software. There are at least two
IEEE Std. 828-2012 Standard for Configuration
possible extensions to this
Management in Systems and Software
generalization, though. Some software
Engineering
activities are managed according to a
service-level agreement (SLA). SLAs do
This standard establishes the minimum
requirements for processes for configuration not meet the criteria for project
management (CM) in systems and software according to some definitions. Also, it
engineering. The application of this standard has become generally agreed that some
applies to any form, class, or type of management of software should occur in
software or system. This revision of the the organization at a level above the
standard expands the previous version to project, so that all projects can benefit
explain CM, including identifying and from a common investment. A
acquiring configuration items, controlling commonly cited example is the
changes, reporting the status of provision of software processes and
configuration items, as well as software tooling by the organization.
builds and release engineering. Its Software project management can be
predecessor defined only the contents of a regarded as a specialization of project
software configuration management plan. management often regarded as a
This standard addresses what CM activities distinct discipline. The Project
are to be done, when they are to happen in Management Institutes Guidetothe
the life cycle, and what planning and ProjectManagement Body of
resources are required. It also describes the Knowledge (PMBOK
content areas for a CM plan. The standard Guide) is often regarded as the
supports ISO/IEC/IEEE 12207:2008 and authoritative source for this knowledge.
ISO/IEC/ IEEE 15288:2008 and adheres to From time to time, IEEE adopts the
most recent version of the PMBOK Guide processes. The jointly developed 16326
as an IEEE standard. standard, replacing two older standards,
expands those provisions with guidance
for application.
IEEE Std. 1490-2011 GuideAdoption of the
Project Management Institute (PMI) ISO/IEC/IEEE 16326:2009 Systems and
Standard, A Guide to the Project Management Software EngineeringLife Cycle
Body of Knowledge (PMBOK Guide) ProcessesProject Management
Fourth Edition
ISO/IEC/IEEE 16326:2009 provides
The PMBOK Guide identifies that subset normative content specifications for
of the project management body of project management plans covering
knowledge generally recognized as good software projects and softwareintensive
practice. Generally recognized means the system projects. It also provides detailed
knowledge and practices described are discussion and advice on applying a set
applicable to most projects most of the time of project processes that are common to
and there is consensus about their value and both the software and system life cycle
usefulness. Good practice means there is as covered by ISO/IEC 12207:2008
general agreement that the application of (IEEE Std. 12207-2008) and ISO/IEC
these skills, tools, and techniques can 15288:2008 (IEEE Std. 15288-2008),
enhance the chances of success over a wide respectively. The discussion and advice
range of projects. Good practice does not are intended to aid in the preparation of
mean the knowledge described should the normative content of project
always be applied uniformly to all projects; management plans. ISO/IEC/IEEE
the organization and/or project management 16326:2009 is the result of the
team is responsible for determining what is harmonization of ISO/IEC TR
appropriate for any given project. The 16326:1999 and IEEE Std. 1058-1998.
PMBOKGuide also provides and
promotes a common vocabulary within the Particularly in high-technology
project management profession for applications and high-consequence
discussing, writing, and applying project projects, the management of risk is an
management concepts. Such a standard important aspect of the overall project
vocabulary is an essential element of a management responsibilities. This
professional discipline. The Project standard deals with that subject.
Management Institute (PMI) views this
standard as a foundational project
management reference for its professional IEEE Std. 16085-2006 (a.k.a. ISO/IEC
development programs and certifications. 16085:2006)
Engineering
Software Life Cycle ProcessesRisk
The 2008 revisions of ISO/IEC/IEEE Management
12207 and 15288 provide project
management processes for software and ISO/IEC 16085:2006 defines a process
systems and relate them to organization- for the management of risk in the life
level processes as well as technical cycle. It can be added to the existing set
of system and software life cycle
processes defined by ISO/IEC 15288 and ISO/IEC 15939:2007 identifies a

ISO/IEC 12207, or it can be used process that supports defining a suitable
independently. set of measures that address specific
ISO/IEC 16085:2006 can be applied information needs. It identifies the
equally to systems and software. activities and tasks that are necessary to
The purpose of risk management is to successfully identify, define, select,
identify potential managerial and technical apply, and improve measurement within
problems before they occur so that actions an overall project or organizational
can be taken that reduce or eliminate the measurement structure. It also provides
probability and/or impact of these problems definitions for measurement terms
should they occur. It is a critical tool for commonly used within the system and
continuously determining the feasibility of software industries.
project plans, for improving the search for
and identification of potential problems that
can affect life cycle activities and the quality Software projects often require the
development of user documentation.
and performance of products, and for Management of the project, therefore,
improving the active management of includes management of the
projects. documentation effort.
The analysis of risk and risk mitigation ISO/IEC/IEEE 26511:2012 Systems and
depends crucially upon measurement. This Software EngineeringRequirements for
international standard provides an Managers of User Documentation
elaboration of the measurement process from
ISO/IEC/IEEE 15288:2008 and ISO/IEC/IEEE 26511:2012 specifies
ISO/IEC/IEEE 12207:2008. procedures for managing user
documentation throughout the software
life cycle. It applies to people or
IEEE Std. 15939-2008 Standard Adoption of organizations producing suites of
ISO/ IEC 15939:2007 Systems and Software documentation, to those undertaking a
EngineeringMeasurement Process single documentation project, and to
documentation produced internally, as
ISO/IEC 15939 defines a measurement well as to documentation contracted to
process applicable to system and software outside service organizations. It provides
engineering and management disciplines. an overview of the software
The process is described through a model documentation and information
that defines the activities of the management processes, and also
measurement process that are required to presents aspects of portfolio planning
adequately specify what measurement and content management that user
information is required, how the measures documentation managers apply. It covers
and analysis results are to be applied, and management activities in starting a
how to determine if the analysis results are project, including setting up procedures
valid. The measurement process is flexible, and specifications, establishing
tailorable, and adaptable to the needs of infrastructure, and building a team. It
different users. includes examples of roles needed on a
user documentation team. It addresses

measurements and estimates needed for
management control, and the use of
Software EngineeringRequirements for
supporting processes such as change Acquirers and Suppliers of User
management, schedule and cost control, Documentation
resource management, and quality
management and process improvement. It ISO/IEC/IEEE 26512:2011 was
includes requirements for key documents developed to assist users of
produced for user documentation ISO/IEC/IEEE 15288:2008 or ISO/
management, including documentation plans IEC/IEEE 12207:2008 to acquire or
and documentation management plans. supply software user documentation as
ISO/IEC/IEEE 26511:2012 is independent part of the software life cycle processes.
of the software tools that may be used to It defines the documentation process
produce or manage documentation, and from the acquirers standpoint and the
applies to both printed documentation and suppliers standpoint. ISO/IEC/IEEE
onscreen documentation. Much of its 26512:2011 covers the requirements for
guidance is applicable to user documentation information items used in the acquisition
for systems including hardware as well as of user documentation products: the
software. acquisition plan, document
specification, statement of work, request
for proposals, and proposal. It provides
an overview of the software user
Sometimes software or system documentation and information
components are acquired rather than management processes which may
developed. require acquisition and supply of
software user documentation products
and services. It addresses the preparation
IEEE Std. 1062-1998 Recommended Practice
for Software Acquisition
of requirements for software user
documentation. These requirements are
A set of useful quality practices that can be central to the user documentation
selected and applied during one or more specification and statement of work. It
steps in a software acquisition process is includes requirements for primary
described. This recommended practice can document outputs of the acquisition and
be applied to software that runs on any supply process: the request for proposal
computer system regardless of the size, and the proposal for user documentation
complexity, or criticality of the software, but products and services. It also discusses
is more suited for use on modified-off- the use of a documentation management
theshelf software and fully developed plan and a document plan as they arise
software. in the acquisition and supply processes.
ISO/IEC/IEEE 26512:2011 is
independent of the software tools that
may be used to produce documentation
Sometimes user documentation is acquired and applies to both printed
regardless of whether the software it documentation and onscreen
describes was acquired. The following documentation. Much of its guidance is
standard deals with that subject. applicable to user documentation for
systems including hardware as well as model. A superior approach is to

software. describe the practice in the context of a
process that can be applied at any stage
of the life cycle. The requirements
analysis process, for example, is
The next two standards are mentioned necessary for the development stage, for
here because they supply information used maintenance, and often for retirement,
in management decision-making. so an improved practice described in
terms of the requirements analysis
process can be applied to any of those
IEEE Std. 1028-2008 Standard for Software stages.
Reviews and Audits The two key standards are
See Software Quality KA ISO/IEC/IEEE
12207, SoftwareLifeCycleProcesses,
IEEE Std. 1061-1998 Standard for Software and ISO/ IEC/IEEE 15288, SystemLife
Quality CycleProcesses. The two standards
Metrics Methodology have distinct histories, but they were
See Software Quality KA both revised in 2008 to align their
processes, permitting their interoperable
use across a wide spectrum of projects
ranging from a standalone software
The next standard is mentioned because it component to a system with negligible
includes the managers role in developing software content. Both are being revised
user documentation in an agile project. again with the intent of containing an
identical list of processes, but with
provisions specialized for the respective
ISO/IEC/IEEE 26515:2012 Systems and disciplines.
Software EngineeringDeveloping User
Documentation in an
Agile Environment
See Software Engineering Models and
12207:2008)
Methods KA
Engineering Software Life Cycle
Processes
SOFTWARE ENGINEERING PROCESS

ISO/IEC 12207:2008 establishes a
common framework for software life
Software and systems engineering processes
cycle processes, with well-defined
are central to the standardization of those
terminology that can be referenced by
two disciplinesnot just because many are the software industry.
interested in process improvement, but also ISO/IEC 12207:2008 applies to the
because processes are effective for the acquisition of systems and software
description of improved practices. For products and services and to the supply,
example, one might propose an improved development, operation, maintenance,
practice for software requirements analysis. and disposal of software products and
A nave treatment might relate the the software portion of a system,
description to an early stage of the life cycle
whether performed internally or externally to cycle processes documented in ISO/IEC

an organization. Those aspects of system 12207:2008 may be used to implement
definition needed to provide the context for that system element.
software products and services are included. ISO/IEC 15288:2008 and ISO/IEC
ISO/IEC 12207:2008 also provides a 12207:2008 are harmonized for
process that can be employed for defining, concurrent use on a single project or in a
controlling, and improving software life single organization.
cycle processes.
The processes, activities and tasks of
ISO/IEC 12207:2008either alone or in
conjunction with ISO/IEC 15288may also Those two standards specify that
be applied during the acquisition of a system processes may produce items of
that contains software. information but do not prescribe their
IEEE Std. 15288-2008 (a.k.a. ISO/IEC content or format. The next standard
15288:2008) provides help with that.
Engineering System Life Cycle Processes
ISO/IEC 15288:2008 establishes a common Software EngineeringContent of Life-
framework for describing the life cycle of Cycle Information
systems created by humans. It defines a set Products (Documentation)
of processes and associated terminology.
These processes can be applied at any level ISO/IEC/IEEE 15289:2011 provides
in the hierarchy of a systems structure. requirements for identifying and
Selected sets of these processes can be planning the specific information items
applied throughout the life cycle for (information products, documentation)
managing and performing the stages of a to be developed and revised during
systems life cycle. This is accomplished systems and software life cycles and
through the involvement of all interested service management processes. It
parties, with the ultimate goal of achieving specifies the purpose and content of all
customer satisfaction. identified systems and software data
ISO/IEC 15288:2008 also provides records and life cycle information items,
processes that support the definition, control, as well as records and information items
and improvement of the life cycle processes for information technology service
used within an organization or a project. management. The information item
Organizations and projects can use these life contents are defined according to
cycle processes when acquiring and generic document types (description,
supplying systems. plan, policy, procedure, report, request,
ISO/IEC 15288:2008 concerns those and specification) and the specific
systems that are man-made and may be purpose of the document. For simplicity
configured with one or more of the of reference, each information item is
following: hardware, software, data, described as if it were published as a
humans, processes (e.g., processes for separate document. However,
providing service to users), procedures (e.g., information items may be unpublished
operator instructions), facilities, materials, but available in a repository for
and naturally occurring entities. When a reference, divided into separate
system element is software, the software life
documents or volumes, or combined with ISO/IEC TR 24748-1 and ISO/IEC

other information items into one document. 12207:2008. It gives guidance on
ISO/IEC/IEEE 15289:2011 is based on the applying ISO/ IEC 12207:2008 from the
life cycle processes specified in ISO/IEC aspects of strategy, planning, application
12207:2008 (IEEE Std. 12207-2008) and in organizations, and application on
ISO/IEC 15288:2008 (IEEE Std. projects.
152882008), and the service management
processes specified in ISO/IEC 20000-
1:2005 and ISO/IEC 20000-2:2005.
The 12207 and 15288 standards
provide processes covering the life
cycle, but they do not provide a standard
The next two guides provide life cycle model (waterfall, incremental
supplementary information helpful in delivery, prototype-driven, etc).
applying 12207 and 15288. Selecting an appropriate life cycle model
for a project is a major concern of
ISO/IEC 24748-1.
IEEE Std. 24748.2-2012 GuideAdoption of
ISO/ IEC TR 24748-2:2011 Systems and
Software EngineeringLife Cycle IEEE Std. 24748.1-2011 GuideAdoption
ManagementPart 2: Guide to the of ISO/ IEC TR 24748-1:2010 Systems and
Application of ISO/IEC 15288 (System Life Software EngineeringLife Cycle
Cycle Processes) ManagementPart 1: Guide for Life
Cycle Management
ISO/IEC TR 24748-2 is a guide for the
application of ISO/IEC 15288:2008. It ISO/IEC TR 24748-1 provides
addresses system, life cycle, process, information on life cycle concepts and
organizational, project, and adaptation descriptions of the purposes and
concepts, principally through reference to outcomes of representative life cycle
ISO/IEC TR 24748-1 and ISO/IEC stages. It also illustrates the use of a life
15288:2008. It then gives guidance on cycle model for systems in the context
applying ISO/IEC 15288:2008 from the of ISO/IEC 15288 and provides a
aspects of strategy, planning, application in corresponding illustration of the use of a
organizations, and application on projects. life cycle model for software in the
context of ISO/IEC 12207. ISO/IEC TR
IEEE Std. 24748.3-2012 GuideAdoption of 24748-1 additionally provides detailed
ISO/IEC TR 24748-3:2011 Systems and discussion and advice on adapting a life
Software EngineeringLife Cycle cycle model for use in a specific project
ManagementPart 3: Guide to the and organizational environment. It
Application of ISO/IEC 12207 (Software Life further provides guidance on life cycle
Cycle Processes)
model use by domains, disciplines and
specialties. ISO/ IEC TR 24748-1 gives
ISO/IEC TR 24748-3 is a guide for the a detailed comparison between prior and
application of ISO/IEC 12207:2008. It current versions of ISO/IEC 12207 and
addresses system, life cycle, process, ISO/IEC 15288 as well as advice on
organizational, project, and adaptation transitioning from prior to current
concepts, principally through reference to versions and on using their application
guides. The discussion and advice are IEEE Std. 1220-2005 (a.k.a. ISO/IEC
intended to provide a reference model for 26702:2007)
life cycle models, facilitate use of the Standard for Application and Management
updated ISO/IEC 15288 and ISO/IEC of the Systems Engineering Process
12207, and provide a framework for the
development of updated application guides ISO/IEC 26702 defines the
for those International Standards. ISO/IEC interdisciplinary tasks which are
TR 24748-1 is a result of the alignment stage required throughout a systems life cycle
of the harmonization of ISO/IEC 12207 and to transform customer needs,
ISO/IEC 15288. requirements, and constraints into a
system solution. In addition, it specifies
the requirements for the systems
engineering process and its application
The next standard extends the provisions throughout the product life cycle.
of ISO/IEC/IEEE 12207 to deal with ISO/IEC 26702:2007 focuses on
systematic software reuse. engineering activities necessary to guide
product development, while ensuring
that the product is properly designed to
IEEE Std. 1517-2010 Standard for Information make it affordable to produce, own,
TechnologySystem and Software Life Cycle operate, maintain, and eventually
ProcessesReuse Processes dispose of without undue risk to health
or the environment.
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 Since SC 7 and IEEE have written so
processes, activities, and tasks to be applied many process standards, one may not be
during each life cycle process to enable a surprised to learn that their model for
system and/or product to be constructed process description is recorded in a
from reusable assets are specified. The Technical Report.
processes, activities, and tasks to enable the
identification, construction, maintenance,
and management of assets supplied are also IEEE Std. 24774-2012 GuideAdoption of
specified. ISO/IEC TR 24474:2010 Systems and
Software EngineeringLife Cycle
ManagementGuidelines for Process
Description
IEEE Std. 1220 has been widely applied
as a systems engineering process and was An increasing number of international,
adopted by ISO/IEC with the number 26702. national, and industry standards describe
Unfortunately, the standard is not completely process models. These models are
compatible with ISO/IEC/IEEE 15288 and is developed for a range of purposes
being revised to solve that problem. The including process implementation and
result will be published as ISO/IEC/IEEE assessment. The terms and descriptions
24748-4. used in such models vary in format,
content, and level of prescription.
ISO/IEC TR 24774:2010 presents
guidelines for the elements used most defined as an enterprise, organization,

frequently in describing a process: the title, department, or project having up to 25
purpose, outcomes, activities, task, and people. A set of standards and guides has
information item. Whilst the primary been developed according to a set of
purpose of ISO/IEC TR 24774:2010 is to VSEs characteristics and needs. The
encourage consistency in standard process guides are based on subsets of
reference models, the guidelines it provides appropriate standards elements, referred
can be applied to any process model to as VSE profiles. The purpose of a
developed for any purpose. 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
A very small entity (VSE) is an enterprise, provides the management and
an organization, a department, or a project engineering guide to the basic VSE
having up to 25 people. The ISO/IEC 29110 profile applicable to VSEs that do not
series profiles large standards, such as develop critical software. The generic
ISO/IEC 12207 for software and ISO/IEC profile group does not imply any
15288 for systems, into smaller ones for specific application domain.
VSEs. ISO 29110 is applicable to VSEs that
do not develop critical systems or critical
software. Profiles provide a roadmap
allowing a start-up to grow a step at a time The next standard may be viewed as
using the ISO 29110 management and an alternative to 12207 for individual
engineering guides. projects. The 1074 standard explains
ISO/IEC 29110 set of standards and how to define processes for use on a
technical reports are targeted by audience given project. The 12207 and 15288
such as VSEs, customers, or auditors. standards, however, focus on defining
ISO/IEC 29110 is not intended to preclude processes for organizational adoption
the use of different life cycles approaches and repeated use on many projects. The
such as waterfall, iterative, incremental, current 1074 is the update of a standard
evolutionary, or agile. that was a predecessor of 12207.
A VSE could obtain an ISO/IEC 29110
Certification. The set of technical reports is
available at no cost on the ISO website. IEEE Std. 1074-2006 Standard for
Many ISO 29110 documents are available in Developing a Software Project Life Cycle
English, Spanish, Portuguese, Japanese, and Process
French.
This standard provides a process for
creating a software project life cycle
ISO/IEC TR 29110-5-1-2:2011 Software process (SPLCP). It is primarily directed
EngineeringLifecycle Profiles for Very Small at the process architect for a given
Entities (VSEs)Part 5-1-2: Management and software project.
Engineering Guide: Generic Profile Group:
Basic Profile All of the standards described so far in
this section provide a basis for defining
ISO/IEC TR 29110-5-1-2:2011 is applicable processes. Some users are interested in
to very small entities (VSEs). A VSE is
assessing and improving their processes provides a basis for use in process
after implementation. The 15504 series improvement and capability
provides for process assessment; it is determination;
currently being revised and renumbered takes into account the context in
330xx. which the assessed process is
implemented;
produces a process rating;
ISO/IEC 15504 [ten parts] Information addresses the ability of the process
TechnologyProcess Assessment to achieve its purpose;
is applicable across all application
ISO/IEC 15504-2:2003 defines the domains and sizes of organization;
requirements for performing process and
assessment as a basis for use in process may provide an objective
improvement and capability determination. benchmark between organizations.
Process assessment is based on a two-
dimensional model containing a process The minimum set of requirements
dimension and a capability dimension. The defined in ISO/IEC 15504-2:2003
process dimension is provided by an external ensures that assessment results are
process reference model (such as 12207 or objective, impartial, consistent,
15288), which defines a set of processes repeatable, and representative of the
characterized by statements of process assessed processes. Results of
purpose and process outcomes. The conformant process assessments may be
capability dimension consists of a compared when the scopes of the
measurement framework comprising six assessments are considered to be similar;
process capability levels and their associated for guidance on this matter, refer to
process attributes. ISO/IEC 15504-4.
The assessment output consists of a set of
process attribute ratings for each process
assessed, termed the process profile, and
may also include the capability level Several other standards are mentioned
achieved by that process. here because they are written as
ISO/IEC 15504-2:2003 identifies the elaborations of the processes of 12207 or
measurement framework for process 15288. They are allocated to other KAs
capability and the requirements for because each one deals with topics
described in those other KAs.
performing an assessment;
process reference models;
process assessment models; IEEE Std. 828-2012 Standard for
verifying conformity of process Configuration
assessment. Management in Systems and Software
Engineering See Software
The requirements for process assessment Configuration Management KA
defined in ISO/IEC 15504-2:2003 form a
structure that IEEE Std. 14764-2006 (a.k.a. ISO/IEC
14764:2006) Standard for Software
facilitates self-assessment; EngineeringSoftware Life
Cycle ProcessesMaintenance See Software those of the aforementioned engineering

Maintenance KA standards, but may be preferable for
situations where the risks of failure
ISO/IEC 15026-4:2012 Systems and Software involve money or customer satisfaction
EngineeringSystems and Software Assurance rather than public health, safety, and
Part 4: welfare. The ISO/IEC 20000 series now
Assurance in the Life Cycle extend to many parts. The foundation of
See Software Quality KA the series, ISO/IEC 20000-1, is briefly
described below.
IEEE Std. 15939-2008 Standard Adoption of
ISO/ IEC 15939:2007 Systems and Software
EngineeringMeasurement Process
ISO/IEC 20000-1:2011 Information
See Software Engineering Management KA
Technology Service ManagementPart
1: Service Management System
ISO/IEC 15940:2006 Information Technology
Requirements

Software Engineering Environment Services
See Software Engineering Models ISO/IEC 20000-1:2011 is a service
management system (SMS) standard. It
and
specifies requirements for the service
Methods KA
provider to plan, establish, implement,
operate, monitor, review, maintain, and
16085:2006) improve an SMS. The requirements
Standard for Systems and Software include the design, transition, delivery
Engineering and improvement of services to fulfill
Software Life Cycle ProcessesRisk agreed service requirements.
Management
See Software Engineering Management KA
ISO/IEC/IEEE 16326:2009 Systems and IEEE has adopted the first two parts of
Software EngineeringLife Cycle Processes the ISO/ IEC 20000 series.
Project
Management SOFTWARE ENGINEERING
See Software Engineering Management KA MODELS
AND METHODS
Software EngineeringLife Cycle Processes Some approaches to software
Requirements engineering use methods that cut across
Engineering large parts of the life cycle, rather than
See Software Requirements KA focusing on specific processes. Chief
Programmer was one traditional
example. Agile development (actually
an example of traditional incremental
Some users desire process standards delivery) is a current example. Neither
usable for IT operations or IT service S2ESC nor SC 7 has a standard for agile
management. The ISO/IEC 20000 series development, but there is a standard for
describe IT service management. The developing user documentation in an
processes are less rigorously defined than agile project.
IDEF0 function modeling is designed to

represent the decisions, actions, and
activities of an existing or prospective
Software EngineeringDeveloping User
Documentation in an Agile Environment organization or system. IDEF0 graphics
and accompanying texts are presented in
ISO/IEC/IEEE 26515:2012 specifies the an organized and systematic way to gain
way in which user documentation can be understanding, support analysis, provide
developed in agile development projects. It logic for potential changes, specify
is intended for use in all organizations that requirements, and support system-level
are using agile development or are design and integration activities. IDEF0
considering implementing their projects may be used to model a wide variety of
using these techniques. It applies to people systems, composed of people, machines,
or organizations producing suites of materials, computers, and information of
documentation, to those undertaking a single all varieties, and structured by the
documentation project, and to relationships among them, both
documentation produced internally, as well automated and nonautomated. For new
as to documentation contracted to outside systems, IDEF0 may be used first to
service organizations. ISO/IEC/IEEE define requirements and to specify the
26515:2012 addresses the relationship functions to be carried out by the future
between the user documentation process and system. As the basis of this architecture,
the life cycle documentation process in agile IDEF0 may then be used to design an
development. It describes how the implementation that meets these
information developer or project manager requirements and performs these
may plan and manage the user functions. For existing systems, IDEF0
documentation development in an agile can be used to analyze the functions that
environment. It is intended neither to the system performs and to record the
encourage nor to discourage the use of any means by which these are done.
particular agile development tools or
IEEE Std. 1320.2-1998 Standard for
methods.
Conceptual Modeling LanguageSyntax
and Semantics for IDEF1X97
(IDEFobject)
Many methodologies are based on

IDEF1X 97 consists of two conceptual
semiformal descriptions of the software to modeling languages. The key-style
be constructed. These range from simple language supports data/ information
descriptive notations to models that can be modeling and is downward compatible
manipulated and tested and, in some cases, with the US governments 1993
can generate code. Two relatively old standard, FIPS PUB 184. The identity-
techniques start the list; the first has been style language is based on the object
widely applied for modeling processes and model with declarative rules and
workflows. constraints. IDEF1X 97 identity style
includes constructs for the distinct but
related components of object
IEEE Std. 1320.1-1998 Standard for abstraction: interface, requests, and
Functional Modeling LanguageSyntax and realization; utilizes graphics to state the
Semantics for IDEF0 interface; and defines a declarative,
directly executable rule and constraint Language (UML), revision 2. The

language for requests and realizations. objective of UML is to provide system
IDEF1X 97 conceptual modeling supports architects, software engineers, and
implementation by relational databases, software developers with tools for
extended relational databases, object analysis, design, and implementation of
databases, and object programming softwarebased systems as well as for
languages. IDEF1X 97 is formally defined modeling business and similar
in terms of first order logic. A procedure is processes.
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 Two more standards build on the base
define the valid set of IDEF1X 97 models. of UML to provide additional modeling
capabilities:
In recent years, the UML notation has ISO/IEC 19506:2012 Information

become popular for modeling software- Technology Object Management Group
intensive systems. Architecture-Driven Modernization
The next two standards provide two versions (ADM)Knowledge Discovery
of the UML language. Meta-Model (KDM)
ISO/IEC 19506:2012 defines a

ISO/IEC 19501:2005 Information Technology metamodel for representing existing
Open Distributed ProcessingUnified software assets, their associations, and
Modeling operational environments, referred to as
Language (UML) Version 1.4.2 the knowledge discovery metamodel
(KDM). This is the first in the series of
ISO/IEC 19501 describes the Unified specifications related to software
Modeling Language (UML), a graphical assurance (SwA) and architecture-driven
language for visualizing, specifying, modernization (ADM) activities. KDM
constructing, and documenting the artifacts facilitates projects that involve existing
of a software-intensive system. The UML software systems by insuring
offers a standard way to write a systems interoperability and exchange of data
blueprints, including conceptual things such between tools provided by different
as business processes and system functions vendors.
as well as concrete things such as
ISO/IEC 19507:2012 Information
programming language statements, database
Technology Object Management Group
schemas, and reusable software components.
Object Constraint Language (OCL)
ISO/IEC 19505:2012 [two parts] Information
TechnologyObject Management Group ISO/IEC 19507:2012 defines the Object
Unified Modeling Language (OMG UML) Constraint Language (OCL), version
2.3.1. OCL version 2.3.1 is the version
ISO/IEC 19505 defines the Unified of OCL that is aligned with UML 2.3
Modeling and MOF 2.0.
Some organizations invest in software Their selection must be carried out with
engineering environments (SEE) to assist in careful consideration of both the
the construction of software. An SEE, per se, technical and management requirements.
is not a replacement for sound processes. ISO/IEC 14102:2008 defines both a
However, a suitable SEE must support the set of processes and a structured set of
processes that have been chosen by the CASE tool characteristics for use in the
organization. technical evaluation and the ultimate
selection of a CASE tool. It follows the
software product evaluation model
ISO/IEC 15940:2006 Information Technology defined in ISO/IEC 14598-5:1998.
Software Engineering Environment Services ISO/IEC 14102:2008 adopts the
general model of software product
ISO/IEC 15940:2006 defines software quality characteristics and
engineering environment (SEE) services subcharacteristics defined in ISO/IEC
conceptually in a reference model that can 91261:2001 and extends these when the
be adapted to any SEEs to automate one or software product is a CASE tool; it
more software engineering activities. It provides product characteristics unique
describes services that support the process to CASE tools.
definitions 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 reference or to The next document provides guidance
define an automated software process. on how to adopt CASE tools, once
selected.
The selection of tooling for a software IEEE Std. 14471-2010 GuideAdoption of

engineering environment is itself a difficult ISO/IEC TR 14471:2007 Information
task. Two standards provide some assistance. TechnologySoftware Engineering
ISO/IEC 14102:2008 defines both a set of Guidelines for the Adoption of CASE Tools
processes and a structured set of computer-
aided software engineering (CASE) tool The purpose of ISO/IEC TR 14471:2007
characteristics for use in the technical is to provide a recommended practice
evaluation and the ultimate selection of a for CASE adoption. It provides guidance
CASE tool. in establishing processes and activities
that are to be applied for the successful
adoption of CASE technology. The use
IEEE Std. 14102-2010 Standard Adoption of of ISO/IEC TR 14471:2007 will help to
ISO/ IEC 14102:2008 Information Technology maximize the return and minimize the
Guideline for the Evaluation and Selection of risk of investing in CASE technology.
CASE Tools However, ISO/ IEC TR 14471:2007
does not establish compliance criteria.
Within systems and software engineering, It is best used in conjunction with
computer-aided software engineering ISO/IEC 14102 for CASE tool
(CASE) tools represent a major part of the evaluation and selection. It neither
supporting technologies used to develop and dictates nor advocates particular
maintain information technology systems. development standards, software
processes, design methods, methodologies, throughout an organization. The

techniques, programming languages, or life terminology of that standard may be
cycle paradigms. unfamiliar to software professionals, and
Within a software engineering quality management auditors may be
environment, it is important for the various unfamiliar with software jargon. The
tools to interoperate. The following following standard describes the
standards provide a scheme for relationship between ISO 9001 and
interconnection. ISO/IEC 12207. Unfortunately, the
current version refers to obsolete
editions of both; a replacement is in
IEEE Std. 1175.1-2002 Guide for CASE Tool progress:
InterconnectionsClassification and
Description
IEEE Std. 90003-2008 GuideAdoption of
IEEE Std. 1175.2-2006 Recommended Practice ISO/
for CASE Tool Interconnection IEC 90003:2004 Software Engineering
Characterization of Interconnections Guidelines for the Application of ISO
9001:2000 to Computer Software
IEEE Std. 1175.3-2004 Standard for CASE
Tool InterconnectionsReference Model for ISO/IEC 90003 provides guidance for
Specifying Software Behavior organizations in the application of ISO
9001:2000 to the acquisition, supply,
IEEE Std. 1175.4-2008 Standard for CASE development, operation, and
Tool InterconnectionsReference Model for
maintenance of computer software and
Specifying
related support services. ISO/IEC
System Behavior
90003:2004 does not add to or otherwise
change the requirements of ISO
The purpose of this family of standards is to
9001:2000.
specify a common set of modeling concepts
The guidelines provided in
based on those found in commercial CASE ISO/IEC
tools for describing the operational behavior 90003:2004 are not intended to be used
of a software system. These standards as assessment criteria in quality
establish a uniform, integrated model of management system
software concepts related to software registration/certification.
functionality. They also provide a textual The application of ISO/IEC
syntax for expressing the common properties 90003:2004 is appropriate to software
(attributes and relationships) of those that is
concepts as they have been used to model
software behavior. part of a commercial contract with
another organization,
a product available for a market
sector,
SOFTWARE QUALITY used to support the processes of an
organization,
One viewpoint of software quality starts
embedded in a hardware product, or
with ISO 9001, Quality Management
related to software services.
Requirements, dealing with quality policy
Some organizations may be involved in all standards covers this approach in great
the above activities; others may specialize in detail.
one area. Whatever the situation, the
organizations quality management system
should cover all aspects (software related ISO/IEC 25000 through 25099 Software
and nonsoftware related) of the business. EngineeringSoftware Product Quality
ISO/IEC 90003:2004 identifies the issues Requirements and Evaluation (SQuaRE)
which should be addressed and is
independent of the technology, life cycle
models, development processes, sequence of
activities, and organizational structure used A few of the SQuaRE standards are
by an organization. Additional guidance and selected below for particular attention.
frequent references to the ISO/IEC JTC The first is the overall guide to the
1/SC 7 software engineering standards are series.
provided to assist in the application of ISO
9001:2000: in particular, ISO/IEC 12207,
ISO/IEC TR 9126, ISO/ IEC 14598, ISO/IEC 25000:2005 Software Engineering
ISO/IEC 15939, and ISO/IEC TR 15504. Software Product Quality Requirements
and Evaluation (SQuaRE)Guide to
SQuaRE
The ISO 9001 approach posits an ISO/IEC 25000:2005 provides guidance

organization-level quality management for the use of the new series of
process paired with project-level quality international standards named Software
assurance planning to achieve the product Quality Requirements and
organizational goals. IEEE 730 describes Evaluation (SQuaRE). The purpose of
project-level quality planning. It is currently this guide is to provide a general
aligned with an obsolete edition of 12207, overview of SQuaRE contents, common
but a revision is being prepared. reference models, and definitions, as
well as the relationship among the
documents, allowing users of this guide
IEEE Std. 730-2002 Standard for Software a good understanding of those
Quality Assurance Plans international standards. This document
contains an explanation of the transition
The standard specifies the format and process between the old ISO/IEC 9126
content of software quality assurance plans. and the 14598 series and SQuaRE, and
also presents information on how to use
the ISO/IEC 9126 and 14598 series in
Another viewpoint of software quality their previous form.
begins with enumerating the desired SQuaRE provides
characteristics of a software product and
selecting measures or other evaluations to terms and definitions,
determine if the desired level of reference models,
characteristics has been achieved. The so- guides
called SQuaRE (software product quality standards for requirements
requirements and evaluation) series of SC 7 specification, planning and
management, measurement, and Although the scope of the product

evaluation purposes. quality model is intended to be software
and computer systems, many of the
The next SQuaRE standard provides a characteristics are also relevant to wider
taxonomy of software quality characteristics systems and services.
that may be useful in selecting ISO/IEC 25012 contains a model for
characteristics relevant to a specific project: data quality that is complementary to
this model.
The scope of the models excludes
ISO/IEC 25010:2011 Systems and Software purely functional properties, but it does
EngineeringSystems and Software Quality include functional suitability.
Requirements and Evaluation (SQuaRE) The scope of application of the quality
System and Software Quality Models models includes supporting specification
and evaluation of software and software-
ISO/IEC 25010:2011 defines the following: intensive computer systems from
different perspectives by those who are
1. A quality in-use model composed of five associated with their acquisition,
characteristics (some of which are requirements, development, use,
further subdivided into evaluation, support, maintenance,
subcharacteristics) that relate to the quality assurance and control, and audit.
outcome of interaction when a product The models can, for example, be used by
is used in a particular context of use. developers, acquirers, quality assurance
This system model is applicable to the and control staff, and independent
complete human-computer system, evaluators, particularly those responsible
including both computer systems in use for specifying and evaluating software
and software products in use. product quality. Activities during
2. A product quality model composed of product development that can benefit
eight characteristics (which are further from the use of the quality models
subdivided into subcharacteristics) that include
relate to static properties of software and
dynamic properties of the computer identifying software and system
system. The model is applicable to both requirements;
computer systems and software validating the comprehensiveness of
products. a requirements definition;
identifying software and system
The characteristics defined by both design objectives;
models are relevant to all software products identifying software and system
and computer systems. The characteristics testing objectives;
and subcharacteristics provide consistent identifying quality control criteria as
terminology for specifying, measuring, and part of quality assurance;
evaluating system and software product identifying acceptance criteria for a
quality. They also provide a set of quality software product and/or software-
characteristics against which stated quality intensive computer system;
requirements can be compared for establishing measures of quality
completeness. characteristics in support of these
activities.
Some documents in the SQuaRE series The CIF family focuses on

deal specifically with the characteristic of documenting those elements needed for
usability. The Common Industry Format design and development of usable
(CIF) for usability reporting began at the US systems, rather than prescribing a
National Institute for Standards and specific process. It is intended to be used
Technology (NIST) and was moved into in conjunction with existing
ISO/ IEC JTC 1/SC 7 for purposes of international standards, including ISO
standardization. 9241, ISO 20282, ISO/IEC 9126, and
the SQuaRE series (ISO/IEC 25000 to
ISO/IEC 25099).
ISO/IEC 25060 through 25064 Software The CIF family of standards does not
EngineeringSoftware Product Quality prescribe any kind of method, life cycle
Requirements and Evaluation (SQuaRE) or process.
Common Industry Format
(CIF) for Usability
Not everyone agrees with the
A family of international standards, named taxonomy of quality characteristics in
the Common Industry Formats (CIF), ISO/IEC 25010. That standard has a
documents the specification and evaluation quality factor called reliability that has
of the usability of interactive systems. It subfactors of maturity, availability, fault
provides a general overview of the CIF tolerance, and recoverability. IEC TC
framework and contents, definitions, and the 65, which has responsibility for
relationship of the framework elements. The standards on dependability, defines
intended users of the framework are that term as a nonquantitative composite
identified, as well as the situations in which of reliability, maintainability, and
the framework may be applied. The maintenance support. Others use the
assumptions and constraints of the term reliability to denote a measure
framework are also enumerated. The defined by a mathematical equation. The
framework content includes the following: disagreement over the use of these
words means that the standards on the
consistent terminology and classification subject are inherently unaligned. A few
of specification, evaluation, and will be noted below, but the words like
reporting; those noted above may mean different
a definition of the type and scope of things in different standards.
formats and the high-level structure to
be used for documenting required IEEE Std. 982.1-2005 Standard for
information and the results of Dictionary of
evaluation. Measures of the Software Aspects of
Dependability
The CIF family of standards is applicable
to software and hardware products used for A standard dictionary of measures of the
predefined tasks. The information items are software aspects of dependability for
intended to be used as part of system-level assessing and predicting the reliability,
documentation resulting from development maintainability, and availability of any
processes such as those in ISO 9241-210 and software system; in particular, it applies
ISO/IEC JTC 1/SC 7 process standards. to mission critical software systems.
IEEE Std. 1633-2008 Recommended Practice IEEE Std. 1012-2012 Standard for System
for Software Reliability and Software Verification and Validation
The methods for assessing and predicting the Verification and validation (V&V)
reliability of software, based on a life cycle processes are used to determine whether
approach to software reliability engineering, the development products of a given
are prescribed in this recommended practice. activity conform to the requirements of
It provides information necessary for the that activity and whether the product
application of software reliability (SR) satisfies its intended use and user needs.
measurement to a project, lays a foundation V&V life cycle process requirements are
for building consistent methods, and specified for different integrity levels.
establishes the basic principle for collecting The scope of V&V processes
the data needed to assess and predict the encompasses systems, software, and
reliability of software. The recommended hardware, and it includes their
practice prescribes how any user can interfaces. This standard applies to
participate in SR assessments and systems, software, and hardware being
predictions. developed, maintained, or reused
[legacy, commercial off-theshelf
(COTS), nondevelopmental items]. The
term software also includes firmware
IEEE has an overall standard for software and microcode, and each of the terms
product quality that has a scope similar to system, software, and hardware includes
the ISO/IEC 250xx series described documentation. V&V processes include
previously. Its terminology differs from the the analysis, evaluation, review,
ISO/IEC series, but it is substantially more inspection, assessment, and testing of
compact. products.

Quality There are other standards that support
Metrics Methodology the verification and validation processes.
One describes techniques for performing
A methodology for establishing quality reviews and audits during a software
requirements and identifying, implementing, project.
analyzing, and validating the process and
product software quality metrics is defined.
The methodology spans the entire software IEEE Std. 1028-2008 Standard for
life cycle. Software Reviews and Audits
One approach to achieving software
quality is to perform an extensive program Five types of software reviews and
of verification and validation. IEEE Std. audits, together with procedures required
1012 is probably the worlds most widely for the execution of each type, are
applied standard on this subject. A revision defined in this standard. This standard is
was recently published. concerned only with the reviews and
audits; procedures for determining the
necessity of a review or audit are not
defined, and the disposition of the results of IEEE Std. 15026.1-2011 Trial-Use
the review or audit is not specified. Types Standard Adoption of ISO/IEC TR 15026-
included are management reviews, technical 1:2010 Systems and Software Engineering
reviews, inspections, walkthroughs, and Systems and Software AssurancePart
audits. 1: Concepts and Vocabulary
In many cases, a database of software
anomalies is used to support verification and This trial-use standard adopts ISO/IEC
validation activities. The following standard TR 15026-1:2010, which defines terms
suggests how anomalies should be classified. and establishes an extensive and
organized set of concepts and their
relationships for software and systems
IEEE Std. 1044-2009 Standard for
assurance, thereby establishing a basis
Classification for Software Anomalies
for shared understanding of the concepts
and principles central to ISO/IEC 15026
This standard provides a uniform approach
across its user communities. It provides
to the classification of software anomalies,
information to users of the subsequent
regardless of when they originate or when
parts of ISO/IEC 15026, including the
they are encountered within the project,
use of each part and the combined use of
product, or system life cycle. Classification
multiple parts. Coverage of assurance
data can be used for a variety of purposes,
for a service being operated and
including defect causal analysis, project
managed on an ongoing basis is not
management, and software process
covered in ISO/IEC 15026.
improvement (e.g., to reduce the likelihood
of defect insertion and/or increase the The second part of the standard
likelihood of early defect detection). 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
In some systems, one particular property various domain-specific constructs like
of the software is so important that it safety cases.
requires special treatment beyond that
provided by a conventional verification and
validation program. The emerging term for IEEE Std. 15026.2-2011 Standard
this sort of treatment is systems and Adoption of ISO/ IEC 15026-2:2011
software assurance. Examples include Systems and Software Engineering
safety, privacy, high security, and Systems and Software AssurancePart 2:
ultrareliability. The 15026 standard is under Assurance Case
development to deal with such situations.
The first part of the four-part standard ISO/IEC 15026-2:2011 is adopted by
provides terminology and concepts used in this standard. ISO/IEC 15026-2:2011
the remaining parts. It was first written specifies minimum requirements for the
before the other parts and is now being structure and contents of an assurance
revised for complete agreement with the case to improve the consistency and
others. comparability of assurance cases and to
facilitate stakeholder communications,
engineering decisions, and other uses of
assurance cases. An assurance case
includes a top-level claim for a property of a ISO/IEC 15026-3:2011 specifies the

system or product (or set of claims), concept of integrity levels with
systematic argumentation regarding this corresponding integrity level
claim, and the evidence and explicit requirements that are required to be met
assumptions that underlie this in order to show the achievement of the
argumentation. Arguing through multiple integrity level. It places requirements on
levels of subordinate claims, this structured and recommends methods for defining
argumentation connects the top-level claim and using integrity levels and their
to the evidence and assumptions. Assurance integrity level requirements, including
cases are generally developed to support the assignment of integrity levels to
claims in areas such as safety, reliability, systems, software products, their
maintainability, human factors, operability, elements, and relevant external
and security, although these assurance cases dependences.
are often called by more specific names, ISO/IEC 15026-3:2011 is applicable
e.g., safety case or reliability and to systems and software and is intended
maintainability (R&M) case. ISO/IEC for use by:
15026-2:2011 does not place requirements
on the quality of the contents of an definers of integrity levels such as
assurance case and does not require the use industry and professional
of a particular terminology or graphical organizations, standards
representation. Likewise, it places no organizations, and government
requirements on the means of physical agencies;
implementation of the data, including no users of integrity levels such as
requirements for redundancy or colocation. developers and maintainers,
suppliers and acquirers, users, and
assessors of systems or software,
and for the administrative and
In many systems, some portions are technical support of systems and/or
critical to achieving the desired property software products.
while others are only incidental. For
example, the flight control system of an One important use of integrity levels
airliner is critical to safety, but the is by suppliers and acquirers in
microwave oven is not. Conventionally, the agreements; for example, to aid in
various portions are assigned criticality assuring safety, economic, or security
levels to indicate their significance to the characteristics of a delivered system or
overall achievement of the property. The product.
third part of ISO/IEC 15026 describes how ISO/IEC 15026-3:2011 does not
that is done. This part will be revised for prescribe a specific set of integrity levels
better fit with the remainder of the 15026 or their integrity level requirements. In
standard. addition, it does not prescribe the way in
which integrity level use is integrated
ISO/IEC 15026-3:2011 Systems and Software with the overall system or software
EngineeringSystems and Software Assurance engineering life cycle processes.
Part 3: System Integrity Levels 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 was originally developed in cooperation
development approaches. ISO/IEC TR with the US nuclear power industry.
15026-1 provides additional information and
references to aid users of ISO/IEC 15026-
3:2011. IEEE Std. 1228-1994 Standard for
ISO/IEC 15026-3:2011 does not require Software Safety Plans
the use of the assurance cases described by
ISO/IEC 15026-2 but describes how The minimum acceptable requirements
integrity levels and assurance cases can work for the content of a software safety plan
together, especially in the definition of are established. This standard applies to
specifications for integrity levels or by using the software safety plan used for the
integrity levels within a portion of an
assurance case. development, procurement,
maintenance, and retirement of safety-
critical software.
The final part of 15026 provides
This standard requires that the plan be
additional guidance for executing the life
prepared within the context of the
cycle processes of 12207 and 15288 when a
system safety program. Only the safety
system or software is required to achieve an
aspects of the software are included.
important property.
This standard does not contain special
provisions required for software used in
distributed systems or in parallel
ISO/IEC 15026-4:2012 Systems and Software
processors.
EngineeringSystems and Software Assurance
Part 4: Assurance in the Life Cycle
This part of ISO/IEC 15026 gives guidance

Classical treatments suggest that
and recommendations for conducting
verification deals with static
selected processes, activities and tasks for
evaluation methods and that testing
systems and software products requiring deals with dynamic evaluation methods.
assurance claims for properties selected for Recent treatments, including ISO/IEC
special attention, called critical properties. draft 29119, are blurring this distinction,
This part of ISO/IEC 15026 specifies a though, so testing standards are
property-independent list of processes, mentioned here.
activities, and tasks to achieve the claim and
show the achievement of the claim. This part
of ISO/IEC 15026 establishes the processes,
activities, tasks, guidance, and and System Test Documentation
recommendations in the context of a defined
See Software Testing KA
life cycle model and set of life cycle
processes for system and/or software life IEEE Std. 1008-1987 Standard for
cycle management. Software Unit
Testing
The next standard deals with a property

safetythat is often identified as critical. It
IEEE Std. 26513-2010 Standard Adoption of certifying software engineering

ISO/ IEC 26513:2009 Systems and Software professionals. A certification scheme is a
EngineeringRequirements for Testers and set of certification requirements for
Reviewers of software engineering professionals.
Documentation ISO/IEC 24773:2008 specifies the items
See Software Testing KA that a scheme is required to contain and
indicates what should be defined for
ISO/IEC/IEEE 29119 [four parts] (Draft) each item.
Software and Systems EngineeringSoftware
ISO/IEC 24773:2008 will facilitate the
Testing
portability of software engineering
professional certifications between
different countries or organizations. At
present, different countries and
organizations have adopted different
PROFESSIONAL PRACTICE
approaches on the topic, which are
IEEE is a provider of products related to the implemented by means of regulations
certification of professional practitioners of and bylaws. The intention of ISO/ IEC
software engineering. The first has already 24773:2008 is to be open to these
been described, the Guide to the Software individual approaches by providing a
Engineering Body ofKnowledge. The framework for expressing them in a
SWEBOK Guide has been adopted by common scheme that can lead to
ISO/IEC as an outline of the knowledge that understanding.
professional software engineers should have.
SC 7 is currently drafting a guide that

will supplement 24773.
ISO/IEC TR 19759:2005 Software Engineering
Guide to the Software Engineering Body of
Knowledge (SWEBOK)
ECONOMICS
See General
No standards are allocated to this KA.
COMPUTING FOUNDATIONS
An SC 7 standard provides a framework
for comparisons among certifications of No standards are allocated to this KA.
software engineering professionals. That
standard states that the areas considered in MATHEMATICAL FOUNDATIONS
certification must be mapped to the
SWEBOK Guide. No standards are allocated to this KA.
ENGINEERING FOUNDATIONS
ISO/IEC 24773:2008 Software Engineering No standards are allocated to this KA.

Certification of Software Engineering
Professionals STAYING CURRENT
ISO/IEC 24773:2008 establishes a This article was obsolescent the moment

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

Number and Title (listed in order of number) Most Relevant KA
IEEE Std. 730-2002 Standard for Software Quality Assurance Plans SW Quality
IEEE Std. 828-2012 Standard for Configuration Management in SW Configuration
Systems and Software Engineering Management
IEEE Std. 829-2008 Standard for Software and System Test
SW Testing
Documentation
IEEE Std. 982.1-2005 Standard for Dictionary of Measures of the
SW Quality
Software Aspects of Dependability
IEEE Std. 1008-1987 Standard for Software Unit Testing SW Testing
IEEE Std. 1012-2012 Standard for System and Software Verification and
SW Quality
Validation
IEEE Std. 1016-2009 Standard for Information TechnologySystems
SW Design
DesignSoftware Design Descriptions
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

SW Quality
Methodology
SW Engineering
IEEE Std. 1062-1998 Recommended Practice for Software Acquisition
Management
IEEE Std. 1074-2006 Standard for Developing a Software Project Life SW Engineering
Cycle Process Process
IEEE Std. 1175.1-2002 Guide for CASE Tool Interconnections SW Engineering
Classification and Description Models and Methods
IEEE Std. 1175.2-2006 Recommended Practice for CASE Tool SW Engineering
InterconnectionCharacterization of Interconnections Models and Methods
IEEE Std. 1175.3-2004 Standard for CASE Tool Interconnections SW Engineering
Reference Model for Specifying Software Behavior Models and Methods
IEEE Std. 1175.4-2008 Standard for CASE Tool Interconnections SW Engineering
Reference Model for Specifying System Behavior Models and Methods
IEEE Std. 1220-2005 (a.k.a. ISO/IEC 26702:2007) Standard for SW Engineering
Application and Management of the Systems Engineering Process Process
IEEE Std. 1228-1994 Standard for Software Safety Plans SW Quality
IEEE Std. 1320.1-1998 Standard for Functional Modeling Language SW Engineering
Syntax and Semantics for IDEF0 Models and Methods
IEEE Std. 1320.2-1998 Standard for Conceptual Modeling Language SW Engineering
Syntax and Semantics for IDEF1X97 (IDEFobject) Models and Methods
IEEE Std. 1490-2011 GuideAdoption of the Project Management

SW Engineering
Institute (PMI) Standard, A Guide to the Project Management Body of
Management
Knowledge (PMBOK Guide)Fourth Edition
IEEE Std. 1517-2010 Standard for Information TechnologySystem SW Engineering
and Software Life Cycle ProcessesReuse Processes Process

IEEE Std. 1633-2008 Recommended Practice for Software Reliability SW Quality
Systems and Software EngineeringSoftware Life Cycle Processes Process
IEEE Std. 14102-2010 Standard Adoption of ISO/IEC 14102:2008
SW Engineering
Information TechnologyGuideline for the Evaluation and Selection of
Models and Methods
CASE Tools
ISO/IEC 14143 [six parts] Information TechnologySoftware
SW Requirements
MeasurementFunctional Size Measurement
IEEE Std. 14471-2010 GuideAdoption of ISO/IEC TR 14471:2007
SW Engineering
Information TechnologySoftware EngineeringGuidelines for the
Models and Methods
Adoption of CASE Tools
IEEE Std. 14764-2006 (a.k.a. ISO/IEC 14764:2006) Standard for
SW Maintenance
Software EngineeringSoftware Life Cycle ProcessesMaintenance
IEEE Std. 15026.1-2011 Trial-Use Standard Adoption of ISO/IEC
TR 15026-1:2010 Systems and Software EngineeringSystems and SW Quality
Software AssurancePart 1: Concepts and Vocabulary
IEEE Std. 15026.2-2011 Standard Adoption of ISO/IEC 150262:2011
Systems and Software EngineeringSystems and Software SW Quality
AssurancePart 2: Assurance Case
ISO/IEC 15026-3 Systems and Software EngineeringSystems and
SW Quality
Software AssurancePart 3: System Integrity Levels
ISO/IEC 15026-4:2012 Systems and Software EngineeringSystems
SW Quality
and Software AssurancePart 4: Assurance in the Life Cycle
Systems and Software EngineeringSystem Life Cycle Processes Process
ISO/IEC/IEEE 15289:2011 Systems and Software Engineering SW Engineering
Content of Life-Cycle Information Products (Documentation) Process
ISO/IEC 15504 [ten parts] Information TechnologyProcess SW Engineering
Assessment Process
IEEE Std. 15939-2008 Standard Adoption of ISO/IEC 15939:2007 SW Engineering
Systems and Software EngineeringMeasurement Process Management
ISO/IEC 15940:2006 Information TechnologySoftware Engineering SW Engineering
Environment Services Models and Methods
IEEE Std. 16085-2006 (a.k.a. ISO/IEC 16085:2006) Standard for

SW Engineering
Systems and Software EngineeringSoftware Life Cycle Processes
Management
Risk Management
ISO/IEC/IEEE 16326:2009 Systems and Software EngineeringLife SW Engineering
Cycle ProcessesProject Management Management
ISO/IEC 19501:2005 Information TechnologyOpen Distributed SW Engineering
ProcessingUnified Modeling Language (UML) Version 1.4.2 Models and Methods

ISO/IEC 19505:2012 [two parts] Information TechnologyObject SW Engineering
Management Group Unified Modeling Language (OMG UML) Models and Methods
ISO/IEC 19506:2012 Information TechnologyObject Management
SW Engineering
Group Architecture-Driven Modernization (ADM)Knowledge
Models and Methods
Discovery Meta-Model (KDM)
ISO/IEC 19507:2012 Information TechnologyObject Management SW Engineering
Group Object Constraint Language (OCL) Models and Methods
ISO/IEC TR 19759:2005 Software EngineeringGuide to the Software
[General]
Engineering Body of Knowledge (SWEBOK)
ISO/IEC 19761:2011 Software EngineeringCOSMIC: A Functional
SW Requirements
Size Measurement Method
ISO/IEC 20000-1:2011 Information TechnologyService SW Engineering
ManagementPart 1: Service management system requirements Process
ISO/IEC 20926:2009 Software and Systems EngineeringSoftware
SW Requirements
MeasurementIFPUG Functional Size Measurement Method
ISO/IEC 20968:2002 Software EngineeringMk II Function Point
SW Requirements
AnalysisCounting Practices Manual
ISO/IEC 24570:2005 Software EngineeringNESMA Functional
Size Measurement Method Version 2.1Definitions and Counting SW Requirements
Guidelines for the Application of Function Point Analysis
IEEE Std. 24748.1-2011 GuideAdoption of ISO/IEC TR 24748-
1:2010 Systems and Software EngineeringLife Cycle Management SW Engineering
Part 1: Process
Guide for Life Cycle Management
IEEE Std. 24748.2-2012 GuideAdoption of ISO/IEC TR 24748-
2:2011
SW Engineering
Systems and Software EngineeringLife Cycle ManagementPart
Process
2: Guide to the Application of ISO/IEC 15288 (System Life Cycle
Processes)
IEEE Std. 24748-3:2012 GuideAdoption of ISO/IEC TR 24748-

3:2011
SW Engineering
Systems and Software EngineeringLife Cycle ManagementPart
Process
3: Guide to the Application of ISO/IEC 12207 (Software Life Cycle
Processes)
ISO/IEC/IEEE 24765:2010 Systems and Software
[General]
EngineeringVocabulary
ISO/IEC TR 24772:2013 Information technologyProgramming
Languages Guidance to Avoiding Vulnerabilities in Programming SW Construction
Languages through Language Selection and Use
ISO/IEC 24773:2008 Software EngineeringCertification of Software SW Engineering
Engineering Professionals Professional Practice
IEEE Std. 24774:2012 GuideAdoption of ISO/IEC TR 24474:2010
SW Engineering
Systems and Software EngineeringLife Cycle Management
Process
Guidelines for Process Description
ISO/IEC 25000:2005 Software EngineeringSoftware Product Quality
SW Quality
Requirements and Evaluation (SQuaRE)Guide to SQuaRE

ISO/IEC 25000 through 25099 Software EngineeringSoftware
SW Quality
Product Quality Requirements and Evaluation (SQuaRE)
ISO/IEC 25010:2011 Systems and Software EngineeringSystems and
Software Quality Requirements and Evaluation (SQuaRE)System and SW Quality
Software Quality Models
ISO/IEC 25060 through 25064 Software EngineeringSoftware
Product Quality Requirements and Evaluation (SQuaRE)Common SW Quality
Industry Format (CIF) for Usability
Requirements for Managers of User Documentation Management
Requirements for Acquirers and Suppliers of User Documentation Management
Systems and Software EngineeringRequirements for Testers and SW Testing
Reviewers of Documentation
Systems and Software EngineeringRequirements for Designers and SW Design
Developers of User Documentation
Developing User Documentation in an Agile Environment Models and Methods
ISO/IEC 29110 [several parts] Software EngineeringLifecycle SW Engineering
Profiles for Very Small Entities (VSE) Process
ISO/IEC/IEEE 29119 [four parts] (Draft) Software and Systems

SW Testing
EngineeringSoftware Testing
ISO/IEC/IEEE 29148:2011 Systems and Software EngineeringLife
SW Requirements
Cycle ProcessesRequirements Engineering
ISO/IEC/IEEE 42010:2011 Systems and Software Engineering
SW Design
Architecture Description
IEEE Std. 90003:2008 GuideAdoption of ISO/IEC 90003:2004
Software EngineeringGuidelines for the Application of ISO SW Quality
9001:2000 to Computer Software
APPENDIX C CONSOLIDATED
REFERENCE LIST
The Consolidated Reference List Succinct: As short as possible

identifies all recommended (both in number of reference
reference materials (to the level of items and in total page count)
section number) that accompany without failing other objectives.
the breakdown of topics within
each knowledge area (KA). This [1*] J.H. Allen et al., Software
Consolidated Reference List is SecurityEngineering:AGuide
adopted by the software forProjectManagers, Addison-
engineering certification and Wesley, 2008.
associated professional
development products offered by [2*] M. Bishop, Computer
the IEEE Computer Society. KA Security:ArtandScience,
Editors used the references Addison-Wesley, 2002.
allocated to their KA by the
Consolidated Reference List as [3*] B. Boehm and R. Turner,
BalancingAgilityand
their Recommended References.
Discipline:AGuideforthe
Collectively this Consolidated
Perplexed, Addison-Wesley,
Reference List is
2003.
[4*] F. Bott et al., Professional
Complete: Covering the entire
IssuesinSoftwareEngineering,
scope of the SWEBOK Guide.
3rd ed., Taylor & Francis, 2000.
Sufficient: Providing enough
information to describe
[5*] J.G. Brookshear, Computer
generally accepted
Science:AnOverview, 10th
knowledge.
Consistent: Not providing
contradictory knowledge nor [6*] D. Budgen, SoftwareDesign,
conflicting practices. 2nd ed., Addison-Wesley, 2003.
Credible: Recognized as
providing expert treatment. [7*] E.W. Cheney and D.R. Kincaid,
Current: Treating the subject in NumericalMathematicsand
a manner that is commensurate Computing, 6th ed.,
with currently generally Brooks/Cole, 2007.
accepted knowledge.
[8*] P. Clements et al., [15*] IEEE CS/ACM Joint Task
DocumentingSoftware Force on
Architectures:Viewsand Software Engineering Ethics
Beyond, 2nd ed., Pearson and
Education, 2010. Professional Practices,
Software
[9*] R.E. Fairley, Managingand Engineering Code of Ethics and
LeadingSoftwareProjects, Professional Practice (Version
Wiley-IEEE Computer Society 5.2), 1999;
Press, 2009. www.acm.org/serving/se/code.h
tm.
[10*] D. Galin, SoftwareQuality
Assurance:FromTheoryto [16*] IEEEStd.828-2012,
Implementation, Pearson Standardfor
Education Limited, 2004. ConfigurationManagementin
SystemsandSoftware
[11*] E. Gamma et al., Design Engineering, IEEE, 2012.
Patterns:
ElementsofReusableObject- [17*] IEEEStd.1028-2008,
OrientedSoftware, 1st ed., SoftwareReviewsandAudits,
Addison-Wesley Professional, IEEE, 2008.
1994.
[18*] ISO/IEC14764IEEEStd.
[12*] P. Grubb and A.A. Takang, 14764-2006,
SoftwareMaintenance: SoftwareEngineering
ConceptsandPractice, 2nd ed., SoftwareLifeCycleProcesses
World Scientific Publishing, Maintenance, IEEE, 2006.
2003.
[19*] S.H. Kan, Metricsand
[13*] A.M.J. Hass, Configuration ModelsinSoftwareQuality
ManagementPrinciplesand Engineering, 2nd ed.,
Practices, 1st ed., AddisonWesley, 2002.
C-
1
AddisonWesley, 2003. [20*] S. McConnell, Code
Complete, 2nd ed., Microsoft
C-2 SWEBOK Guide V3.0 Press, 2004.
[21*] J. McGarry et al.,

[14*] E. Horowitz et al., Computer PracticalSoftware
Algorithms, 2nd ed., Silicon Measurement:Objective
Press, 2007. InformationforDecision
Makers, Addison-Wesley
Professional, 2001.
[22*] S.J. Mellor and M.J. Balcer, [29*] K. Rosen, Discrete
Executable Mathematics and Its
UML:AFoundationfor Applications, 7th ed., McGraw-
Model-DrivenArchitecture, 1st Hill, 2011.
[30*] A. Silberschatz, P.B. Galvin,
[23*] D.C. Montgomery and G.C. and G. Gagne, Operating
Runger, AppliedStatisticsand SystemConcepts, 8th ed.,
ProbabilityforEngineers, 4th Wiley, 2008.
ed., Wiley, 2007.
[31*] H.M. Sneed, Offering
[24*] J.W. Moore, TheRoadMap Software
toSoftwareEngineering:A Maintenance as an Offshore
Standards-BasedGuide, 1st ed., Service, Proc.IEEEIntl
Wiley-IEEE Computer Society Conf.SoftwareMaintenance
Press, 2006. (ICSM 08), IEEE, 2008, pp. 1
5.
[25*] S. Naik and P. Tripathy,
SoftwareTestingandQuality [32*] I. Sommerville, Software
Assurance:Theoryand Engineering, 9th ed., Addison-
Practice, Wiley-Spektrum, Wesley, 2011.
2008.
[33*] S. Tockey, Returnon
[26*] J. Nielsen, Usability Software:Maximizingthe
Engineering, 1st ed., Morgan ReturnonYourSoftware
Kaufmann, 1993. Investment, 1st ed., Addison-
Wesley, 2004.
[27*] L. Null and J. Lobur, The
Essentialsof [34*] G. Voland, Engineeringby
ComputerOrganizationand Design, 2nd ed., Prentice Hall,
Architecture, 2003.
2nd ed., Jones and Bartlett
Publishers, 2006. [35*] K.E. Wiegers, Software
Requirements, 2nd ed.,
[28*] M. Page-Jones, Microsoft Press, 2003.
Fundamentalsof
ObjectOrientedDesigninUML, [36*] J.M. Wing, A Specifiers
1st ed., AddisonWesley, 1999. Introduction to Formal
Methods, Computer, vol. 23,
no. 9, 1990, pp. 8, 1023.

SWEBOKv 3

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

SWEBOKv 3

Hochgeladen von

Copyright:

Verfügbare Formate

Appendix B

A Project of the IEEE Computer Society

Copyright 2014 IEEE. All rights reserved.

IEEE Computer Society Staff for This Publication

Foreword to the 2004 Edition xix

Contributing Editors xxi

Change Control Board xxi

Knowledge Area Editors of Previous SWEBOK Versions xxv

Review Team xxvii

Professional Activities Board, 2013 Membership xxix

Motions Regarding the Approval of SWEBOK Guide V3.0 xxx

Motions Regarding the Approval of SWEBOK Guide 2004 Version xxx

Introduction to the Guide xxxi

Chapter 1: Software Requirements 1-1

1.Software Requirements Fundamentals 1-1

1.1. DefinitionofaSoftwareRequirement 1-1

1.2. ProductandProcessRequirements 1-2

1.3. FunctionalandNonfunctionalRequirements 1-3

1.4. EmergentProperties 1-3

1.5. QuantifiableRequirements 1-3

1.6. SystemRequirementsandSoftwareRequirements 1-3

2.Requirements Process 1-3

2.1. ProcessModels 1-4

2.2. ProcessActors 1-4

2.3. ProcessSupportandManagement 1-4

2.4. ProcessQualityandImprovement 1-4

3.Requirements Elicitation 1-5

3.1. RequirementsSources 1-5

3.2. ElicitationTechniques 1-6

4.Requirements Analysis 1-7

4.1. RequirementsClassification 1-7

4.2. ConceptualModeling 1-8

4.3. ArchitecturalDesignandRequirementsAllocation 1-9

4.4. RequirementsNegotiation 1-9

5.Requirements Specification 1-10

5.1. SystemDefinitionDocument 1-10

5.2. SystemRequirementsSpecification 1-10

5.3. SoftwareRequirementsSpecification 1-11

6.Requirements Validation 1-11

6.1. RequirementsReviews 1-11

6.2. Prototyping 1-12

SWEBOK Guide V3.0

Matrix of Topics vs. Reference Material 2-12

Chapter 4: Software Testing 4-

5. Software Maintenance Tools 5-11

4. Review and Evaluation 7-8

CHANGE CONTROL BOARD

Software Configuration Management

Software Engineering Management

Software Engineering Process

Software Engineering Models and Methods

Software Engineering Professional Practice

Software Engineering Economics

Appendix B: IEEE and ISO/IEC Standards Supporting SWEBOK

Software Configuration Management

Software Engineering Management

Software Engineering Process

Software Engineering Tools and Methods

SWEBOK Guide V3.0

collected and duly adjudicated. Ann M. Eblen, Australia

IEEE COMPUTER SOCIETY PRESIDENTS

PROFESSIONAL ACTIVITIES BOARD,

MOTIONS REGARDING THE APPROVAL OF

[5, c29-web] [17, Commandlanguage. The user issues a

[5] I. Sommerville, SoftwareEngineering, 9th [15] E. Gamma et al., DesignPatterns:

[1, c8s11, c13s3] [1, c8s8]