Index

Note: Bold page numbers refer to tables; italic page numbers refer to figures.

• abstract factory 187

• accreditation board for engineering and technology (ABET) 5, 239, 250–251

• accreditation criteria 5

• adapter 187

• agile processes 29–30

• alpha testing 79

• analyst, software 8–9

• appraisal cost 57

• architect, software 9

• architecture, software design

  • allocation view 164

  • client-server style 168, 168–169

  • code view 166

  • component and connector (C&C) view 164

  • conceptual view 165

  • definitions 160

  • deployment view 163

  • development view 164

  • documenting decisions 161

  • entities referred 160

  • execution view 166

  • importance 159–160

  • Krutchen’s view 163–164

  • layered style 169, 169

  • logical view 163

  • 4+1’s logical view 165–166

  • module view 164, 166

  • physical view 163

  • pipe and filter style 167–168

  • process view 163

  • quality attributes 160–161

  • SEI views 164, 165

  • service-oriented style 170, 170

  • Siemens four-views approach 165–166

  • and stakeholders 162

  • styles of 167–170

  • use cases view 164

  • views 161–166

• association for computing machinery (ACM) 5, 242

• backlog

  • buffer 262

  • epics 261

  • estimation techniques 264–265

  • items 261

  • refinement/grooming 263

  • sprint backlog 261–262

  • stories 261

  • tasks 261

  • themes 261

• beta testing 79

• black box techniques, unit testing 75

• Boehm, B. 29, 31

• Booch, G. 181

• bridge 187

• British computer society (BCS) 239

• Brooks, F. P. 4, 5, 124

• Brooks, J. 238

• builder 187

• burnup chart 271

• business risks 106

• Canadian engineering accreditation board (CEAB) 239

• capability maturity model (CMM) 34, 34

• capability maturity model integration (CMMI) 6, 34, 34

• case study

  • appropriate set of views selection, DH 192

  • architectural style selection, DH 192–193

  • architecture development, DH 193–194

  • assessing customer needs 20–21

  • code review 84–85

  • configuration identification 115, 119–120

  • configuration management 115–116, 120

  • cost of quality experiences 80–81

  • design concepts and principles 191

  • design patterns application 197–198

  • design quality measurement 194–196

  • development strategy, DH 46–47

  • documenting, software design 198–199

  • effective team formation 45

  • eliciting requirements, DH 144–145

  • ethical issues, DH 251–253

  • evaluating a software process 45–46

  • goal/question/metric, DH 82–83

  • integration test planning 86–87

  • legal issues, DH 254

  • maintenance costs estimation, DH 233–234

  • maintenance process determination, DH 233

  • potential maintenance problems identification, DH 231–232

  • quality attribute specification 143–144

  • quality measurement strategy, DH 82

  • quality planning 116, 120–121

  • re-engineering effort, DH 234–235

  • requirements inspection 83–84

  • risk assessment 109, 118–119

  • security attacks 79–80

  • security requirements 148–149

  • software quality assurance planning 81–82

  • standards determination, DH 253–254

  • task plan and schedule 105, 117–118

  • team member hire, DH 250

  • team problems 17–20

  • unit test planning 85–86

  • use case modeling, DH 146–147

  • use case test planning 77–78, 88–89

  • writing software requirements 147–148

• certified software development professional (CSDP) 6, 241

• chain of responsibility 188

• changeability 5

• Chidamber and Kemerer metrics 182–184

• Chidamber, S. R. 182

• client groups 3

• client-server architectural style 168, 168–169

• COCOMO see constructive cost model (COCOMO)

• code restructuring 230–231

• code review 72, 84–85, 212, 213–214

• coding standards 37, 211–212

• collective ownership, extreme programming 37

• competitor 2

• complexity 5

• composite 187

• computer emergency response team (CERT) 214

• concept of operations (ConOps) document 16–17

• configuration management see software configuration management (SCM)

• conformity 5

