Software Process Model and Waterfall Model

What is a Software Process Model? (2 marks)

A software process model is an abstract representation of a software process. It describes a structured set of activities, methods, practices, and transformations that are used to develop and maintain software and its associated products (plans, documents, code, test cases, manuals, etc.).

A software process model provides a framework that defines:

• The order in which activities are carried out
• The entry and exit criteria for each activity
• The deliverables produced at each stage

Common software process models include:

• Waterfall Model
• Incremental Model
• Spiral Model
• Agile Model

Waterfall Model (6 marks)

Definition

The Waterfall Model is a sequential software development approach where each fundamental activity of the process is represented as a separate phase, arranged in linear order. Each phase must be completed fully before proceeding to the next phase. The process is strictly sequential -- no backing up or repeating of phases is allowed. This model is strictly documented and predefined, with features expected at every phase of the Software Development Life Cycle (SDLC).

Phases of the Waterfall Model

The diagram below illustrates the sequential flow:

Requirements Definition
        |
        v
System and Software Design
        |
        v
Implementation and Unit Testing
        |
        v
Integration and System Testing
        |
        v
Operation and Maintenance

1. Requirements Definition (System Requirements)

• All possible requirements of the system to be developed are captured and documented.
• Feasibility study is conducted.
• A Software Requirements Specification (SRS) document is produced.

2. System and Software Design

• The requirements gathered in the first phase are studied and system design is prepared.
• Hardware and software requirements are defined.
• Overall system architecture is designed.

3. Implementation and Unit Testing

• The design is translated into source code.
• Each unit (module) of the software is developed and tested individually to verify that it meets its specifications.

4. Integration and System Testing

• All units developed in the previous phase are integrated into a complete system.
• The integrated system is tested to ensure it meets the specified requirements.
• Errors and bugs are found and fixed.

5. Operation and Maintenance

• The software is deployed to the customer environment.
• Maintenance is carried out to correct errors discovered after deployment, improve performance, and adapt the software to a changed environment.

Merits of the Waterfall Model (1 mark)

Demerits of the Waterfall Model (1 mark)

Summary

The Waterfall Model is the oldest and most widely used software process model. It is best suited for projects where:

• Requirements are clearly defined and stable
• The project is small and short in duration
• Technology is well understood

However, for large, complex, or requirement-changing projects, more flexible models such as the Spiral or Agile model are preferred over the Waterfall Model.

Modular Decomposition and Object Oriented Model of Decomposition

Modular Decomposition

Modular decomposition is a process of decomposing subsystems into modules. After the system has been decomposed into subsystems (during system structuring), each subsystem must be further decomposed into lower-level modules such as components, objects, or functions. It is one of the key activities of the architectural design process.

In short: System --> Subsystems --> Modules (via modular decomposition)

Two modular decomposition models are commonly used:

1. Object Oriented Model (decomposition into objects/classes)
2. Function Oriented (Pipeline) Model (decomposition into functions/processes)

Object Oriented Model of Decomposition

In the object oriented model, the system is decomposed into a set of loosely coupled objects with well-defined interfaces. Each object encapsulates its own private state (data/attributes) and operations (methods/behaviors).

Key characteristics of this model include:

Steps in Object Oriented Decomposition

1. Define the context and modes of use of the system.
2. Design the system architecture by identifying major subsystems.
3. Identify the principal system objects (classes) from the requirements.
4. Develop design models such as class diagrams, sequence diagrams, etc.
5. Specify object interfaces -- define the operations each object provides.

Example

Consider a Patient Management System:

• It can be decomposed into objects such as Patient, PatientRecord, Doctor, Appointment.
• Each object has its own attributes and methods.
• Objects communicate with each other through well-defined interfaces.

Patient                 PatientRecord
-----------             ---------------
- patientID             - recordID
- name                  - diagnosis
- age                   - treatment
-----------             ---------------
+ register()            + addRecord()
+ getDetails()          + getHistory()

These classes and their associations are modeled using UML Class Diagrams, which show the static structure of the system.

Advantages of Object Oriented Decomposition

• Software is easier to change and maintain compared to functional approaches.
• Promotes reusability of object classes.
• Closely models real-world entities, making design more intuitive.
• Supports incremental development -- individual objects can be developed and tested independently.

In summary, modular decomposition breaks subsystems into manageable modules, and the object oriented model does this by organizing the system around objects that encapsulate both data and behavior, making the system more modular, reusable, and maintainable.

Cleanroom Software Development

Definition

Cleanroom software development is a formal software engineering approach that emphasizes the prevention of defects rather than their removal after the fact. It is based on the idea of developing software correctly the first time by using mathematical (formal) methods for specification and design, combined with statistical testing to certify software reliability. The name "cleanroom" is borrowed from the semiconductor manufacturing process, where defects are prevented by working in a controlled, contamination-free environment.

Characteristics of Cleanroom Software Development

1. Formal Specification

• Software requirements and design are expressed using mathematical/formal notations.
• This ensures that the specification is precise, unambiguous, and verifiable.
• Reduces misunderstandings between developers and clients at the earliest stage.

2. Incremental Development

• Software is developed in a series of increments (small, manageable pieces).
• Each increment is specified, designed, verified, and tested before the next one begins.
• This allows early detection of problems and reduces overall project risk.

3. Structured Programming

• Only well-defined, mathematically sound control structures are used (sequence, selection, iteration).
• No ad-hoc or unstructured code is permitted.
• This makes formal verification of the code feasible and practical.

4. Static Verification (Correctness Proofs)

• Code is not executed by developers for testing purposes during development.
• Instead, correctness is verified through formal inspections and mathematical proofs.
• Teams use structured walkthroughs and reviews to confirm that the code meets its specification before any execution.

