Difference between revisions of "Chapter 3: Software Construction"

From SWEBOK
Jump to: navigation, search
Line 30: Line 30:
  
 
The first four concepts apply to design as well as to construction. The following sections define these concepts and describe how they apply to construction.
 
The first four concepts apply to design as well as to construction. The following sections define these concepts and describe how they apply to construction.
 +
 +
===Minimizing Complexity===
 +
 +
[1*]
 +
 +
Most people are limited in their ability to hold complex structures and information in their working memories, especially over long periods of time. This proves to be a major factor influencing how people convey intent to computers and leads to one of the strongest drives in software construction: ''minimizing'' complexity.
 +
The need to reduce complexity applies to essentially every aspect of software construction and is particularly critical to testing of software constructions. In software construction, reduced complexity is achieved through emphasizing code creation that is simple and readable rather than clever.
 +
It is accomplished through making use of standards (see  section  1.5,  Standards  in  Construction), modular  design  (see  section  3.1,  Construction
 +
Design), and numerous other specific techniques (see section 3.3, Coding). It is also supported by construction-focused quality techniques (see section 3.7, Construction Quality).
 +
 +
===Anticipating Change===
 +
[1*]
 +
Most  software  will  change  over  time,  and  the anticipation of change drives many aspects of software  construction;  changes  in  the  environments in which software operates also affect software in diverse ways.
 +
Anticipating change helps software engineers build extensible software, which means they can enhance a software product without disrupting the underlying structure. Anticipating change is supported by many specific techniques (see section 3.3, Coding).
 +
 +
===Constructing for Verification===
 +
[1*]
 +
 +
Constructing  for  verification  means  building software in such a way that faults can be readily found by the software engineers writing the software as well as by the testers and users during independent testing and operational activities. Specific techniques that support constructing for verification include following coding standards to support code reviews and unit testing, organizing code to support automated testing, and restricting the use of complex or hard-to-understand language structures, among others.
 +
 +
===Reuse===
 +
[2*]
 +
 +
Reuse refers to using existing assets in solving different problems. In software construction, typical assets that are reused include libraries, modules, components, source code, and commercial off-the-shelf (COTS) assets. Reuse is best practiced systematically, according to a well-defined, repeatable process. Systematic reuse can enable significant  software  productivity,  quality,  and cost improvements. Reuse has two closely related facets:"construction for reuse" and "construction with reuse." The former means to create reusable software assets,
 +
while the latter means to reuse software assets in the construction of a new solution. Reuse often transcends the boundary of projects, which means reused assets can be constructed in other projects or organizations.
 +
 +
===Standards in Construction===
 +
[1*]
 +
 +
Applying external or internal development standards during construction helps achieve a project’s objectives for efficiency, quality, and cost. Specifically, the choices of allowable programming language subsets and usage standards are important aids in achieving higher security. Standards that directly affect construction issues include
 +
*communication methods (for example, standards for document formats and contents)
 +
*programming languages (for example, language standards for languages like Java and C++)*coding standards (for example, standards for naming conventions, layout, and indentation)
 +
*platforms (for example, interface standards for operating system calls)
 +
*tools (for example, diagrammatic standards for notations like UML (Unified Modeling Language)).
 +
 +
''Use of external standards''. Construction depends on the use of external standards for construction languages, construction tools, technical interfaces, and interactions between the Software Construction KA and other KAs. Standards come from numerous sources, including hardware and software  interface  specifications  (such  as  the Object Management Group (OMG)) and international organizations (such as the IEEE or ISO). Use of internal standards. Standards may also be created on an organizational basis at the corporate level or for use on specific projects. These standards support coordination of group activities, minimizing complexity, anticipating change, and constructing for verification.

Revision as of 22:39, 23 August 2015

Acronyms
API
Application Programming Interface
COTS
Commercial Off-the-Shelf
GUI
Graphical User Interface
IDE
Integrated Development Environment
OMG
Object Management Group
POSIX
Portable Operating System
TDD
Test-Driven Development
UML
Unified Modeling Language
Introduction

