Topic Two: Software Process

Topic Outline
1. Introduction to Software Process
2. Software process models,
3. Process activities,
4. Coping with change,
5. Rational Unified Process (RUP)

1. Definition: Software Process

A Software Process is a structured set of activities required to develop, maintain, and retire a
software product.
It provides a framework for planning, managing, and controlling the development and
maintenance of software systems.
A Software Process (also called a software development process or software lifecycle) is a
framework that defines the steps involved in producing software, including:
1. Requirements Gathering: The first stage where the business owners and developers
meet to discuss the goals and requirements of the website.
2. Design: Second stage, the developers create a preliminary design of the website based on
the requirements gathered in stage 1.
3. Implementation: Third stage, the developers begin to build the website based on the
design created in stage 2.
4. Testing: Fourth stage to ensure that it meets the requirements and functions properly.
5. Deployment: Fifth stage deployed and made live to the public.
6. Review and Improvement: Six stage oversee the business owners and developers
review its performance and make any necessary improvements.

Software Process Activities

These are the four fundamental activities common to all software processes:

Activity Description
Software Specification The process of defining what the system should do. Involves
requirement gathering, analysis, and documentation.
Software Design and Translating the specification into a working system through
Implementation system design and programming.
Software Validation Ensuring the software meets customer requirements through
testing, reviews, and inspections.
Software Evolution Modifying the software after deployment to fix issues or enhance
features (maintenance).

Importance of Software Process

 Ensures quality and consistency
 Provides a predictable structure to development
 Helps manage risks and resources
 Facilitates team collaboration

1
  Enables better planning and control

3. Software Process Models (Life Cycle Models)

A Software Process Model is an abstract representation of a process. Each model represents a

different way of organizing the software development process.

Types of Software Process Model

a) Waterfall Model
The Waterfall Model is a linear and sequential approach to software development. Each phase
must be completed before the next phase begins, and there is no overlapping or iterative step.

Phases of the Waterfall Model

1. Requirements Analysis
o Collect and document all software requirements.
o Output: Software Requirements Specification (SRS) document.
2. System Design
o Convert requirements into system architecture and design.
o Output: System and software design documents.
3. Implementation (Coding)
o Developers write code based on the design.
o Output: Source code.
4. Integration and Testing
o Combine modules and test the system as a whole.
o Output: Test reports.
5. Deployment
o Deliver the software to the client or deploy to production.
o Output: Working software product.
6. Maintenance
o Ongoing support, bug fixes, updates, and enhancements.
o Output: Updated software versions.

Diagram: Waterfall Model

2
Arrows flow from top to bottom in a single direction — like a waterfall.
Advantages of the Waterfall Model
 Simple and easy to understand and use
 Structured approach – clear deliverables for each phase
 Good for small projects with well-understood requirements
 Easy to manage due to rigidity
Disadvantages of the Waterfall Model
 No room for changes once the process begins
 Late discovery of problems (during testing)
 Poor model for long-term or complex projects
 Not suitable for projects with evolving requirements
Best Use Cases
 Projects with fixed, clear, and well-documented requirements
 Short-term software projects
 Government and military software systems (where strict documentation is required)

b) Iterative Model

The Iterative Model develops a system through repeated cycles (iterations). Each iteration
delivers a working version of the software, which is then reviewed and refined in the next
[Link] the Waterfall Model, the Iterative Model welcomes changes and allows feedback
and improvement throughout the process.

Key Characteristics of the Iterative Model

 Software is built and improved in small parts

 Partial implementation is done in early stages
 Each iteration goes through the full development cycle:

1. Requirements Gathering: This is the first stage where the business owners and developers
meet to discuss the goals and requirements of the website.
2. Design: In this stage, the developers create a preliminary design of the website based on
the requirements gathered in stage 1.
3. Implementation: In this stage, the developers begin to build the website based on the
design created in stage 2.
4. Testing: Once the website has been built, it is tested to ensure that it meets the
requirements and functions properly.
5. Deployment: The website is then deployed and made live to the public.
6. Review and Improvement: After the website has been live for a while, the business
owners and developers review its performance and make any necessary improvements.

3
Diagram: Iterative Model

Feedback Loop and Continuous Improvement

Advantages of the Iterative Model

 Early delivery of working software

 Easier to test and debug smaller iterations
 Allows for changing requirements
 Regular user feedback leads to better products
 Risk is reduced in early stages