• construction principles

  • buffer overflow problem 219–220

  • build/integration plan 201–205, 216

  • code review 212, 213–214

  • coding standards 211–212

  • computer emergency response team (CERT) 214

  • design diagram, DH 205

  • development process script 202–204, 218–219

  • fundamentals 206–208

  • GCD pseudocode 210–211

  • java code conventions 211–212

  • post-condition 209, 217

  • pre-condition 208, 217

  • pseudocode 209–211

  • secure coding 215

  • specification 208, 216, 217

  • test-driven development (TDD) 209

  • test plan/report 210, 218

  • unified process 35

  • unit testing 209

• constructive cost model (COCOMO) 100–101

• content coupling modules 158

• continuous integration, extreme programming 37

• controlled centralized decision 27

• controlled decentralized decision 28

• copyrights 248

• cost of quality 57–58, 80–81

• critical-path method (CPM) 102–103

• curriculum, software engineering programs criteria 240

• customer need assessment 17, 20–21

• customer satisfaction, quality metrics 65

• daily scrum 38

• data coupled modules 158

• decorator 187

• defect tracking 60–61

• defects, software engineering 4

• Delphi software estimation method 98–99

• DeMarco, T. 182

• democratic decentralized decision 27

• design, concepts and principles; see also object-oriented design

  • abstraction 155

  • assuring design quality 181–182

  • cohesion 157

  • component and module 153

  • coupling 158

  • definition 153

  • design documentation 189–190

  • design verification 181–184

  • encapsulation 155, 156

  • information hiding 157

  • modularity 153, 154

  • object-oriented design 171–181

  • phases, DH 152

  • quality assurance 181–184 (see also software quality assurance (SQA))

  • security 158–159

  • software architecture (see architecture, software design)

• design restructuring 230

• development team 8–10

• DigitalHome (DH) system

  • appropriate set of views selection 192

  • architectural style selection 192–193

  • architecture development 193–194

  • business rules 297

  • change history 287–288

  • communication center 14

  • concept of operations 16–17

  • configuration identification 115, 119–120

  • configuration management 115–116, 120

  • cost of quality experiences 80–81

  • customer need assessment 17

  • customer need statement 13, 283–286

  • design concepts and principles 191

  • design patterns application 197–198

  • design quality measurement 194–196

  • development constraints 291

  • development process script 40–42

  • development strategy 42–44, 46–47

  • discussion, debate and decisions 2–3

  • documenting, software design 198–199, 298

  • eliciting requirements 132, 144–145

  • functional requirements 293–296

  • general requirements 293

  • GQM technique evaluation 82–83

  • high-level requirements definition 13–14

  • humidistat requirements 15, 294–295

  • maintenance costs estimation 233–234

  • maintenance process determination 233

  • maintenance requirements 297

  • management requirements 295

  • master control device 14

  • needs assessment 12–13

  • non-functional requirements 296–298

  • operational environment 292–293

  • performance requirements 296

  • planner, parameters set 15–16, 295–296

  • product description and scope 290

  • programmable power switch 15

  • project team 10–13

  • prototype features 14–16

  • quality attribute specification 143–144

  • quality measurement strategy 82

  • quality planning 116, 120–121

  • re-engineering effort 234–235

  • reliability 296

  • risk assessment 109, 118–119

  • safety requirements 297

  • security engineering 79–80

  • security requirements 148–149, 295, 297

  • security system 14

  • sensors 14

  • smart features 1–2

  • software quality assurance plan 81–82

  • specification, requirements 148–149, 289–298

  • task plan and schedule 105, 117–118

  • team project information 289–290

  • thermostat requirements 14–15, 294

  • trend presentation 2

  • use case modeling 132–136, 146–147

  • users description 290–291

  • writing software requirements 147–148

• documentation

  • architecture document uses 161

  • concept of operations (ConOps) 16–17

  • description standards 189–190

  • design 180, 189–190

  • multiple viewpoint 189

  • object-based architectural design 179

• dynamic evaluation 66

• earned value tracking 103–104

