Chapter 2 - Software Processes

A software process is a set of related activities that leads to the production of a software product. These activities may involve the development of software from scratch in a standard programming language like Java or C. However, business applications are not necessarily developed in this way. New business software is now often developed by extending and modifying existing systems or by configuring and integrating off-the-shelf software or system components.

There are many different software processes but all must include four activities that are fundamental to software engineering:

• 1. Software specification: The functionality of the software and constraints on its operation must be defined.
• 2. Software design and implementation: The software to meet the specification must be produced.
• 3. Software validation: The software must be validated to ensure that it does what the customer wants.
• 4. Software evolution: The software must evolve to meet changing customer needs.

1. The 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.

2. Incremental Development

This approach interleaves the activities of specification, development, and validation. The system is developed as a series of versions (increments), with each version adding functionality to the previous version.

3. Reuse-Oriented Software Engineering

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 them from scratch.

Real software processes are interleaved sequences of technical, collaborative, and managerial activities with the overall goal of specifying, designing, implementing, and testing a software system. Software developers use a variety of different software tools in their work.

The four basic process activities of specification, development, validation, and evolution are organized differently in different development processes. In the waterfall model, they are organized in sequence, whereas in incremental development they are interleaved.

2.2.1 Software Specification

• Feasibility study: An estimate is made of whether the identified user needs may be satisfied using current software and hardware technologies.
• Requirements elicitation and analysis: This is the process of deriving the system requirements through observation of existing systems, discussions with potential users and procurers, task analysis, and so on.
• Requirements specification: Requirements specification is the activity of translating the information gathered during the analysis activity into a document that defines a set of requirements.
• Requirements validation: This activity checks the requirements for realism, consistency, and completeness.

2.2.2 Software Design and Implementation

The implementation stage of software development is the process of converting a system specification into an executable system. It always involves processes of software design and programming but, if an incremental approach to development is used, may also involve refinement of the software specification.

• Architectural design: You identify the overall structure of the system, the principal components, their relationships, and how they are distributed.
• Interface design: You define the interfaces between system components.
• Component design: You take each system component and design how it will operate.
• Database design: You design the system data structures and how these are to be represented in a database.

2.2.3 Software Validation

Software validation or, more generally, verification and validation (V&V) is intended to show that a system both conforms to its specification and that it meets the expectations of the system customer.

• Development testing: The components making up the system are tested by the people developing the system.
• System testing: System components are integrated to create a complete system.
• Acceptance testing: This is the final stage in the testing process before the system is accepted for operational use.

2.2.4 Software Evolution

The flexibility of software systems is one of the main reasons why more and more software is being incorporated in large, complex systems. This distinction between development and maintenance is increasingly irrelevant. It makes much more sense to see development and maintenance as a continuum where software is continually changed over its lifetime in response to changing requirements and customer needs.

Change is inevitable in all large software projects. The system requirements change as the business procuring the system responds to external pressures and management priorities change. As new technologies become available, new design and implementation possibilities emerge.

2.3.1 Prototyping

A prototype is an initial version of a software system that is used to demonstrate concepts, try out design options, and find out more about the problem and its possible solutions. Rapid, iterative development of the prototype is essential so that costs are controlled and system stakeholders can experiment with the prototype early in the software process.

2.3.2 Incremental Delivery

Incremental delivery is an approach to software development where some of the developed increments are delivered to the customer and deployed for use in an operational environment.

2.3.3 Boehm's Spiral Model

A risk-driven software process framework (the spiral model) was proposed by Boehm (1988). The software process is represented as a spiral, rather than a sequence of activities. Each loop in the spiral represents a phase of the software process.

• Objective setting: Specific objectives for that phase are defined
• Risk assessment and reduction: Detailed analysis is carried out for each identified risk
• Development and validation: A development model is chosen after risk evaluation
• Planning: The project is reviewed and next phase is planned

The Rational Unified Process (RUP) is an example of a modern process model that has been derived from work on the UML and the associated Unified Software Development Process. It is a good example of a hybrid process model that brings together elements from all of the generic process models.

The RUP is normally described from three perspectives:

• Dynamic perspective: Shows the phases of the model over time
• Static perspective: Shows the process activities that are enacted
• Practice perspective: Suggests good practices to be used during the process

RUP Phases:

• Inception: Establish a business case for the system
• Elaboration: Develop understanding of the problem domain and establish architectural framework
• Construction: System design, programming, and testing
• Transition: Moving the system from development to operational environment