Disadvantages of the Iterative Model

 Requires careful planning and management

 Risk of scope creep if changes are not controlled
 Full system architecture may not be well-defined at the beginning
 Integration between iterations may become complex

Best Use Cases

 Projects with partially known or evolving requirements

 Projects needing early user feedback
 Long-term projects where flexibility is crucial
 Systems that benefit from gradual refinement

c) Spiral Model

Definition:

The Spiral Model is a software development model that emphasizes risk assessment and
management throughout the development lifecycle. It develops software through repeated
spirals (cycles), each consisting of:

1. Planning
4
 2. Risk analysis
3. Engineering (development/testing)
4. Evaluation (customer feedback)

Phases in Each Spiral Loop

Each loop or “spiral” represents one phase of the software process. The size of the spiral
increases as the project progresses.

Quadrants of a Spiral:

1. Determine Objectives & Alternatives

→ Define goals, functionalities, constraints
2. Identify & Resolve Risks
→ Analyze technical/management risks and create prototypes if needed
3. Develop & Test
→ Develop the next version or module and test it
4. Evaluate & Plan Next Iteration
→ Review with customer; decide whether to continue, adjust, or stop

Diagram: Spiral Model

Advantages of the Spiral Model

 Strong emphasis on risk management

 Ideal for large, complex, and high-risk projects
 Supports iterative refinement
 Continuous customer involvement

5
  Flexibility in changes throughout development

Disadvantages of the Spiral Model

 Can be costly and time-consuming

 Requires expertise in risk analysis
 Complex model – hard to manage for small projects
 Not suitable for low-budget or low-risk projects

Summary
Feature Spiral Model
Development Style Iterative with Risk Management
Focus Risk mitigation, prototyping
Flexibility High
Customer Involvement High
Final Delivery After several spirals

d) Agile Model

A family of lightweight methodologies that emphasize iterative development, collaboration,

and customer feedback.

Core Principles (from Agile Manifesto):

 Individuals and interactions over processes and tools

 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan

Advantages:

6
  Highly flexible
 Customer feedback-driven
 Frequent deliveries

Disadvantages:

 Can lack documentation

 Requires experienced teams
 Scope creep possible

e) V-Model (Validation & Verification)

V-Model (or Validation and Verification Model) is a software development process that is an
extension of the Waterfall Model. Instead of being a linear downward flow of phases, the V-
Model bends upwards after the coding phase to form a V shape, which highlights the relationship
between each development stage and its corresponding testing phase.

The V-Model emphasizes verification and validation at each step of development. For every
development activity on the left side, there is a corresponding testing activity on the right side.

Left Side Right Side (Testing)

(Development)
Requirements Acceptance Testing
High-Level Design System Testing
Detailed Design Integration Testing
Implementation Unit Testing

Advantages of the V-Model

7
  Clear relationships between development and testing.
 Testing is planned early, improving quality.
 Works well for projects with clear, stable requirements.
 Easy to manage due to its structured approach.

Disadvantages of the V-Model

 Rigid and less flexible to changes.

 Not suitable for projects where requirements evolve frequently.
 No early working software — testing starts after development.

V-Model is Best For:

 Embedded systems
 Government projects
 Projects with well-defined and stable requirements

f)DevOps Model

DevOps Model is a software development approach that emphasizes collaboration between

Development and Operations teams to automate and integrate the processes of software
development, testing, deployment, and infrastructure management.

It focuses on continuous delivery, automation, monitoring, and rapid feedback, enabling

faster and more reliable software releases.

Core Concepts:

 Automation
 Continuous Integration/Continuous Deployment (CI/CD)
 Collaboration between Dev and Ops
 Monitoring and feedback loops

8
Advantages ofDevOps

 Faster delivery of features and updates

 Improved collaboration and communication
 Reduced deployment failures and rollbacks
 Faster recovery from incidents
 Increased automation and efficiency

Disadvantagesof DevOps

 Cultural resistance to change

 Complexity of toolchains and automation
 Security concerns in fast-moving environments
 Requires significant skill and tooling investment

DevOps is Best For:

 Cloud-native applications
 Agile and lean development teams
 Startups and enterprises wanting rapid delivery
 Continuous customer feedback environments

Characteristics of a Good Software Process

A good software process should:

 Be predictable and repeatable

 Deliver high-quality software
 Allow early error detection
 Support process improvement
 Be scalable and adaptable

