Software construction

Not to be confused with Software development.
Software development process
Core activities
Paradigms and models
Methodologies and frameworks
Supporting disciplines
Tools
Standards and BOKs

Software construction is a software engineering discipline. It is the detailed creation of working meaningful software through a combination of coding, verification, unit testing, integration testing, and debugging. It is linked to all the other software engineering disciplines, most strongly to software design and software testing.[1]

Software construction fundamentals

Minimizing complexity

The need to reduce complexity is mainly driven by limited ability of most people to hold complex structures and information in their working memories. Reduced complexity is achieved through emphasizing the creation of code that is simple and readable rather than clever. Minimizing complexity is accomplished through making use of standards, and through numerous specific techniques in coding. It is also supported by the construction-focused quality techniques.[2]

Anticipating change

Anticipating change helps software engineers build extensible software, which means they can enhance a software product without disrupting the underlying structure.[2] Research over 25 years showed that the cost of rework can be 10 to 100 times (5 to 10 times for smaller projects) more expensive than getting the requirements right the first time. Given that 25% of the requirements change during development on average project, the need to reduce the cost of rework elucidates the need for anticipating change. [3]

Constructing for verification

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

Reuse

Systematic reuse can enable significant software productivity, quality, and cost improvements. Reuse has two closely related facets:[2]

Standards in construction

Standards, whether external (created by international organizations) or internal (created at the corporate level), that directly affect construction issues include:[2]

Managing construction

Construction models

Numerous models have been created to develop software, some of which emphasize construction more than others. Some models are more linear from the construction point of view, such as the waterfall and staged-delivery life cycle models. These models treat construction as an activity which occurs only after significant prerequisite work has been completed—including detailed requirements work, extensive design work, and detailed planning. Other models are more iterative, such as evolutionary prototyping, Extreme Programming, and Scrum. These approaches tend to treat construction as an activity that occurs concurrently with other software development activities, including requirements, design, and planning, or overlaps them.[1]

Construction planning

The choice of construction method is a key aspect of the construction planning activity. The choice of construction method affects the extent to which construction prerequisites (e.g. Requirements analysis, Software design, .. etc) are performed, the order in which they are performed, and the degree to which they are expected to be completed before construction work begins. Construction planning also defines the order in which components are created and integrated, the software quality management processes, the allocation of task assignments to specific software engineers, and the other tasks, according to the chosen method.[1]

Construction measurement

Numerous construction activities and artifacts can be measured, including code developed, code modified, code reused, code destroyed, code complexity, code inspection statistics, fault-fix and fault-find rates, effort, and scheduling. These measurements can be useful for purposes of managing construction, ensuring quality during construction, improving the construction process, as well as for other reasons.[1]

Practical considerations

Software construction is driven by many practical considerations:

Construction design

In order to account for the unanticipated gaps in the software design, during software construction some design modifications must be made on a smaller or larger scale to flesh out details of the software design.[4]

Low Fan-out is one of the design characteristics found to be beneficial by researchers. Information hiding proved to be a useful design technique in large programs that made them easier to modify by a factor of 4. [5]

Construction languages

Construction languages include all forms of communication by which a human can specify an executable problem solution to a computer. They include configuration languages, toolkit languages, and programming languages:[6]

Programmers working in a language they have used for three years or more are about 30 percent more productive than programmers with equivalent experience who are new to a language. High-level languages such as C++, Java, Smalltalk, and Visual Basic yield 5 to 15 times better productivity, reliability, simplicity, and comprehensibility than low-level languages such as assembly and C. Equivalent code has been shown to need less lines to be implemented in high level languages than lower level languages.[7]

Coding

Main article: Computer programming

The following considerations apply to the software construction coding activity:[8]

Construction testing

The purpose of construction testing is to reduce the gap between the time at which faults are inserted into the code and the time those faults are detected. In some cases, construction testing is performed after code has been written. In test-first programming, test cases are created before code is written. Construction involves two forms of testing, which are often performed by the software engineer who wrote the code:[1]

Reuse

Implementing software reuse entails more than creating and using libraries of assets. It requires formalizing the practice of reuse by integrating reuse processes and activities into the software life cycle. The tasks related to reuse in software construction during coding and testing are:[1]

Construction quality

The primary techniques used to ensure the quality of code as it is constructed include:[15]

Studies have shown that a combination of these techniques need to be used to achieve high defect detection rate. Other studies showed that different people tend to find different defects. One study found that the Extreme Programming practices of pair programming, desk checking, unit testing, integration testing, and regression testing can achieve a 90% defect detection rate.[16] An experiment involving experienced programmers found that on average they were able to find 5 errors (9 at best) out of 15 errors by testing.[18]

