Construction Principles

The construction activity encompasses a set of coding and testing tasks that lead to operational software that is ready for delivery to the customer or end-user. In modern software engineering work, coding may be (1) the direct creation of prógramming language source code (e.g., Java, (2) the automatic generation of source code using an intermediate design-like representation of the component to be built, or (3) the automatic generation of executable code using a "fourth-generation programming language" (e.g., Visual C++).

The initial focus of testing is at the component level, often called Other levels of testing include (1) integration testing (conducted as the system is constructed), validation testing that assesses whether requirements have been met for the complete system (or software increment), and (3) acceptance testing that is conducted by the customer in an effort to exercise all required features and functions.

The following set of fundamental principles and concepts are applicable to coding and testing:

Coding Principles. The principles that guide the coding task are closely aligned with programming style, programming languages, and programming methods. However, there are a number of fundamental principles that can be stated:

Preparation principles: Before you write one line of code, be sure you

• Understand the problem you're trying to solve. Understand basic design principles and concepts.
• Pick a programming language that meets the needs of the software to be built and the environment in which it will operate.
• Select a programming environment that provides tools that will make your work easier.
• Create a set of unit tests that will be applied once the component of your code is completed.

Programming principles: As you begin writing code, be sure you Constrain your algorithms by following structured programming [Boh00] practice.

• Consider the use of pair programming
• Select data structures that will meet the needs of the design.
• Understand the software architecture and create interfaces that are consistent with it. Keep conditional logic as simple as possible,
• Create nested loops in a way that makes them easily testable.
• Select meaningful variable names and follow other local coding standards. part two modeling
• Write code that is self-documenting. Create a visual (e.g., indentation and blank lines) that aids understanding.
• Validation Principles: After you've completed your first coding pass, be sure you
• Conduct a code walkthrough when appropriate.
• Perform unit tests and correct errors you've uncovered.

Refactor the code. More books have been written about programming (coding) and the principles and

concepts that guide it than about any other topic in the software process. Books on the subject include early works on programming style [Ket78], practical software construction [McC04], programming pearls [Ben99], the art of programming [Knu98], pragmatic programming issues [Hun99], and many, many other subjects.

A comprehensive discussion of these principles and concepts is beyond the scope of this book. If you have further interest, examine one or more of the references noted.

Testing Principles. In a classic book on software testing, Glen Myers [Mye79]

states a number of rules that can serve well as testing objectives: the song?

• Testing is the process of executing a program with the intent of finding an error.
• A good test case is one that has a high probability of finding an as-yet-undiscovered error.

A successful test is one that uncovers an as-yet-undiscovered error.

These objectives imply a dramatic change in viewpoint for some software developers. They move counter to the commonly held view that a successful test is one in which no errors are found. Your objective is to design tests that systematically uncover different classes of errors and to do so with a minimum amount of time and effort.

Iftesting is conducted successfully (according to the objective it will uncover errors in the software. As a secondary benefit, testing demonstrates that software functions appear to be working according to specification and that behavioral and performance requirements appear to have been met. In addition, the data collected as testing is conducted provide a good indication of software reliability and some indication of software quality as a whole. But testing cannot show the absence of errors and defects; it can show only that software errors and defects are present. It is important to keep this (rather gloomy) statement in mind as testing is being conducted.

Principle 1. All tests should be traceable to customer requirements. The objective of software testing is to uncover errors. It follows that the most severe defects (from the customer's point of view) are those that cause the program to fail to meet its requirements.

Principle 2. Tests should be planned long before testing begins. Test planning can begin as soon as the requirements model is complete. Detailed definition of test cases can begin as soon as the design model has been solidified. Therefore, all tests can be planned and designed before any code has been generated.

Principle 3. The Pareto principle applies to software testing. In this context, the Pareto principle implies that 80 percent ofall errors uncovered during testing will likely be traceable to 20 percent of all program components. The problem, of course, is to isolate these suspect components and thoroughly test them.

Principle 4. Testing should begin "in the small" and progress toward testing "in the large. " The first tests planned and executed generally focus on individual components. As testing progresses, focus shifts in an attempt to find errors in integrated clusters of components and ultimately in the entire system.

Principle 5. Exhaustive testing is not possible. The number of path permutations for even a moderately sized program is exceptionally large. For this reason, it is impossible to execute every combination of paths during testing. It is possible, however, to adequately cover program logic and to ensure that all conditions in the component-level design have been exercised.