5. Software Process Assessment & Improvement

Models for Assessing and Improving Processes:

Model Description
CMMI (Capability Maturity Model Assesses organizational maturity on 5 levels (Initial
Integration) → Optimizing)
ISO/IEC 12207 International standard for software lifecycle
processes
SPICE (ISO/IEC 15504) Framework for software process assessment

Software Process vs. Software Methodology

9
 Aspect Software Process Software Methodology
Definitio A framework of activities for A specific approach or set of practices for
n software development implementing the process
Examples Waterfall, Agile, Spiral Scrum, XP, RAD
Scope High-level lifecycle management Detailed technical practices and roles

7. Summary Table

Topic Description
Software Process Structured set of activities for software development
Core Activities Specification, design/implementation, validation, evolution
Models Waterfall, Agile, Spiral, V-Model, DevOps
Good Process Predictable, efficient, adaptable, quality-oriented
Process Done using models like CMMI, ISO 12207
Improvement

2. Process activities

In software engineering, process activities refer to the essential tasks or phases that are
followed during the development of a software system. These activities are part of a software
process model (like Waterfall, Agile, etc.) and help ensure that the development is systematic,
efficient, and delivers a high-quality product.

Main Process Activities in Software Engineering

1. Software Specification (Requirements Engineering)

o Define what the system should do.
o Involves:
 Requirements gathering
 Requirements analysis
 Requirements specification
 Requirements validation
o Output: Software Requirements Specification (SRS)
2. Software Design and Architecture
o Translate requirements into a blueprint for building the software.
o Includes:
 High-level design (system architecture)
 Low-level design (detailed component/module design)
o Output: Design documents (UML diagrams, architecture diagrams, etc.)
3. Software Implementation (Coding)
o Actual development of the software by writing code.
o Tools: IDEs, programming languages, version control (e.g., Git)
o Follow coding standards, best practices, and perform unit testing.
4. Software Validation (Testing)
o Ensure the software meets the requirements and works correctly.

10
 oLevels of testing:
 Unit testing
 Integration testing
 System testing
 Acceptance testing
o Output: Test plans, test cases, test reports
5. Software Evolution (Maintenance)
o Updating and improving software after deployment.
o Types:
 Corrective (fixing bugs)
 Adaptive (modifying for new environments)
 Perfective (enhancing features)
 Preventive (improving future maintainability)

Supporting Activities (Cross-cutting)

 Project Management – Planning, monitoring, and controlling the development process.

 Configuration Management – Managing changes to software artifacts.
 Quality Assurance – Ensuring quality standards and practices are followed.
 Documentation – Creating and maintaining documents throughout the lifecycle.

Summary Table

Activity Purpose Key Output

Specification Define what the system should do SRS document
Design Plan how the system will be built Design docs, models
Implementation Develop the system (write code) Source code
Validation (Testing) Ensure system correctness Test cases, test results
Evolution Update and improve system post- Updated code and
(Maintenance) release documentation

3. Coping with Change in Software Engineering

Change is inevitable in software engineering. Requirements evolve, technologies advance,

business goals shift, and user expectations grow. Successfully coping with change is essential to
deliver adaptable, sustainable, and valuable software systems.

Key Strategies to Cope with Change

1. Anticipating Change

 Requirements may change, especially in long projects.

 Design and develop software with flexibility in mind.
 Use techniques like:
o Modular design – breaking software into independent components.

11
 o Loose coupling – minimizing dependencies between components.
o Design patterns – reusable solutions to common problems.

2. Change Management Process

A formal process to handle changes in requirements, design, or implementation.

Steps include:

 Change Request: Documented proposal for a change.

 Impact Analysis: Assess technical, cost, and schedule implications.
 Approval/Rejection: By stakeholders or a Change Control Board (CCB).
 Implementation: Make the change if approved.
 Validation: Test to ensure the change works and doesn’t break anything.

3. Configuration Management

Helps manage versions and changes of software artifacts (code, documents, configs).

 Tools: Git, SVN, Mercurial

 Key concepts:
o Version control
o Change tracking
o Baselining (snapshotting a stable version)
o Branching and merging

4. Iterative and Incremental Development

Frameworks like Agile and Scrum are built to handle change effectively.

 Develop software in small iterations (sprints).

 Get frequent feedback from users.
 Embrace evolving requirements.

