SE (P1/ C2) - Software process

The objective of this chapter is to introduce you to the idea of a software process—a coherent set of activities for software production.

Software process model (sometimes called a Software Development Life Cycle or SDLC model)

A process model is like a simplified map of how a software process works. It shows the steps involved and how they connect.

However, keep in mind that each process model only gives part of the picture—it focuses on specific aspects and doesn’t show everything.

Three general process models (sometimes called process paradigms)

• The waterfall model

• Incremental development

• Integration and configuration

The waterfall model

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, and testing

Incremental development

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.

Integration and configuration

Integration and configuration This approach relies on the availability of reusable components or systems. The system development process focuses on configuring these components for use in a new setting and integrating them into a system.

The waterfall model or software life cycle

The waterfall model is an example of a plan-driven process. In principle at least.

You plan and schedule all of the process activities before starting software development.

The stages of the waterfall model directly reflect the fundamental software development activities

Stage 1: Requirement analysis and definition (of the waterfall model)

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.

Stage 2: System and software design (of the waterfall model)

• The systems design process allocates the requirements to either hardware or software systems. It establishes an overall system architecture.

• Software design involves identifying and describing the fundamental software system abstractions and their relationships

Stage 3: Implementation and unit testing (of the waterfall model)

1. During this stage, the software design is realized as a set of programs or program units.

2. Unit testing involves verifying that each unit meets its specification.

Stage 4: Integration and system testing (of the waterfall model)

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

Stage 5: Operation and maintenance (of the waterfall model)

• Normally, 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.

The limitations of the waterfall model in SD

The waterfall model assumes a sequential and rigid approach, where each phase must be completed and approved before moving to the next. While this approach may work for hardware development with high manufacturing costs, it is ill-suited for software development. (For more information, read page 49-50)

Incremental development

Incremental development

• Initial implementation is developed first

• Feedback is gathered from users and stakeholders

• Software evolves through multiple versions

• Specification, development, and validation activities are interleaved

• Rapid feedback across activities

• Iterative approach until the required system is developed

What are the three major advantages of ID over WM

• Reduced Cost of Requirement Changes: Less analysis and documentation are needed compared to the waterfall model.

• Easier Customer Feedback: Customers can provide feedback on software demonstrations, making it easier to judge progress than from design documents.

• Early Delivery and Deployment: Customers can use and gain value from the software earlier, even if not all functionality is included.

the Incremental (ID) approach has two problem in the management perspective.

• Lack of Visibility for Managers: Managers need regular deliverables to measure progress, but quickly developed systems make it impractical to produce documentation for every version.

• Structural Degradation: Adding new increments can lead to messy code and degraded system structure, making it costly to add new features. Agile methods suggest regular refactoring to maintain code quality.

For more understanding, read page 51

Three types of software components that are frequently used. (in Integration & Configuration)

1. Stand-alone application systems that are configured for use in a particular environment. These systems are general-purpose systems that have many features, but they have to be adapted for use in a specific application.

2. Collections of objects that are developed as a component or as a package to be integrated with a component framework such as the Java Spring framework (Wheeler and White 2013).

3. Web services that are developed according to service standards and that are available for remote invocation over the Internet.

a general process model for reuse-based development, based on integration and configuration.

• Requirements Specification: Propose initial system requirements with brief descriptions of essential needs and desirable features.

• Software Discovery and Evaluation: Search for and evaluate components and systems that meet the outlined requirements.

• Requirements Refinement: Refine requirements based on the discovered components and systems, updating the system specification accordingly.

• Application System Configuration: If an off-the-shelf system meets the requirements, configure it for the new system.

• Component Adaptation and Integration: If no off-the-shelf system is suitable, modify reusable components or develop new ones and integrate them to create the system.