• ease of use, quality metrics 65

• elaboration, unified process 35

• Institute of Electrical and Electronics Engineers Computer Society (IEEE-CS) 5, 242

• eliciting requirements

  • apprenticing 130

  • interviews 130

  • observation 130–131

  • prototyping 131

  • storyboarding 131

  • use case 131

• endurance test 77

• engineering accreditation commission (EAC) 239

• ethics; see also professionalism

  • IEEE Code 244

  • importance 243

  • SE code 244–245

• European network for accreditation of engineering education 239

• evaluation 39, 45–46, 66, 82–83

• expert judgment method 98

• extreme programming (XP) 35–37

• façade 187

• faculty, software engineering programs criteria 240

• Fagan inspection process

  • follow-up activity 71

  • formal meeting 71

  • individual inspection phase 70

  • inspection analysis 71–72

  • overview phase 70

  • preparation 70

  • rework phase 71

  • work product 70

• Fagan, M. 70

• failure cost 57

• flyweight 187

• formal specification languages 140

• format

  • development strategy form 47

  • meeting preparation form 17, 20–21

• formulating plans 2–3

• forward engineering 231

• functional structure project management 95

• function point 98

• Gantt chart 102–103, 103

• GQM technique, quality assurance 61–63

• graphical notation 140

• high-level requirements definition (HLRD) 13–14

• IEEE Code Ethics 244

• IEEE computer society 242

• IEEE standard, software quality assurance process 59–60

• IEEE Std 830-1998 246

• IEEE Std 1012™-2012 247

• IEEE Std 1016™-2009 246

• IEEE Std 12207-2008 246

• IEEE Std 14764-2006 247

• impact analysis 228

• implementation languages 157

• inception, unified process 35

• incremental-model 33, 33–34

• increment releases, unified process 35

• inspection, quality assurance

  • examination factors 69

  • Fagan inspection process 70–72

  • participants, inspection meeting 70

  • requirements inspection 72, 83–84

  • vs. technical review 69–70

• integration tests 75–76, 79, 86–87

• intellectual property (IP) 248

• interpreter 188

• invisibility 5

• ISO/IEC/IEEE 24765 246

• iterator 188

• Japan accreditation board for engineering (JABEE) 239

• Kaizen 274

• Kemerer, C. F. 182

• knowledge areas (KA), SWEBOK 6–8

• Kruchten, P. 163

• Krutchen’s view architecture 163–164

• launch process, software project

  • script particulars 24

  • team member meeting 23–24

• Lawford, M. 249

• layered architectural style 169, 169

• legacy system 229

• legal issues

  • copyrights 248

  • intellectual property 248

  • liability focus 249

  • negligence harms 247, 249

  • patents 248

  • trade secret 248–249

• liability legal issues 249

• lines of code (LOC) 98

• maintenance

  • adaptive maintenance situation 223

  • analyzability 226

  • backlog management index 225

  • categories 222–223

  • changeability 226

  • code restructuring 230–231

  • corrective maintenance 222–223

  • costs 225

  • definition 222

  • design restructuring 230

  • document restructuring 230

  • forward engineering 231

  • impact analysis 228

  • inventory analysis 230

  • legacy system 229

  • measurement 225–226

  • migration 227

  • modification implementation 227

  • objective of 222

  • perfective maintenance situation 223

  • preventive maintenance situation 223

  • problem and modification analysis 226

  • process activities 226–228, 227

  • process implementation 226

  • re-engineering process 229

  • restructuring 230–231

  • retirement 227

  • reverse engineering 231

  • review/acceptance 227

  • and software evolution 222

  • stability 226

  • testability 226

  • vs. hardware maintenance 222

• market research 2

• mathematical notation 140

• McCabe, T. J. 183

• mediator 188

• memento 188

• metaphor, extreme programming 37

• metrics, quality

  • during development 63–65

  • post release 65

• milestone setting 26

