Lecture 2 – Software Process

Dr. Aghabi Abosaif

Software Process
A software process is a structured set of related activities required to develop a software system.

• Structured → Organized, systematic, and ordered.

• Set of related activities → Activities are interconnected and depend on each other.
• Develop a software system → From idea to delivery and maintenance.

A software process defines:

• What activities must be performed?

• In what order they are performed?
• Who performs them?
• What artifacts are produced?
• What conditions must hold before and after activities?
Software Process, is it Universal?
Sommerville emphasizes:

There is no universally applicable software process.

Why?
Because software systems differ in:
Factor Example
Size Small mobile app vs National banking system
Criticality Game vs Air traffic control
Requirements stability Startup app vs Government system
Regulatory needs Medical system vs Social media platform
Team skills Junior team vs Expert team

Therefore, organizations design processes suited to:

• Their domain
• Their business model
• Their team expertise
• Their risk tolerance
The Four Fundamental Software
Engineering Activities
All software processes, regardless of model, include four core activities.
1. Software Specification
Software specification is the activity of defining:
• The services the system should provide
• The constraints under which the system must operate

Includes:
• Requirements elicitation
• Requirements analysis
• Requirements documentation
• Requirements validation

Example – Online Banking System

Specification defines:
• Users can transfer money
• Transactions must complete within 2 seconds
• System must comply with banking regulations
• System must support 10,000 concurrent users
Without proper specification:
• Development becomes chaotic
• Misunderstandings occur
• Cost overruns happen
 2. Software Development
Software development is the activity of designing and implementing the system according to the specification.

includes:
• Architectural design
• Detailed design
• Implementation (coding)
• Integration

Example – E-commerce Platform

Development includes:
• Designing microservices architecture
• Implementing payment gateway integration
• Developing inventory management system
• Building front-end user interface

Development transforms abstract requirements into executable software.

3. Software Validation
• Software validation is the process of checking that the software
• Conforms to its specification
• Meets the customer's real needs
Validation ensures the system does what the customer wants.
Includes:
• Unit testing • Integration testing
• System testing • Acceptance testing

Important Distinction:
• Verification → Are we building the product right?
• Validation → Are we building the right product?

Example – Hospital Management System

Validation ensures:
• Patient data is correctly stored
• Access control prevents unauthorized access
• Emergency alerts function correctly
• Reports match medical standards
4. Software Evolution
Software evolution refers to modifying the system after delivery to:
• Correct faults
• Improve performance
• Adapt to new requirements
• Respond to changing environment

Types of Evolution:
1. Corrective maintenance → Fix bugs
2. Adaptive maintenance → Adapt to new OS or regulations
3. Perfective maintenance → Add features
4. Preventive maintenance → Improve maintainability

Real-World Example – Ride Sharing Application

Evolution includes:
• Adding digital wallet payments
• Supporting electric vehicle drivers
• Integrating AI route optimization
• Enhancing security authentication
Software rarely remains static after deployment.
Process Description Components
When describing a software process, Sommerville emphasizes three structural elements
that provide a comprehensive framework for understanding and implementing
development methodologies.

01

Products
Deliverables and artifacts produced

02

Roles
Responsibilities and assignments

03

Conditions
Pre and post-activity requirements
Products (Deliverables)
Products are the tangible artifacts produced during process activities.
These deliverables represent measurable outputs that demonstrate
progress and provide value to stakeholders.

Common Software Products

• Requirements document
• UML diagrams
• Source code
• Test cases
• User manuals

Requirements Document UML Diagrams Source Code

Formal specification of system Visual representations of system Implementation of system
functionality and constraints architecture and design functionality in programming
language
Roles
Roles define the responsibilities assigned to individuals or groups within the software development process. Clear role
definition improves accountability, coordination, and overall team effectiveness.

Project Manager Software Architect Developer

Oversees project execution, timeline, Designs system structure and Writes and implements source code
and resource allocation technical framework

Tester Configuration Manager

Validates functionality and identifies Manages version control and system
defects configuration
Pre-conditions and Post-conditions
These conditions ensure controlled transitions between development phases, maintaining
quality and consistency throughout the process.

Pre-condition
Condition that must be true before activity begins
Example: Requirements must be approved before design starts

Activity
Process step is executed

Post-condition
Condition that must be true after activity completes
Example: Architecture must be reviewed and accepted before coding begins
Process Models
A process model is a simplified representation of a software process. It describes the main activities, their order,
and how they interact with each other.

Sommerville presents three generic process models that serve as abstract frameworks guiding software
organization:

Waterfall Model Incremental Reuse-Oriented

Development Software Engineering
Linear sequential approach
with strict phase separation Iterative building with Leveraging existing
continuous feedback components and systems

These models are not real-world processes exactly, but rather conceptual frameworks that help us understand
and organize software development.
The Waterfall Model
Main Phases
The Waterfall Model follows a strict linear sequence where the output of one phase becomes the input of the next:

Requirements Definition
Gathering and documenting all system requirements

System and Software Design

Creating architectural and detailed design specifications

Implementation and Unit Testing

Writing code and testing individual components

Integration and System Testing

Combining components and testing the complete system

Operation and Maintenance

Deploying and maintaining the system in production
 Why "Waterfall"?
The Waterfall Model is a plan-driven, linear sequential
process model where each phase must be completed
before the next phase begins.
The model gets its name because development flows
downward step by step — like a waterfall — without
going back easily.

Once a phase is completed and the team

moves to the next phase, returning to previous
phases requires significant effort and
documentation updates.
Real-World Example
Government Tax System
Consider developing a national tax management system for a government:

Legal Requirements Detailed Design

Must be fully approved before development begins Comprehensive documentation required for all
components

Auditor Traceability Formal Testing

Complete documentation trail for regulatory Strict acceptance testing protocols must be followed
compliance

In this scenario, requirements are stable, regulatory documentation is mandatory, and formal approval is essential. The
Waterfall Model is appropriate for such regulated environments.
Advantages

Clear Milestones Easy to Manage

Well-defined phases make it easy to track progress Linear structure simplifies project planning and
and set expectations resource allocation

Well-Documented System Suitable for Regulated Systems

Comprehensive documentation supports maintenance Formal approvals and traceability meet regulatory
and knowledge transfer requirements
Disadvantages
1

Poor at Handling Changing Requirements

Difficult and expensive to accommodate changes once development has started

Working Software Appears Late

Users don't see working software until late in the development cycle

High Risk if Requirements Misunderstood

Errors in requirements specification can lead to costly rework
2. Incremental Development Model

Incremental Delivery Evolutionary Development

System delivered in parts to customers System evolves through continuous feedback

Core Idea
Instead of building everything at once:
Build Deliver

Improve & Add Get Feedback

Build → Deliver → Get Feedback → Improve → Add More
2. Incremental Development Model
Example –
Mobile Banking App
Reuse-Oriented Software Engineering
Also called: Integration and configuration model. Focus: assemble systems from existing components
rather than building from scratch.

Core Practices Key Principle

Reuse existing components, integrate Do not reinvent the wheel — prefer proven
systems, configure COTS products. solutions.

Important Concept
Requirements may change based on available components (unlike waterfall).

Process Activities

1. Requirements specification
2. Component analysis
3. Requirements modification
4. System design with reuse
5. Development and integration
Reuse-Oriented Software Engineering
Thank you
for your
attention!