80% of the errors tend to be concentrated in 20% of the project's classes and routines. 50% of the errors are found in 5% of the project's classes. IBM was able to reduce the customer reported defects by a factor of ten to one and to reduce their maintenance budget by 45% in its IMS system by repairing or rewriting only 31 out of 425 classes. Around 20% of a project's routines contribute to 80% of the development costs. A classic study by IBM found that few error-prone routines of OS/360 were the most expensive entities. They had around 50 defects per 1000 lines of code and fixing them costs 10 times what it took to develop the whole system.[18]

Integration

A key activity during construction is the integration of separately constructed routines, classes, components, and subsystems. In addition, a particular software system may need to be integrated with other software or hardware systems. Concerns related to construction integration include planning the sequence in which components will be integrated, creating scaffolding to support interim versions of the software, determining the degree of testing and quality work performed on components before they are integrated, and determining points in the project at which interim versions of the software are tested.[1]

Construction technologies

Object-Oriented Runtime Issues

Object-oriented languages support a series of runtime mechanisms that increase the flexibility and adaptability of the programs like data abstraction, encapsulation, modularity, inheritance, polymorphism, and reflection.[19][20]

Data abstraction is the process by which data and programs are defined with a representation similar in form to its meaning, while hiding away the implementation details.[21] Academic research showed that data abstraction makes programs about 30% easier to understand than functional programs.[10]

Assertions, Design by Contract, and Defensive Programming

Assertions are executable predicates which are placed in a program that allow runtime checks of the program.[19] Design by contract is a development approach in which preconditions and postconditions are included for each routine. Defensive programming is the protection a routine from being broken by invalid inputs.[22]

Error Handling, Exception Handling, and Fault Tolerance

Error handling refers to the programming practice of anticipating and coding for error conditions that may arise when the program runs. Exception handling is a programming language construct or hardware mechanism designed to handle the occurrence of exceptions, special conditions that change the normal flow of program execution.[23] Fault tolerance is a collection of techniques that increase software reliability by detecting errors and then recovering from them if possible or containing their effects if recovery is not possible.[22]

State-Based and Table-Driven Construction Techniques

State-based programming is a programming technology using finite state machines to describe program behaviors.[22] A table-driven method is a schema that uses tables to look up information rather than using logic statements (such as if and case).[24]

Runtime Configuration and Internationalization

Runtime configuration is a technique that binds variable values and program settings when the program is running, usually by updating and reading configuration files in a just-in-time mode. Internationalization is the technical activity of preparing a program, usually interactive software, to support multiple locales. The corresponding activity, localization, is the activity of modifying a program to support a specific local language.[24]

See also

Notes

  1. 1 2 3 4 5 6 7 SWEBOK Pierre Bourque, Robert Dupuis; executive editors, Alain Abran, James W. Moore, eds. (2004). "Chapter 4: Software Construction". Guide to the Software Engineering Body of Knowledge. IEEE Computer Society. pp. 4–1 – 4–5. ISBN 0-7695-2330-7.
  2. 1 2 3 4 5 SWEBOK 2014, p. 3-3.
  3. McConnell 2004, Chapter 3.
  4. SWEBOK 2014, p. 3-5.
  5. McConnell 2004, Chapter 5.
  6. SWEBOK 2014, p. 3-5 - 3-6.
  7. McConnell 2004, Chapter 4.
  8. SWEBOK 2014, p. 3-6.
  9. McConnell 2004, Chapter 11.
  10. 1 2 3 McConnell 2004, Chapter 6.
  11. 1 2 McConnell 2004, Chapter 7.
  12. McConnell 2004, Chapter 12.
  13. 1 2 McConnell 2004, Chapter 16.
  14. 1 2 McConnell 2004, Chapter 19.
  15. SWEBOK 2014, p. 3-7.
  16. 1 2 3 4 McConnell 2004, Chapter 20.
  17. 1 2 McConnell 2004, Chapter 21.
  18. 1 2 McConnell 2004, Chapter 22.
  19. 1 2 SWEBOK 2014, p. 3-8.
  20. Thayer 2013, pp. 140 - 141.
  21. Thayer 2013, p. 140.
  22. 1 2 3 SWEBOK 2014, p. 3-9.
  23. Thayer 2013, p. 142.
  24. 1 2 SWEBOK 2014, p. 3-10.

References

  • Pierre Bourque, Richard E. (Dick) Fairley, eds. (2014). "Chapter 3: Software Construction". Guide to the Software Engineering Body of Knowledge Version 3.0. IEEE Computer Society. ISBN 978-0-7695-5166-1. 
  • McConnell, Steven (2004). Code Complete (2nd ed.). Microsoft Press. ISBN 978-0-7356-1967-8. 
  • Thayer, Richard; Dorfman, Merlin (2013). Software Engineering Essentials. Volume I: The Development Process (Fourth ed.). Software Management Training Press, Carmichael, California. ISBN 978-0-9852707-0-4. 

External links

This article is issued from Wikipedia - version of the 10/9/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.