The Art and Science of Software Construction: Code Complete

From Code Complete 2:

What Is Software Construction?
Researchers have identified numerous distinct activities that go into software development. They include 

  • Problem definition 
  • Requirements development 
  • Construction planning 
  • Software architecture, or high-level design 
  • Detailed design 
  • Coding and debugging 
  • Unit testing 
  • Integration testing 
  • Integration 
  • System testing 
  • Corrective maintenance

Here are some of the specific tasks involved in construction: 

  • Verifying that the groundwork has been laid so that construction can proceed successfully 
  • Determining how your code will be tested 
  • Designing and writing classes and routines 
  • Creating and naming variables and named constants 
  • Selecting control structures and organizing blocks of statements 
  • Unit testing, integration testing, and debugging your own code 
  • Reviewing other team members’ low-level designs and code and having them review yours 
  • Polishing code by carefully formatting and commenting it 
  • Integrating software components that were created separately 
  • Tuning code to make it faster and use fewer resources

Techniques for Improving Software QualitySoftware quality assurance is a planned and systematic program of activities designed to ensure that a system has the desired characteristics. Although it might seem that the best way to develop a high-quality product would be to focus on the product itself, in software quality assurance you also need to focus on the software-development process.

  • Software-quality objectives. One powerful technique for improving software quality is setting explicit quality objectives from among the external and internal characteristics described in the previous section.
  • Explicit quality-assurance activity. One common problem in assuring quality is that quality is perceived as a secondary goal. Indeed, in some organizations, quick and dirty programming is the rule rather than the exception.  The organization must show programmers that quality is a priority. Making the quality-assurance activity explicit makes the priority clear, and programmers will respond accordingly.
  • Testing strategy. Execution testing can provide a detailed assessment of a product’s reliability. Part of quality assurance is developing a test strategy in conjunction with the product requirements, architecture, and design.
  • Software-engineering guidelines. Guidelines should control the technical character of the software as it’s developed. Such guidelines apply to all software development activities, including problem definition, requirements development, architecture, construction, and system testing.
  • Informal technical reviews. Many software developers review their work before turning it over for formal review. Informal reviews include desk-checking the design or the code or walking through the code with a few peers.
  • Formal technical reviews. One part of managing a software-engineering process is catching problems at the “lowest-value” stage—that is, at the time at which the least investment has been made and at which problems cost the least to correct. To achieve such a goal, developers use “quality gates,” periodic tests or reviews that determine whether the quality of the product at one stage is sufficient to support moving on to the next.  A “gate” does not mean that architecture or requirements need to be 100 percent complete or frozen; it does mean that you will use the gate to determine whether the requirements or architecture are good enough to support downstream development.
  • External audits. An external audit is a specific kind of technical review used to determine the status of a project or the quality of a product being developed.

Development ProcessOther process that aren’t explicitly quality assurance activities also affect software quality:

  • Change-control procedures. One big obstacle to achieving software quality is uncontrolled changes.  The natural effect of change is to destabilize and degrade quality, so handling changes effectively is a key to achieving high quality levels.
  • Measurement of results. Unless results of a quality-assurance plan are measured, you’ll have no way to know whether the plan is working.
  • Prototyping. Prototyping is the development of realistic models of a system’s key functions. A developer can prototype parts of a user interface to determine usability, critical calculations to determine execution time, or typical data sets to determine memory requirements.

Setting Objectives
Explicitly setting quality objectives is a simple, obvious step in achieving quality software, but it’s easy to overlook. You might wonder whether, if you set explicit quality objectives, programmers will actually work to achieve them?

Here’s a recommended combination for achieving higher-than-average quality: 

  • Formal inspections of all requirements, all architecture, and designs for critical parts of a system 
  • Modeling or prototyping 
  • Code reading or inspections 
  • Execution testing

When to Do Quality Assurance
Defects creep into software at all stages. Consequently, you should emphasize quality-assurance work in the early stages and throughout the rest of the project. It should be planned into the project as work begins; it should be part of the technical fiber of the project as work continues; and it should punctuate the end of the project, verifying the quality of the product as work ends.

The General Principle of Software Quality
The General Principle of Software Quality is that improving quality reduces development costs.  Understanding this principle depends on understanding a key observation: the best way to improve productivity and quality is to reduce the time spent reworking code, whether the rework arises from changes in requirements, changes in design, or debugging.
The single biggest activity on most projects is debugging and correcting code that doesn’t work properly.

A Quality-Assurance Plan 

  • Have you identified specific quality characteristics that are important to your project? 
  • Have you made others aware of the project’s quality objectives? 
  • Have you differentiated between external and internal quality characteristics? 
  • Have you thought about the ways in which some characteristics might compete with or complement others? 
  • Does your project call for the use of several different error-detection techniques suited to finding several different kinds of errors? 
  • Does your project include a plan to take steps to assure software quality during each stage of software development? 
  • Is the quality measured in some way so that you can tell whether it’s improving or degrading? 
  • Does management understand that quality assurance incurs additional costs up front in order to save costs later?

Key Points 

  • Quality is free, in the end, but it requires a reallocation of resources so that defects are prevented cheaply instead of fixed expensively. 
  • Not all quality-assurance goals are simultaneously achievable. Explicitly decide which goals you want to achieve, and communicate the goals to other people on your team. 
  • No single defect-detection technique is completely effective by itself. Testing by itself is not optimally effective at removing errors. Successful quality-assurance programs use several different techniques to detect different kinds of errors. 
  • You can apply effective techniques during construction and many equally powerful techniques before construction. The earlier you find a defect, the less intertwined it will become with the rest of your code and the less damage it will cause. 
  • Quality assurance in the software arena is process-oriented. Software development doesn’t have a repetitive phase that affects the final product like manufacturing does, so the quality of the result is controlled by the process used to develop the software.”

Object-Oriented Programming (From Oriented Analysis Design Applications)
What then, is object—oriented programming (OOP as it is sometimes written)? We define it as follows:  Object-oriented programming is a method of implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships

There are three important parts to this definition: 

  1. Object-oriented programming, uses objects, not algorithms, as its fundamental logical building blocks (the “part of” hierarchy we introduced in Chapter 1)
  2. Each object is an instance of some class
  3. Classes are related to one another via inheritance relationships (the “is a” hierarchy we spoke of in Chapter 1). 

There are four major elements of this model:

  • Abstraction
  • Encapsulation
  • Modularity
  • Hierarchy

References:
Code Complete 2
Oriented Analysis Design Applications