The SWEBOK defines Software Construction as “the detailed creation of working, meaningful software through a combination of coding, verification, unit testing, integration testing, and debugging”.
The SWEBOK identifies three sub-areas;
- Software Construction Fundamentals
- Managing Construction
- Practical Considerations
It should be noted that the SWEBOK states that “the software construction process itself involves significant software design and test activity. It also uses the output of design and provides one of the inputs to testing, both design and testing being the activities, not the KAs[Knowledge Areas] in this case. Detailed boundaries between design, construction, and testing (if any) will vary depending upon the software life cycle processes that are used in a project.”
One of the agile techniques is TDD, Test Driven Development, which uses testing to drive coding and sort of flips the inputs and outputs. Of course most all agile techniques emphasize short iterations and blurs those boundaries between design, construction, and testing!
From Steve McConnell’s book, Code Complete, Microsoft Press, 1993;
The role of software construction is:
- Verifying that the architectural design is acceptable
- Designing and writing routines and modules
- Creating data types and naming variables
- Selecting control structures and organizing blocks of statements
- Finding and fixing errors
- Conducting peer reviews
- Polishing code through careful formatting and commenting
- Integrating the completed modules
- Tuning the code to make it shorter and faster
Unfortunately, many people (inside as well as outside the industry) think that the software construction process is all there is to creating programs. While this may be the most labor-intensive effort, it is NOT the only necessary activity in software engineering. I recommend you find the “Computer Program vs. Programming Product” chart from “The Mythical Man-Month: Essays on Software Engineering, Addison-Wesley, 1975” by F.P. Brooks Jr.
I like to think of “Extreme Programming” as addressing “Software Construction” issues and “Agile/Lean” as addressing “Software Engineering” issues. Again this is an over simplification, but helps me keep my head from spinning.
Allen