5. Prototyping and User Involvement

 Build early prototypes to gather user feedback.

 Involve users regularly to validate evolving requirements.

6. Refactoring

 Continuously improve the internal structure of the code without changing its behavior.
 Keeps codebase clean, maintainable, and easier to modify when changes are required.

12
Example Scenario

Before: A system is built with hard-coded tax rules.

Change: Government updates tax policy.

Poor response: Whole system must be modified in many places.

Good response: Tax logic is separated into a module. Change only that module and redeploy —
minimal impact.

Summary Table
Strategy Purpose
Modular/Decoupled Design Makes software easier to change
Change Management Process Structured handling of change requests
Configuration Management Track and control changes systematically
Agile Development Embrace and adapt to change through iteration
User Feedback & Prototyping Reduce risk of late-stage changes
Refactoring Keeps code maintainable and change-ready

4 Rational Unified Process (RUP) in Software Engineering

The Rational Unified Process (RUP) is a software development process framework

developed by Rational Software (now part of IBM). It provides a structured and disciplined
approach to assigning tasks and responsibilities in a software development organization.

RUP is iterative, use-case driven, and architecture-centric. It promotes high-quality software

that meets the needs of its end users.

Key Characteristics of RUP

Characteristic Description
Iterative Develop software in repeated cycles (iterations), allowing refinement over
time.
Use-case driven Requirements are captured and organized as use cases, which guide
design, implementation, and testing.
Architecture- Focus on building a robust software architecture early in the process.
centric
Risk-driven High-risk elements are addressed early in development.

13
RUP Phases

RUP is divided into four sequential phases, each containing multiple iterations:

Phase Main Goal Key Activities

1. Inception Define the scope and business - Identify key use cases- Estimate cost/time-
case Assess feasibility
2. Elaboration Plan the project and establish - Define architecture- Address risks- Refine
architecture use cases
3. Build the product - Code and test- Develop complete
Construction functionality
4. Transition Deliver to users - Beta testing- Bug fixing- Deployment

Each phase ends with a major milestone to assess progress.

RUP Workflows (Core Disciplines)

RUP defines 9 core workflows (disciplines), grouped into engineering and supporting
workflows:

Engineering Workflows

1. Business Modeling
2. Requirements
3. Analysis & Design
4. Implementation
5. Testing
6. Deployment

Supporting Workflows

1. Project Management
2. Configuration & Change Management
3. Environment (setting up tools, processes, infrastructure)

14
RUP Process Diagram
Time →
Phases: Inception → Elaboration → Construction → Transition
Workflows:
───────────────────────────────────────────────────────
─
Requirements █████ ██████ ██ ░
Design ░██ ███████ █████ ░
Implementation ░ ██ ███████ ███
Testing ░ ░██ ██████ ██████
Deployment ░ ░ ██ ███████

(█ = High activity, ░ = Minimal activity)

Advantages of RUP

 Well-defined and disciplined approach

 Emphasizes documentation, architecture, and planning
 Supports iterative development
 Manages risks early
 Scalable for small to large teams

Disadvantages of RUP

 Can be complex and heavy for small teams or projects

 Requires training and discipline to implement properly
 Emphasis on documentation may slow down rapid development

Summary
Aspect RUP Description
Process type Iterative, incremental, use-case driven
Phases Inception, Elaboration, Construction, Transition
Focus Requirements, architecture, risk management
Key benefit Structured process with focus on quality
Best for Medium to large projects with complex requirements
Review question

15
Question

You are hired as a project lead for a new software product: a web based learning management
system (LMS). The client expects the following:

 The system must be delivered in two major releases over 9 months: first release provides
basic course creation, enrolment, content uploading, and assessments; second release
adds discussion forums, mobile access, and analytics.
 Requirements are not fully stable: some stakeholders are unsure exactly what they want
for analytics and mobile.
 The client values reliability, usability, and wants a maintainable system.
 You must ensure stakeholder satisfaction and manage risks (time, cost, changing
requirements).

You are asked to define the software process and your approach. Specifically on the following
areas

a) Which software process model(s) would you choose, and why?

b) Describe the main process activities you will follow.
c) Explain how you will cope with change in requirements.
d) How you would apply RUP (Rational Unified Process) in this project: phases, iterations,
risk management.
e) Identity and explain any attributes, Ethics and Challenges expected

16