• models and methods

  • capability maturity model (CMM) 34, 34

  • incremental-model 33, 33–34

  • spiral model 31, 31–32

  • V-model 32, 32–33

  • waterfall model 30, 30–31

• natural language 140

• negligence legal issues 247, 249

• object constraint language 140

• object-oriented analysis diagrams, SRS 140

• object-oriented design 171

  • aggregation relationships 172

  • association relationships 172

  • behavioral patterns 188

  • Chidamber and Kemerer metrics 182–184

  • class diagram 172–174

  • composition relationships 172, 173

  • coupling between object classes (CBO) 183

  • creational design patterns 187

  • cyclomatic complexity 183

  • define semantics 179

  • design external interfaces 179

  • design patterns 184–188

  • develop operational scenarios 179

  • documentation 179

  • establish dependencies 179

  • evaluate design 180

  • exit criteria 180

  • identify packages and classes 178

  • inheritance relationship 174, 174

  • lack of cohesion of methods (LCOM) 184

  • measure quality 182–184

  • modeling language 171

  • modules 171

  • object class 171

  • package 171

  • process script 178–180

  • response for a class (RFC) 183

  • revise design 180

  • sequence diagram 174–176, 175

  • software reuse 184–188

  • state machine diagrams 176–177

  • weighted methods per class (WMC) 182–183

• observer 188

• organizational structure project management 95–96

• pair programming, extreme programming 37

• Parnas, D. L. 249

• patents 248

• perfective maintenance situation 223

• performance test 77

• phases, software development process

  • acceptance test 42

  • analysis 40

  • architectural design 41

  • construction increment 41

  • exit criteria 42

  • inception 40

  • launch 40

  • planning 40

  • postmortem 42

  • system test 41

• pipe and filter architectural style 167–168

• plan-driven processes 29–30

• planning game, extreme programming 36

• planning manager 10

• presentation

  • guidance proposal 2

  • market trend 2

• prevention cost 57

• preventive maintenance situation 223

• pricing-to-win 99

• process metrics, quality 64–65

• product backlog, scrum process 37

• product metrics, quality 64

• professional advancement 5–6

• professionalism

  • abilities 240

  • accreditation 239–240

  • certification 241

  • code of ethics and conduct 243–245

  • components 238

  • definition of 238

  • legal issues 247–250

  • licensing 240–241

  • societies of 241–242

  • software development standards 245–247

  • software engineering programs criteria 240

• project management

  • definition 91–92

  • earned value tracking 103–104

  • functional structure type 95

  • key activities 93–94

  • matrix structure type 96

  • organizational structures 95–96

  • planned value (PV) 103–104

  • planning activities 96–97

  • project structure type 95

  • risk management 105–109

  • software estimation 97–101

  • task plan and schedule 105

  • work-breakdown-structure (WBS) 102, 102

• project metrics, quality 64

• project risks 106

• project team formation; see also team building

  • qualification and experience 10–12

  • team problems 12, 17–20

• proof of concept 3

• proxy 187

• pseudocode 209–211

• Putman, L. 101

• quality assurance see software quality assurance (SQA)

• quality attribute

  • definitions 125

  • modules 126–127

  • purpose of 126

  • reliability, DH 127

• quality manager 9

• quality metrics

  • during development 63–65

  • post release 65

• rational unified process 35

• re-engineering process 229

• refactoring, extreme programming 37

• regression test 76

• reliability, quality metrics 65

• requirements engineering

  • agreement of 124

  • analysis phase tasks 124

  • analyzing 132–137

  • characteristics 127–128

  • conceptual design 132

  • context diagram 132

  • definitions 125

  • eliciting 129–132

  • emergent requirement 125–126

  • functional vs. non-functional 125

  • interviews 130

  • prototyping 131

  • quality attribute 125–128

  • role playing 130

  • shadowing 130–131

  • specifying 137–141

  • storyboarding 131

  • use case modeling 131, 133–136

  • validating 141–143

• requirements specification 148–149, 289–298

• requirements traceability matrix (RTM) 141, 143

