Software Development Process – An Overview

An Overview of the Software Development Process

An intuitive software development process is outlined below.

In general, the process of development of a software project could be broken down into a number of stages. Here is an outline of the stages involved:

Requirements Analysis  

First you need to identify the requirements of the project. Simply speaking, you will need to decide what your program should do (known as functional requirements), and note down other requirements that are important but not related to the functions of your program (known as non-functional requirements),

for example, a requirement that the user interface should be user friendly.You have to make a list of the requirements, and from it you will need to decide whether you have the capability to complete them. You may also want to prioritize them such that the most important functionalities are developed first, and other parts can be added subsequently.

Systems Design

From the requirements determined you can then define the scope of the project. Instead of putting the whole program in one piece, we will now organize the program into several components (or subsystems — a part of the entire system).

Two major models exist today — decomposition based on functions and decomposition based on objects. After you have fixed the model, you decide on which functions or object methods are to be associated with which source file or object, and determine how these components interact with each other to perform the functionalities.

Note that you don’t need to decide on how these source files or objects are implemented in real source code at this stage — it is just an overall view of the interaction between the components.

Program Design

After we have determined how the components interact with each other, we can now decide how each function or object method is implemented. For each function, based on the actions to perform you have to develop an algorithm, which is a well-defined programming-language independent procedure to carry out the actions specified. You may want to use a flowchart or some pseudocode to illustrate the flow of the program. Pseudocode is expressed in a way resembling real programming source code, except language-dependent constructs are omitted.

As pseudocode is language independent, you can transform an idea from pseudocode to source code in any programming languages very easily.

There isn’t a single standardized pseudocode syntax. In many cases, pseudocode can even be written in English-like statements because pseudocode is written to demonstrate how a program is supposed to work, and provided it communicates the idea clearly it suffices.It is up to you as the author to express pseudocode in whatever way the algorithm is best illustrated.

Coding

This is largely the continuation of the Program Design stage to transform your algorithm into programming language constructs. If you have worked out the algorithm properly this should be a piece of cake.

Unit Testing

Unit testing corresponds to Program Design. As each function or object method has a predefined behaviour, they can be tested individually to see if such behaviour agree to that defined. Most of the time when we are talking about debugging, we are describing this stage.

Systems Testing

Systems Testing corresponds to System Design. This is to test if the components interact with each other in exactly the same way as designed in the Systems Design stage.

Requirements Validation

This corresponds to requirements analysis. The software developed is compared against the requirements to ensure each functionality has been incorporated into the system and works as expected.

Maintenance

By now the software has been developed but you cannot simply abandon it. Most probably we still need to develop later versions, or apply patches to the current one as new bugs are found in the program.

 

Software for commercial distribution especially needs investment of a lot of time and effort at this stage capturing user feedback, but software not distributed commercially should also pay attention to this stage as this affects how well your software can be further developed. Of course, for the examples in this discussion that is so short and simple we don’t need such an elaborate development procedure. However, you will find when you develop a larger-scale project that having a well-defined procedure is essential to keep your development process in order.

 This is just one of the many process models in existence today. Discussion of such process models can be found in many fundamental text for Software Engineering.

Actually, what I have presented was a variant of the Waterfall process model, and is considered one that, if employed, is likely to delay project schedules and result in increased costs of software development.

The reason I present it here is that the Waterfall model is the easiest model to understand.

Because presentation of process models is out of the scope of the discussion, some Web links will be presented at the end of this discussion from which you will find selected texts describing process models, including the Rational Unified Process which I recommend as an improved process model for larger-scale development projects.

Adoption of an appropriate process model helps guide the development process with optimized usage of resources, increased productivity and software that are more fault-tolerant.

 

Rational Unified Process Whitepapers

http://www.rational.com/products/rup/whitepapers.jsp