The Software Development Process

---

A software development process is a set of activities where the end product is a computer program. Numerous distinct activities have been identified in the last 20 years as being part of the software development process. We will just discuss the most important steps in this section.

1. Software Specification Defining the requirements of the software.

2. Software Design Conception or contrivance of a method for turning the software specification into an operational program. It links the software specification with writing the exact program text in a high-level language such as C#.

3. Writing the Software Constructing and writing the text, which constitutes the source code of the program.

4. Software Validation and Debugging The software must be validated to ensure that it does what was defined during the software specification phase.

These steps should be performed in the sequence presented here. However, it is often necessary to go back to a previous step before continuing. Let's take a closer look at each step.

1. Software Specification

   Why do we need software requirements? First, if we don't know what the program is supposed to do, how can we even start thinking about ways to implement it? It is the first step toward a solution. Often, one will find the solution hidden inside the specification. There are many other reasons for software specifications, whose discussion is beyond the scope of this book.

   An example of a very simple software specification could be, "The program must be able to calculate the average of two numbers."

2. Software Design Software design can involve many diverse activities, depending on the size and nature of a project. A large project might have several stages as shown in the following:

   2a. Division of the overall project into various subsystems Examples of subsystems are user interfaces, report formatters, and database interfaces. Note that the programs we construct in this book are too small to involve this stage. Thus, every program here can be regarded being part of a subsystem already.

   2b. Segregating each subsystem into modules The term module is a flexible word that has different meanings in different contexts. Here, a module is defined as a collection of data and routines that can act on that data. A module will have a host of suitable services assigned to it that, when collaborating with the other modules in the subsystem, will be able to fulfill its requirements.

   A routine generally only has a very narrow purpose. It consists of a set of specific instructions executed one after the other. Examples of routines would be "Find the square root of a number." or "Find the largest number in this list of numbers." Various high-level languages use different terms, such as procedure, function, and subroutine for this concept. In the C# world, a routine is referred to as a method.

   2c. Identify the data and methods in each module The services offered by the module are divided into suitable subparts that are small enough to be accomplished by one method. Each subpart will then be assigned a method and, consequently, each method will get its functionality specified. Finally, the designers identify the data that must be represented by this module.

   2d. Internal method design This design level is usually left to the individual programmer. Algorithms are constructed here to accomplish very specific tasks. The first actual valid statements might be written here using a language such as C#.

   At this point, we are moving into or getting very close to the next step writing the software.

   New Term: Algorithm

   
   

   An algorithm is a set of exact instructions used to solve a problem. The instructions must be expressed accurately so that by following them blindly, as the computer would, the desired result is still accomplished.

3. Writing the Software The actual statements are written in C#. This part of the design process is always needed on projects of any size and nature.

4. Software validation and debugging Various tests should be performed on the program, during and after writing the program, to make sure that it does what it is intended to do. You are, in effect, detecting the errors in the program. This activity is referred to as testing.

   To write a correct program, you need to be careful with the design of all program elements and of the translation into C# source code. However, unless you are superhuman, errors (also called bugs) tend to creep into programs from many unexpected angles. Eliminating bugs in a program is called debugging. Sometimes, the terms testing and debugging are used interchangeably but, strictly speaking, this is incorrect.

Small informal projects, such as many of the programs you will encounter throughout this book, will often involve only design levels 3 and 4 and can be done while the programmer sits in front of the computer. Design might then be taking place inside the head of the programmer, be in the form of scribbling a few diagrams on a piece of paper, and/or looking up a few standard algorithms in a textbook.

Note

Regardless of the project size, careful design will always be beneficial to the software construction process and the end result.

Note

In the OOP discussions of this book, the term object refers to a module; a method to a routine and instance variables are part of the data.

Now we'll look at some of the concepts often encountered by programmers during the design of algorithms. These will be particularly useful when we introduce the first concepts of C#.

---