5. Statistical Testing for Reliability Certification

• Testing is performed not to find bugs, but to certify the reliability of the software.
• Test cases are generated based on a statistical usage model that reflects how real users will use the system.
• This allows a quantitative, measurable statement of software reliability (e.g., Mean Time to Failure).

6. Team Organization

• The cleanroom process uses separate teams for development and testing.
• The development team focuses on correctness verification.
• The independent testing team performs statistical testing.
• This separation ensures objectivity and reduces bias.

7. Zero Defect Goal

• The primary goal is defect prevention, not defect correction.
• By combining formal methods with rigorous inspections, the aim is to deliver software with near-zero defects.

Summary Table

Conclusion

Cleanroom software development is a disciplined, mathematically-grounded approach that combines formal methods, structured programming, and statistical testing to produce highly reliable software. Its core philosophy is that quality must be built in from the beginning, not inspected in at the end.

Path Testing

Definition

Path testing is a white-box (structural) testing technique that aims to design test cases such that every possible path through a program's control flow graph (CFG) is executed at least once. The goal is to ensure complete coverage of all independent paths in the program logic, thereby detecting errors in the program structure and logic.

Key Concepts

Control Flow Graph (CFG)

A CFG represents the program as a directed graph where:

• Nodes represent processing steps (statements or blocks)
• Edges represent flow of control between steps
• Decision nodes represent branching (if, while, for)

Cyclomatic Complexity

Cyclomatic complexity (V(G)) determines the number of independent paths to be tested:

$$V(G) = E - N + 2P$$

Where:

• E = Number of edges
• N = Number of nodes
• P = Number of connected components (usually 1)

Steps in Path Testing

1. Draw the Control Flow Graph from the program
2. Calculate Cyclomatic Complexity V(G)
3. Identify all independent (basis) paths
4. Design test cases for each path
5. Execute tests and verify results

Example

Program: Find the largest of two numbers

1. Start
2. Read A, B
3. If A > B then
4.     Print "A is largest"
5. Else
6.     Print "B is largest"
7. End

Step 1: Draw the Control Flow Graph

        [1] Start
          |
        [2] Read A, B
          |
        [3] A > B ?
       /         \
    Yes            No
     |              |
    [4] Print A   [5] Print B
       \              /
        \            /
         [6] End

Step 2: Calculate Cyclomatic Complexity

$$V(G) = E - N + 2P = 6 - 6 + 2(1) = \mathbf{2}$$

So there are 2 independent paths to test.

Step 3: Identify Independent Paths

Step 4: Design Test Cases

Advantages of Path Testing

• Ensures complete logical coverage of the program
• Helps detect unreachable code and dead code
• Identifies logic errors that may not be found by black-box testing
• Provides a measurable coverage criterion using cyclomatic complexity

Disadvantages

• Becomes complex and impractical for large programs with many paths
• Does not test data-related errors (e.g., wrong formula)
• Number of paths can grow exponentially with nested loops and conditions

Summary

Path testing is a systematic white-box technique that guarantees all independent execution paths are tested at least once. By using cyclomatic complexity as a guide, testers can determine the minimum number of test cases required to achieve full path coverage, making it a powerful method for ensuring program correctness.

Short Notes

a. Reliability Validation

Reliability validation is a part of the broader software validation activity in software engineering. Validation is concerned with building the right system -- it is intended to show that a system conforms to its specifications and meets the user's expectations.

Reliability validation specifically focuses on verifying that the software performs its intended functions correctly and consistently over time, under defined conditions, without failure.

Key Points:

• Purpose: To demonstrate that the software can be trusted by its users. As noted in software engineering principles, the trust challenge requires developing techniques that demonstrate software can be trusted -- reliability validation directly addresses this challenge.

• Importance in Safety-Critical Systems: In areas such as space, aviation, and nuclear power plants, the cost of software failure can be massive because lives are at risk. Reliability validation is therefore critical in such domains.

• Cost Consideration: Roughly 60% of software costs are development costs and 40% are testing costs. For real-time and safety-critical software, validation and testing require even more extensive effort than web-based systems.

• Process: It involves:

  • Running the system under realistic conditions
  • Measuring failure rates
  • Comparing results against reliability requirements specified during software specification

• Outcome: A validated, reliable software system improves overall software quality, reliability, and productivity -- all recognized advantages of proper software engineering practice.

b. Reverse Engineering

Reverse engineering in software engineering is the process of analyzing an existing software system to identify its components, their relationships, and to extract design and requirement information -- essentially working backwards from the implemented system to recover higher-level abstractions such as design documents or specifications.

Key Points:

• Definition: It is the process of recovering the design, architecture, or requirements of a software system from its source code, binary, or documentation when the original design artifacts are unavailable or outdated.

• Why It Is Needed:

  • Over time, software evolves to meet changing customer needs. As noted, software evolution is a fundamental software engineering activity, and evolution costs often exceed development costs for customer software.
  • Original documentation may be lost, incomplete, or outdated after repeated maintenance cycles.

• Goals of Reverse Engineering:

  • Understand the existing system before making changes
  • Recover lost documentation
  • Support software re-engineering or migration to a new platform
  • Detect security vulnerabilities

• Process Steps:

  1. Information extraction -- collecting data from source code or binaries
  2. Analysis -- understanding the structure and behavior
  3. Abstraction -- producing higher-level design or requirement models

• Relation to Software Evolution: Since software must be written and maintained to meet changing needs of customers, reverse engineering is a practical tool used during the evolution phase of the software process.

Note: The reference notes do not cover reverse engineering in explicit detail; the above is supplemented with standard, correct software engineering knowledge consistent with the curriculum context provided.