• retirement 227

• retrospective meeting 273–274

• risk management

  • analysis 106–108

  • exposure 106–107, 107

  • identification 106

  • planning and monitoring 109

• Royce, W. 31

• scrum development process

  • backlog items 261

  • backlog list 261–264

  • burndown chart 270, 271, 271

  • cross-functional team 256

  • daily scrum 38, 270

  • epics 261

  • estimation process 264–265

  • implementation phase 259, 266–272

  • initiation phase 258–259

  • kaizen 274

  • key roles 256–257

  • meeting types 256

  • ordering method 264–266, 265

  • planning meeting 37

  • planning poker technique 264, 265

  • principles 256

  • product backlog 37

  • product backlog item (PBI) 261

  • product owner 256–257

  • refinement/grooming, backlog 263

  • reflection phase 259–260, 272–274

  • relationship of 262

  • retrospective 273–274

  • review 37, 259–260, 272–274

  • scrum master 256–257

  • sprint and planning of 37, 266–272

  • stories 261

  • team 257

  • themes 261

  • tracking progress 270–271

  • T-shaped person 257

  • T-shirt sizing technique 264

• secure coding 56, 214, 215

• security design 56

• security engineering

  • key techniques 55–56

  • and quality assurance 55

  • security attacks 56, 79–80

• security requirements engineering 55–56

• security risk management 55

• security test 77

• security verification 56

• service-oriented architecture (SOA) 170, 170

• Siemens four-views architecture 165–166

• simple object-based architectural design(SOBAD) 178–180

• singleton 187

• small releases, extreme programming 36

• software configuration management (SCM)

  • configuration identification 113–114

  • control management 114–115

  • elements of 112–113

  • importance 110–111

• software development life cycle (SDLC) 30–34

• software engineering

  • advancement 5–6

  • changeability 5

  • complexity 5

  • component developer 10

  • conformity 5

  • defects 4

  • definition 3–4

  • development team, role 8–10

  • foundations 6

  • invisibility 5

  • knowledge areas 6–8

  • nature 4–5

  • planning manager 10

  • quality manager 9

  • software analyst 8–9

  • software architect 9

  • SWEBOK 6–8

  • team leader 8

• software engineering body of knowledge (SWEBOK)

  • maintenance of 222

  • roles and responsibilities 6–8

  • SCM process 112–113

  • software design 153

  • software engineering management 91

  • software testing 72

  • system requirements 125

• software engineering code of ethics and professional practice (SE Code) 5, 244–245

• software engineering institute (SEI) 5, 34, 38, 164–165

• software engineering process

  • agile processes 29–30

  • conceptual design 42–43, 44

  • context design 42–43, 43

  • development strategy 42–44, 46–47

  • evaluation 39, 45–46

  • extreme programming (XP) 35–37

  • fundamentals 29

  • life cycle models 30–34

  • plan-driven processes 29–30

  • scrum process 37–38, 38

  • team software process (TSP) 38–39, 39

  • unified process (UP) 35

• software estimation

  • analogy 99

  • business-driven techniques 99

  • constructive cost model (COCOMO) 100–101

  • Delphi method 98–99

  • estimating to available capacity 99

  • expert judgment method 98

  • fundamental principles 97

  • linear regression estimation 99–100, 100

  • pricing-to-win 99

  • project scheduling 102–103, 103

  • size estimates 97–98

  • software life cycle management (SLIM) 100–101

  • statistical/parametric methods 99–101

• software life cycle management (SLIM) 100–101

