Software construction

Last updated
Software development
Core activities
Paradigms and models
Methodologies and frameworks
Supporting disciplines
Practices
Tools
Standards and Bodies of Knowledge
Glossaries

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 engineering is the application of engineering to the development of software in a systematic method.

Software verification is a discipline of software engineering whose goal is to assure that software fully satisfies all the expected requirements.

In computer programming, unit testing is a software testing method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine whether they are fit for use.

Contents

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]

Programming complexity is a term that includes many properties of a piece of software, all of which affect internal interactions. According to several commentators, there is a distinction between the terms complex and complicated. Complicated implies being difficult to understand but with time and effort, ultimately knowable. Complex, on the other hand, describes the interactions between a number of entities. As the number of entities increases, the number of interactions between them would increase exponentially, and it would get to a point where it would be impossible to know and understand all of them. Similarly, higher levels of complexity in software increase the risk of unintentionally interfering with interactions and so increases the chance of introducing defects when making changes. In more extreme cases, it can make modifying the software virtually impossible. The idea of linking software complexity to the maintainability of the software has been explored extensively by Professor Manny Lehman, who developed his Laws of Software Evolution from his research. He and his co-Author Les Belady explored numerous possible Software Metrics in their oft-cited book, that could be used to measure the state of the software, eventually reaching the conclusion that the only practical solution would be to use one that uses deterministic complexity models.

In computing, source code is any collection of code, possibly with comments, written using a human-readable programming language, usually as plain text. The source code of a program is specially designed to facilitate the work of computer programmers, who specify the actions to be performed by a computer mostly by writing source code. The source code is often transformed by an assembler or compiler into binary machine code understood by the computer. The machine code might then be stored for execution at a later time. Alternatively, source code may be interpreted and thus immediately executed.

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]

Software testing is an investigation conducted to provide stakeholders with information about the quality of the software product or service under test. Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include the process of executing a program or application with the intent of finding software bugs, and verifying that the software product is fit for use.

Programming language Language designed to communicate instructions to a machine

A programming language is a formal language, which comprises a set of instructions that produce various kinds of output. Programming languages are used in computer programming to implement algorithms.

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 model

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 fewer lines to be implemented in high level languages than in lower level languages. [7]

Coding

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.CS1 maint: Uses editors parameter (link)
  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.

Related Research Articles

Code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior. Refactoring is intended to improve nonfunctional attributes of the software. Advantages include improved code readability and reduced complexity; these can improve source-code maintainability and create a more expressive internal architecture or object model to improve extensibility.

A software bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways. The process of finding and fixing bugs is termed "debugging" and often uses formal techniques or tools to pinpoint bugs, and since the 1950s, some computer systems have been designed to also deter, detect or auto-correct various computer bugs during operations.

Regression testing is re-running functional and non-functional tests to ensure that previously developed and tested software still performs after a change. If not, that would be called a regression. Changes that may require regression testing include bug fixes, software enhancements, configuration changes, and even substitution of electronic components. As regression test suites tend to grow with each found defect, test automation is frequently involved. Sometimes a change impact analysis is performed to determine an appropriate subset of tests.

The Therac-25 was a computer-controlled radiation therapy machine produced by Atomic Energy of Canada Limited (AECL) in 1982 after the Therac-6 and Therac-20 units.

Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: requirements are turned into very specific test cases, then the software is improved so that the tests pass. This is opposed to software development that allows software to be added that is not proven to meet requirements.

Code review is a software quality assurance activity in which one or several humans check a program mainly by viewing and reading parts of its source code, and they do so after implementation or as an interruption of implementation. At least one of the humans must not be the code's author. The humans performing the checking, excluding the author, are called "reviewers".

<i>Code Complete</i> book by Steve McConnell

Code Complete is a software development book, written by Steve McConnell and published in 1993 by Microsoft Press, encouraging developers to continue past code-and-fix programming and the big design up front and waterfall models. It is also a compendium of software construction techniques, which include techniques from naming variables to deciding when to write a subroutine.

White-box testing is a method of software testing that tests internal structures or workings of an application, as opposed to its functionality. In white-box testing an internal perspective of the system, as well as programming skills, are used to design test cases. The tester chooses inputs to exercise paths through the code and determine the expected outputs. This is analogous to testing nodes in a circuit, e.g. in-circuit testing (ICT). White-box testing can be applied at the unit, integration and system levels of the software testing process. Although traditional testers tended to think of white-box testing as being done at the unit level, it is used for integration and system testing more frequently today. It can test paths within a unit, paths between units during integration, and between subsystems during a system–level test. Though this method of test design can uncover many errors or problems, it has the potential to miss unimplemented parts of the specification or missing requirements.

Software maintenance in software engineering is the modification of a software product after delivery to correct faults, to improve performance or other attributes.

A Fagan inspection is a process of trying to find defects in documents during various phases of the software development process. It is named after Michael Fagan, who is credited with being the inventor of formal software inspections.

A software review is "A process or meeting during which a software product is examined by a project personnel, managers, users, customers, user representatives, or other interested parties for comment or approval".

Software security assurance is a process that helps design and implement software that protects the data and resources contained in and controlled by that software. Software is itself a resource and thus must be afforded appropriate security.

Fault injection is a testing technique which aids in understanding how [virtual/real] system behaves when stressed in unusual ways. This technique is based on simulation's or experiment's result, thus it may be more valid compared to statistical methods.

Frame technology (FT) is a language-neutral system that manufactures custom software from reusable, machine-adaptable building blocks, called frames. FT is used to reduce the time, effort, and errors involved in the design, construction, and evolution of large, complex software systems. Fundamental to FT is its ability to stop the proliferation of similar but subtly different components, an issue plaguing software engineering, for which programming language constructs or add-in techniques such as macros and generators failed to provide a practical, scalable solution.

A Software Defect Indicator is a pattern that can be found in source code that is strongly correlated with a software defect, an error or omission in the source code of a computer program that may cause it to malfunction. When inspecting the source code of computer programs, it is not always possible to identify defects directly, but there are often patterns, sometimes called anti-patterns, indicating that defects are present.

Development testing is a software development process that involves synchronized application of a broad spectrum of defect prevention and detection strategies in order to reduce software development risks, time, and costs.

Software testing tactics a set of tactics useful in software testing

This article discusses a set of tactics useful in software testing. It is intended as a comprehensive list of tactical approaches to Software Quality Assurance (more widely colloquially known as Quality Assurance and general application of the test method.

References