1 CHAPTER 4 2 SOFTWARE CONSTRUCTION 3 46 Since software construction heavily involves the use of 4 ACRONYMS 47 knowledge of algorithms and of detailed coding 48 practices, it is closely related to the Computing OMG Object Management Group 49 Foundations KA, which is concerned with the UML Unified Modeling Language 50 computer science foundations that support the design 51 and construction of software products. It is also related 5 INTRODUCTION 52 to project management, insofar as the management of 53 construction can present considerable challenges. 6 The term software construction refers to the detailed 7 creation of working, meaningful software through a 54 BREAKDOWN OF TOPICS FOR SOFTWARE 8 combination of coding, verification, unit testing, 9 integration testing, and debugging. 55 CONSTRUCTION 10 56 The breakdown of the Software Construction KA is 11 The Software Construction Knowledge Area is linked 57 presented below, together with brief descriptions of the 12 to all the other KAs, but is most strongly linked to 58 major topics associated with it. Appropriate references 13 Software Design and Software Testing because the 59 are also given for each of the topics. Figure 1 gives a 14 software construction process, itself, involves 60 graphical representation of the top-level decomposition 15 significant software design and test activity. The 61 of the breakdown for this KA. 16 process also uses the design output and provides an 62 1. Software Construction Fundamentals 17 input to testing (“design” and “testing” in this case 18 referring to the activities, not the KAs). Detailed 63 Software construction fundamentals include: 19 boundaries between design, construction, and testing (if 64 20 any) will vary depending upon the software life cycle 65 Minimizing complexity 21 processes that are used in a project. 66 Anticipating change 22 67 Constructing for verification 23 Although some detailed design may be performed prior 68 Reuse 24 to construction, much design work is performed within 25 the construction activity itself. Thus, the Software 69 Standards in construction 26 Construction KA is closely linked to the Software 70 27 Design KA. 71 The first four concepts apply to design as well as to 28 72 construction. The following sections define these 29 Throughout construction, software engineers both unit- 73 concepts and describe how they apply to construction. 30 test and integration-test their work. Thus, the Software 74 31 Construction KA is closely linked to the Software 75 1.1. Minimizing Complexity 32 Testing KA as well. 76 [3] 33 77 34 Software construction typically produces the highest 78 Most people are severely limited in their ability to hold 35 volume of configuration items that need to be managed 79 complex structures and information in their working 36 in a software project (source files, content, test cases, 80 memories, especially over long periods of time. This 37 and so on). Thus, the Software Construction KA is also 81 proves to be a major factor influencing how people 38 closely linked to the Software Configuration 82 convey intent to computers and leads to one of the 39 Management KA. 83 strongest drives in software construction: minimizing 40 84 complexity. The need to reduce complexity applies to 41 While software quality is important in all the KAs, 85 essentially every aspect of software construction and is 42 code is the ultimate deliverable of a software project, 86 particularly critical to the process of verification and 43 and thus the Software Quality KA is also closely linked 87 testing of software constructions. 44 to the Software Construction KA. 88 45 89 © IEEE – SWEBOK Guide V3 4–1 90 91 Figure 1. Breakdown of Topics for Software Construction 92 4–2 © IEEE – SWEBOK Guide V3 93 In software construction, reduced complexity is 147 latter means to reuse software assets in the construction 94 achieved through emphasizing code creation that is 148 of a new solution. Reuse often transcends the boundary 95 simple and readable rather than clever. It is 149 of projects, which means reused assets can be 96 accomplished through making use of standards (see 150 constructed in other projects or organizations. 97 1.5), modular design (see 3.1), and numerous other 151 98 specific techniques (see 3.3). It is also supported by the 152 1.4. Standards in Construction 99 construction-focused quality techniques summarized in 153 [3] 100 3.7. 154 101 1.1. Anticipating Change 155 Applying external or internal development standards 102 [3] 156 during construction helps achieve the project’s 103 157 objectives for development efficiency, quality, and cost. 104 Most software will change over time, and the 158 Specifically, the choices of allowable programming 105 anticipation of change drives many aspects of software 159 language subsets and usage standards are important 106 construction. Software is unavoidably a part of 160 aids in achieving higher security. 107 changing external environments; changes in those 161 108 outside environments affect software in diverse ways. 162 Standards that directly affect construction issues 109 163 include: 110 Anticipating change helps engineers build extensible 164 111 software, which means that they can enhance a 165 Communication methods (for example, standards 112 software product without causing violence to the 166 for document formats and contents) 113 underlying structure. 167 Programming languages (for example, language 114 168 standards for languages like Java and C++) 115 Anticipating change is supported by many specific 169 Platforms (for example, programmer interface 116 techniques, which are summarized in 3.3. 170 standards for operating system calls) 117 171 Tools (for example, diagrammatic standards for 118 1.2. Constructing for Verification 172 notations like UML (Unified Modeling Language)) 119 [3] 173 Use of external standards. Construction depends on the 120 174 use of external standards for construction languages, 121 Constructing for verification means building software 175 construction tools, technical interfaces, and interactions 122 in such a way that faults can be ferreted out readily by 176 between the Software Construction KA and other KAs. 123 the software engineers writing the software as well as 177 Standards come from numerous sources, including 124 testers and users during independent testing and 178 hardware and software interface specifications (such as 125 operational activities. Specific techniques that support 179 the Object Management Group (OMG)) and 126 constructing for verification include following coding 180 international organizations (such as the IEEE or ISO). 127 standards to support code reviews, unit testing, 128 organizing code to support automated testing, and 181 Use of internal standards. Standards may also be 129 restricting the use of complex or hard-to-understand 182 created on an organizational basis at the corporate level 130 language structures, among others. 183 or for use on specific projects. These standards support 131 184 coordination of group activities, minimizing 185 complexity, anticipating change, and constructing for 132 1.3. Reuse 186 verification. 133 [7] 134 187 2. Managing Construction 135 Reuse refers to using an asset in solving different 188 136 problems. In software construction, typical assets that 189 2.1. Construction in Life Cycle Models 137 are reused include libraries, modules, components, 190 [3] 138 source code, and commercial off-the-shelf (COTS) 139 assets. Reuse should be practiced systematically, 191 140 according to a well-defined, repeatable process. 192 Numerous models have been created to develop 141 Systematic reuse can enable significant software 193 software; some emphasize construction more than 142 productivity, quality, and cost improvements. 194 others. 143 195 144 Reuse has two closely related facets: "construction for 196 Some models are more linear from the construction 145 reuse" and "construction with reuse." The former 197 point of view—such as the waterfall and staged- 146 means to create reusable software assets, while the 198 delivery life cycle models. These models treat © IEEE – SWEBOK Guide V3 4–3 199 construction as an activity that occurs only after 254 code reused, code destroyed, code complexity, code 200 significant prerequisite work has been completed— 255 inspection statistics, fault-fix and fault-find rates, effort, 201 including detailed requirements work, extensive design 256 and scheduling. These measurements can be useful for 202 work, and detailed planning. The more linear 257 purposes of managing construction, ensuring quality 203 approaches tend to emphasize the activities that 258 during construction, and improving the construction 204 precede construction (requirements and design) and to 259 process, as well as for other reasons. See the Software 205 create more distinct separations between activities. In 260 Engineering Process KA for more on measurements. 206 these models, the main emphasis of construction may 207 be coding. 261 3. Practical Considerations 208 262 Construction is an activity in which the software has to 209 Other models are more iterative—such as evolutionary 263 come to terms with arbitrary and chaotic real-world 210 prototyping, Extreme Programming, and Scrum. These 264 constraints, and it must do so exactly. Due to its 211 approaches tend to treat construction as an activity that 265 proximity to real-world constraints, construction is 212 occurs concurrently with other software development 266 more driven by practical