Chapter 2-
Software
Processes
CSC3324
Dr Houda CHAKIRI
2
What could go wrong in a
software development project?
EnTech is a software Development company. It has a team of 25 Developers. Dr
Karim Laaboudi has recently established a dental clinic in Rabat and asked EnTech
to develop a management system for his clinic. Karim’s request was to develop a
system to manage patient records and perform administrative functions similar to
‘what is being used in other clinics’ but within a budget of 50k MAD and delivered
within 3 months.
EnTech adopts an ad hoc approach to software development and has not worked
on large scale projects before.
What problems do you anticipate in this project?
3
How can we overcome problems with ad
hoc software development?
Problems?
Difficulty to distinguish between tasks → important tasks may be ignored.
Inconsistent schedules, budgets, functionality and product quality.
Delayed problem discovery → more costly to fix.
Solution?
Software Process Model
“an abstract representation of a process. It presents a description of a process from
some particular perspective.”
Software Process Models provide guidelines to organize how software process
activities should be performed and in what order.
Basic Problem-Solving Flow
WHAT
HOW
DO
TEST
USE
Software Development Life Cycle (SDLC)
A broad general framework
that outlines the phases
involved in the
development of software
applications. It provides a
structured approach to
software development.
• SDLC can encompass
various methodologies,
including Waterfall, V-
Model, Iterative Model,
Spiral, among others.
Chapter 2 Software Processes 5
The Software Process (Simplified)
Feasibility and
Planning Requirements
Design
Operation and
Implementation Maintenance
Processes,
Phases,
Activities &
Tasks
A process is made up of phases. A phase is made up of activities. An
activity is made up of tasks.
Chapter 2 Software Processes 7
what is needed to complete
the task: time, people,
technology, knowledge, and
money
Responsibilities of Outcomes of a process
the people involved activity/task
in the process
Pre- and post-conditions, which are statements that are true
before and after a process activity has been enacted or a
product produced.
Chapter 2 Software Processes 8
Phase: Requirement Analysis
Activity 1: Collecting User Requirements
✓ T 1: Conduct stakeholder interviews
✓ T2: Analyze business needs
✓ T3: Document functional and non-functional requirements
Activity 2, Activity 3…..
Pre-condition:
1. The client or stakeholder must provide business needs.
2. The project team must be assigned for requirement gathering.
3. Tools for documentation must be available.
Post-condition:
1. A finalized Software Requirements Specification (SRS) document
is created.
2. Stakeholders approve the documented requirements.
3. The development team can start designing the system based on
approved requirements.
Chapter 2 Software Processes 9
Types of Process Models
Designing a process can start from scratch or may be based on one of
the many process models that have already been used successfully.
3 types of PMs are:
• Linear process models
• Iterative process models
• Parallel process models
Chapter 2 Software Processes 10
Plan-driven and Agile processes
• Plan-driven processes are processes where all the process
activities are planned, and progress is measured against
this plan.
• Agile processes: planning is incremental, and it is easier to
change the process to reflect changing customer
requirements.
Chapter 2 Software Processes 11
Software Process Models
• The waterfall model: Plan-driven model. Separate and
distinct phases of specification and development.
• Incremental development: Specification, development
and validation are interleaved. May be plan-driven or agile.
• Reuse-oriented software engineering/Integration and
configuration: The system is assembled from existing
components. May be plan-driven or agile.
Chapter 2 Software Processes 12
The waterfall Model
Chapter 2 Software Processes 13
Waterfall Model Discussion
Pros Cons
• Simple and Easy to • Inflexibility
Understand • Late Testing
• Well-Defined Stages
• High Risk
• Structured Approach
• Poor Adaptability
• Ease of Management
• Customer
Involvement
Chapter 2 Software Processes 14
Incremental Development
Chapter 2 Software Processes 15
Incremental Development Discussion
Pros Cons
• Reduced Cost of • Lack of Process
Accommodating Visibility
Changing Requirements
• Degradation of
• Easier Customer System Structure
Feedback
• Rapid Delivery and
Deployment
Chapter 2 Software Processes 16
Iterative Models
ex: Spiral Model
One of the earliest
models to propose
iterative development;
developed by Barry
Boehm (86), it includes
a mix of waterfall and
iterative approaches.
17
Spiral Model phases • Communication btw customer & project manager
• Collect all req from customer
• Analyses estimated cost, schedule & required
resources
• Identification of all the potential
Req Gathering risks
& Analysis • Risk mitigation strategy is
planned for solving risks
• Design a prototype
Development start
• Designer designs the product
as per final prototype,
• Developer perform actual
coding /implementation,
• Tester perform all testing
methods
• Deploy or release product to
the customer environment.
Take a feedback from customers -- Iterate
18
Chapter 2 Software Processes 19
Chapter 2 Software Processes 20
Spiral Model Discussion
Pros Cons
• Highly Risk focused • Requires extensive
expertise/risk
• More Customer
involvement • Costly for small
projects
• Early detection of • Undefined End
issues
• Time-consuming
• Allows extensive use • Requires intensive
of prototypes documentation
• More flexibility • Complexity
Reuse-Oriented Software Engineering
Chapter 2 Software Processes 22
Types of software components
• Web services that are developed
according to service standards and which
are available for remote invocation.
• Collections of objects that are developed
as a package to be integrated with a
component framework such as .NET or
J2EE.
• Stand-alone software systems (COTS)
that are configured for use in a particular
environment.
Chapter 2 Software Processes 23
Reuse-Oriented Software Engineering
Discussion
Pros Cons
• Standardization • Hidden Costs
• Focus on High-Level • Quality Variability
Design • Licensing and Legal
• Increased Reliability Concerns
• Cost Savings • Dependency on Third-Party
• Reduced Components
Development Time • Compatibility Issues
• Limited Control
Chapter 2 Software Processes 24
The V-model is a type of SDLC model where the process
executes sequentially in a V-shape. It is also known as the
Verification and Validation model.
It is based on the association of a testing phase for each
V-Model corresponding development stage
Chapter 2 Software Processes 25
V-Model Discussion
Pros Cons
• Structured and • Rigid Structure
Disciplined Approach • Poor Fit for Complex
• Clear Phases Projects
• Early Detection of • High Dependence on
Issues Requirements
• Emphasizes Testing • Not Ideal for Iterative
• Suited for Small to Development
Medium Projects • Testing is Late in the
Process
Chapter 2 Software Processes 26
Sawtooth
model
• A variation of the
V-Model, designed
to address some of
the limitations of
traditional
sequential models.
Chapter 2 Software Processes 27
Sawtooth Model Discussion
Pros Cons
• Iterative Feedback • Higher Complexity
• Adaptable to • Increased Time and
Changes Resources
• Requires Strong
• Incorporates Both Management
Development and
• Not Ideal for Rapid
Testing Prototyping
• Better Suited for • Limited Flexibility
Complex Systems Compared to Agile
Process
Activities
Chapter 2- Software Processes
Chapter 2 Software Processes 29
Process Activities
• The four basic process activities
of specification,
Implementation, validation and
evolution are organized
differently in different
development processes.
Chapter 2 Software Processes 30
The Requirements Engineering Process
What do the system stakeholders
require or expect from the system?
Defining the
requirements in detail
Is it technically Checking the validity
and financially of the requirements
feasible to build
the system?
Chapter 2 Software Processes 31
Software Design and
Implementation
The process of converting
the system specification
into an executable
system.
• Software design: Design
a software structure that
realises the
specification;
• Implementation:
Translate this structure
into an executable
program; 32
A General
Model of
the Design
Process
Chapter 2 Software Processes 33
Software testing
Individual Testing with customer
components are data to check that the
tested system meets the
independently customer’s needs.
Testing of the
Stages of testing system as a whole.
Chapter 2 Software Processes 34
Software Evolution
As requirements change through changing business circumstances,
the software that supports the business must also evolve and
change.
35
Coping with
change
Chapter 2- Software Processes
Chapter 2 Software Processes 36
Coping with Change leads to rework so the costs of
change change include both rework (e.g. re-
analyzing requirements) as well as the
costs of implementing new functionality
Business changes
lead to new and
changed system
requirements.
New technologies
open new
possibilities for
improving
implementations
Chapter 2 Software Processes 37
Reducing the costs of rework:
Software prototyping
• A prototype is an initial version of a system used to demonstrate concepts
and try out design options. A prototype can be used in:
• The requirements engineering process to help with requirements
elicitation and validation;
• In design processes to explore options and develop a UI design;
• In the testing process to run back-to-back tests.
38
Benefits of prototyping
Improved A closer match
system to users’ real
usability. needs.
Improved Improved
design quality. maintainability
Reduced
development
effort.
Chapter 2 Software Processes 39
Prototype
Development
Rapid Prototyping: Utilizes rapid prototyping languages or tools.
May exclude certain functionalities, focusing on less-understood
areas of the product. Non-functional requirements like error
checking and recovery might be omitted.
Throw-away Prototypes: Designed to be discarded post-
development.
Not suitable for production systems due to:
• Difficulty in meeting non-functional requirements.
• Lack of documentation.
• Degraded structure through rapid changes.
• Failure to meet organizational quality standards.
Chapter 2 Software Processes 40
Incremental Development and Delivery
• Development is divided into small,
functional increments.
• High-priority requirements are tackled
first.
• Requirements for each increment are
fixed once development begins.
• Each increment is built and evaluated
before starting the next (Typically used
in agile methods.)
• Each increment is deployed for real
user feedback.
Chapter 2 Software Processes 41
Incremental Delivery
Chapter 2 Software Processes 42
Chapter 2 Software Processes 43
Chapter 2 Software Processes 44