• software quality assurance (SQA)

  • characteristics, measurement strategy 61

  • code review 72, 84–85

  • cost and project schedule 53–54

  • cost of quality 57–58

  • cost, requirement defect removal 67

  • data analysis 59

  • defect life cycle 56

  • defect rate 53

  • development phase metrics 63–65

  • goal, question, metrics (GQM) technique 61–63, 82–83

  • IEEE standard, SQAP 59–60, 81–82

  • importance 52

  • inspection 69–72, 83–84

  • leaving defects 54

  • managers role 52–53

  • oversight activity 58

  • planning activity 58

  • post release metrics 65

  • processes associated 58–59

  • quality measurement and defect tracking 60–61

  • quality reviews 67–72

  • questions, measurement strategy 61, 82

  • record keeping 58

  • reliability 53

  • reporting data 59

  • requirements phase 53–54

  • security engineering 55–56

  • software testing 72–79

  • technical review 68–69

  • validation and verification 66

  • and V-Model SDLC 54–55

  • walk-through 68

• software quality assurance plan (SQAP) 59–60, 81–82

• software requirements specification (SRS); see also requirements engineering

  • natural language 140

  • organization 138–139

  • purpose and value 138

  • writing requirements, guidelines 139

• software & systems engineering standards committee (S2ESC) 245

• software testing

  • development tests types 73

  • importance 72

  • integration testing 75–76, 79, 86–87

  • successful test implies 73

  • system testing 76–79

  • test harness 73

  • unit testing 74–75, 79, 85–86

  • use case test planning 79, 88–89

  • vs. debugging 72

• special interest group on software engineering (SIGSOFT) 242

• spiral model 31, 31–32

• sprint, scrum process

  • backlog 267–268

  • burnup chart 271

  • capacity 269

  • goal 37

  • planning 267–270, 276–277

  • retrospective 273–274

  • review 272–273

  • scrum board 269

  • velocity 268–269

• stakeholders 162

• standards, software development

  • IEEE-CS standards 246–247

  • importance 245

• state 188

• state machine diagrams 176–177

• static evaluation 66

• strategy 188

• stress test 77

• structured hierarchical style, SRS 140

• SWEBOK see software engineering body of knowledge (SWEBOK)

• system testing 76–79, 77, 78

• task-Gantt chart 102–103, 103

• team building

  • case study 45

  • communication skills 27

  • decision-making procedure 27–28

  • development activities 28

  • effective team qualities 25, 45

  • goal setting 26

  • ineffective team qualities 25

  • problems 12, 17–20

  • roles and responsibilities 8–10, 26

  • work control 28

• team formation 3

• team leader 8

• team problems

  • case study 17–20

  • description 12

  • labor avoidance 19

  • quality issue 18

  • reporting time 19

• team software process (TSP) 38–39, 39

• technical review 68–69

• technical risks 106

• template method 188

• test-driven development (TDD) 37, 209

• trade secret 248

• traffic management system (TMS)

  • Gantt chart 103

  • modularity, design 153, 154

  • risk management 105–108

  • state machine diagrams 176–177

  • use case modeling 134, 135

  • work breakdown structure 102

• transition, unified process 35

• Turner, R. 29

• unified modeling language (UML) 133

• unified process (UP) 35

• unit testing techniques

  • anomaly analysis 75

  • case study 85–86

  • categories 74

  • definitions of 74

  • static techniques 74

  • test plan 75

• usability test 77

• use case, DH system

  • configuration 305–306

  • control DH environment 327–329

  • definition of 131

  • diagram 303

  • humidistat set plan parameters 316–318

  • login/logout 311–312

  • manual parameters set 329–330

  • modify/view, month plan 321–323

  • monitor sensor values 325–326

  • monthly planner management 312–315

  • month report preparation 323–325

  • operation state change 310

  • power switch set plan parameters 319–321

  • read sensor values 326–327

  • security set plan parameters 318–319

  • set default parameters 308–309

  • temperature set plan parameters 315–316

  • test plan 77–78, 88–89

  • user accounts management 307–308

  • users 302

• validation and verification (V&V)

  • quality assurance 66

  • software requirements activity 141–143

• visitor 188

• V-model 32, 32–33

• volume test 77

• walk-through, quality review 68

• waterfall model 30, 30–31

• white box techniques, unit testing 75

• work-breakdown-structure (WBS) 102, 102

• writing requirements

  • language requirement 139–141

  • styles used 140