The term software construction refers to the detailed creation of working software through a combination of coding, verification, unit testing, integration testing, and debugging. The Software Construction knowledge area (KA) is linked to all the other KAs, but it is most strongly linked to Software Design and Software Testing because the software construction process involves significant software design and testing. The process uses the design output and provides an input to testing (“design” and “testing” in this case referring to the activities, not the KAs). Boundaries between design, construction, and testing (if any) will vary depending on the software life cycle processes that are used in a project. Although some detailed design may be performed prior to construction, much design work is performed during the construction activity. Thus, the Software Construction KA is closely linked to the Software Design KA. Throughout construction, software engineers both unit test and integration test their work. Thus, the Software construction KA is closely linked to the Software Testing KA as well. Software construction typically produces the highest number of configuration items that need to be managed in a software project (source files, documentation, test cases, and so on). Thus, the Software Construction KA is also closely linked to the Software Configuration Management KA. While software quality is important in all the KAs, code is the ultimate deliverable of a software project, and thus the Software Quality KA is closely linked to the Software Construction KA. Since software construction requires knowledge of algorithms and of coding practices, it is closely related to the Computing Foundations KA, which is concerned with the computer science foundations that support the design and construction of software products. It is also related to project management, insofar as the management of construction can present considerable challenges.

Breakdown of Topics for Software Construction

Figure 3.1 gives a graphical representation of the top-level decomposition of the breakdown for the Software Construction KA.

1 Software Construction Fundamentals

Software construction fundamentals include

  • minimizing complexity
  • anticipating change
  • constructing for verification
  • reuse
  • standards in construction.

The first four concepts apply to design as well as to construction. The following sections define these concepts and describe how they apply to construction.

1.1 Minimizing Complexity

[1*]

Most people are limited in their ability to hold complex structures and information in their working memories, especially over long periods of time. This proves to be a major factor influencing how people convey intent to computers and leads to one of the strongest drives in software construction: minimizing complexity. The need to reduce complexity applies to essentially every aspect of software construction and is particularly critical to testing of software constructions. In software construction, reduced complexity is achieved through emphasizing code creation that is simple and readable rather than clever. It is accomplished through making use of standards (see section 1.5, Standards in Construction), modular design (see section 3.1, Construction Design), and numerous other specific techniques (see section 3.3, Coding). It is also supported by construction-focused quality techniques (see section 3.7, Construction Quality).

1.2 Anticipating Change

[1*] Most software will change over time, and the anticipation of change drives many aspects of software construction; changes in the environments in which software operates also affect software in diverse ways. Anticipating change helps software engineers build extensible software, which means they can enhance a software product without disrupting the underlying structure. Anticipating change is supported by many specific techniques (see section 3.3, Coding).

1.3 Constructing for Verification

[1*]

Constructing for verification means building software in such a way that faults can be readily found by the software engineers writing the software as well as by the testers and users during independent testing and operational activities. Specific techniques that support constructing for verification include following coding standards to support code reviews and unit testing, organizing code to support automated testing, and restricting the use of complex or hard-to-understand language structures, among others.

1.4 Reuse

[2*]

Reuse refers to using existing assets in solving different problems. In software construction, typical assets that are reused include libraries, modules, components, source code, and commercial off-the-shelf (COTS) assets. Reuse is best practiced systematically, according to a well-defined, repeatable process. Systematic reuse can enable significant software productivity, quality, and cost improvements. Reuse has two closely related facets:"construction for reuse" and "construction with reuse." The former means to create reusable software assets, while the latter means to reuse software assets in the construction of a new solution. Reuse often transcends the boundary of projects, which means reused assets can be constructed in other projects or organizations.

1.5 Standards in Construction

[1*]

Applying external or internal development standards during construction helps achieve a project’s objectives for efficiency, quality, and cost. Specifically, the choices of allowable programming language subsets and usage standards are important aids in achieving higher security. Standards that directly affect construction issues include

  • communication methods (for example, standards for document formats and contents)
  • programming languages (for example, language standards for languages like Java and C++)*coding standards (for example, standards for naming conventions, layout, and indentation)
  • platforms (for example, interface standards for operating system calls)
  • tools (for example, diagrammatic standards for notations like UML (Unified Modeling Language)).

Use of external standards. Construction depends on the use of external standards for construction languages, construction tools, technical interfaces, and interactions between the Software Construction KA and other KAs. Standards come from numerous sources, including hardware and software interface specifications (such as the Object Management Group (OMG)) and international organizations (such as the IEEE or ISO). Use of internal standards. Standards may also be created on an organizational basis at the corporate level or for use on specific projects. These standards support coordination of group activities, minimizing complexity, anticipating change, and constructing for verification.