Software Development Process Models
A software process model is an abstract representation of a software process. Each process model represents a process from a particular perspective so it only provides partial information about that process.
For many large systems, there is no single software process that is used, different processes are used to develop different parts of the system.
The following are some of the generic software process models:
Waterfall Model
This takes the fundamental process activities of specification, development, validation, and evolution and represents them as separate process phases such as requirements specification, software design, implementation, testing, and so on.
The first published model of the software development process was derived from other engineering processes ( Royce, 1970 ).
The principal stages of the model map onto fundamental development activities:
- Requirements analysis and definition: The system’s services, constraints, and goals are established by consultation with system users. They are then defined in detail and serve as a system specification.
- System and software design: The systems design process partitions the requirements to either hardware or software systems. It establishes the overall system architecture. Software design involves identifying and describing the fundamental software system abstractions and their relationships.
- Implementation and unit testing: During this stage, the software design is realized as a set of programs or program units. Unit testing involves verifying that each unit meets its specification.
- Integration and system testing: The individual program units or programs are integrated and tested as a complete system to ensure that the software requirements have been met. After testing. the software system is delivered to the customer.
- Operation and maintenance: Normally ( although not necessarily ) this is the longest life-cycle phase. The system is installed and put into practical use. Maintenance involves correcting errors that were not discovered in earlier stages of the life cycle, improving the implementation of system units, and enhancing the system’s services as new requirements are discovered.
Evolutionary Development
This approach interleaves the activities of specification, development, and validation. An initial system is rapidly developed from an abstract specification. This is then refined with customer input to produce a system that satisfies the customer’s needs.
Evolutionary development is based on the idea of developing an initial implementation, exposing this to user comments, and refining this through many versions until an adequate system has been developed. Rather than having separate specification, development, and validation activities, these are carried out concurrently with rapid feedback across these activities.
There are two types of evolutionary development:
- Exploratory development – where the objective of the process is to work with the customer to explore their requirements and deliver a final system. The development starts with the parts of the system which are understood. The system evolves by adding new features as they are proposed by the customer.
- Throw-away prototyping – where the objective of the evolutionary development process is to understand the customer’s requirements and hence develop a better requirements definition for the system. The prototype concentrates on experimenting with those parts of the customer requirements which are poorly understood.
Reuse-oriented development
This approach is based on the existence of a significant number of reusable components. The system development process focuses on integrating these components into a system rather than developing from scratch.
In the majority of software projects, there is some software reuse. This usually happens informally when people working on the project know of designs or code which is similar to that required. They look for these, modify them as required, and incorporate them into their system. In the evolutionary approach, reuse is often seen as essential for rapid system development.
This informal reuse takes place irrespective of the generic process which is used. However, in the past few years, an approach to software development (component-based software engineering ) that relies on reuse has emerged and is becoming increasingly widely used.
This reuse-oriented approach relies on a large base of reusable software components which can be accessed and some integrating framework for these components.
Sometimes, these components are systems in their own right ( COTS or Commercial Off – The – Shelf systems ) that may be used to provide specific functionality such as text formatting, numeric calculation, etc. The generic process model for reuse-oriented development is shown above.
While the initial requirements specification stage and the validation stage are comparable to other processes, the intermediate stages in a reuse-oriented process are different.
These stages are:
- Component analysis: Given the requirements specification, a search is made for components to implement that specification. Usually, there is not an exact match and the components which may be used provide only some of the functionality required.
- Requirements modification: During this stage, the requirements are analyzed using information about the components which have been discovered. They are then modified to reflect the available components. Where modifications are impossible, the component analysis activity may be re-entered to search for alternative solutions.
- System design with reuse: During this phase, the framework of the system is designed or an existing framework is reused. The designers take into account the components which are reused and organized the framework to enter for this. Nome new software may have to be designed if reusable components are not available.
- Development and integration: Software that cannot be bought in is developed and the components and COTS systems are integrated to create the system. System integration, in this model, may be part of the development process rather than a separate activity.
The RAD Model
Rapid application development ( RAD ) is an incremental software development process model that emphasizes an extremely short development cycle. The RAD model is a “high-speed ” adaptation of the linear sequential model in which rapid development is achieved by using component-based construction. If requirements are well understood and project scope is constrained, the RAD process enables a development team to create a ” fully functional system ” within very short time periods ( e.g .. the following phases: 60 to 90 days ) Used primarily for information systems applications, the RAD approach encompasses the following phases:
Business modeling
The information flow among business functions is modeled in a way that answers the following questions: What information drives the business process? What information is generated? Who generates it? Where does the information go? Who processes it?
Data modeling
The information flow defined as part of the business modeling phase is refined into a set of data objects that are needed to support the business. The characteristics ( called attributes ) of each object are identified and the relationships between these objects are defined.
Process modeling
The data objects defined in the data modeling phase are transformed to achieve the information flow necessary to implement a business function. Processing descriptions are created for adding. modifying, deleting, or retrieving a data object.
Application generation
RAD assumes the use of fourth-generation techniques. Rather than creating software using conventional third-generation programming languages, the RAD process works to reuse existing program components ( when possible ) or create reusable components ( when necessary ). In all cases, automated tools are used to facilitate the construction of the software.
Testing and turnover
Since the RAD process emphasizes reuse, many of the program components have already been tested. This reduces overall testing time. However, new components must be tested and all interfaces must be fully exercised.
Obviously, the time constraints imposed on a RAD project demand ” Scalable scope ” If a business application can be modularized in a way that enables each major function to be completed in less than three months ( using the approach described previously ), it is a candidate for RAD. Each major function can be addressed by a separate RAD team and then integrated to form a whole.
