Software Process

Mr HD Masethe

Saturday, 08 February 2025 Dan Masethe

1
Software Engineering: A Practitioner's Approach, 9th Edition

By Roger Pressman and Bruce Maxim

2020

ISBN10: 1260922510 | ISBN13: 9781260922516

06/24/2025 2
 Objectives
l To introduce software process models
l To describe a number of different process models and when they may be
used
l To describe outline process models for requirements engineering, software
development, testing and evolution
l To introduce CASE technology to support software process activities

an Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 3

 Topics covered
l Software process models
l Process iteration
l Software specification
l
Software design and implementation
l Software validation
l Software evolution
l Automated process support

an Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 4

 How should
we define
software?

“Software is a place where dreams are planted and nightmares harvested,

an abstract, mystical swamp where terrible demons compete with magical
panaceas, a world of werewolves and silver bullets.”

Brad J. Cox

Textbook description of software might take the following form:

Software is: (1) instructions (computer programs) that when executed

provide desired features, function, and performance; (2) data structures
that enable the programs to adequately manipulate information, and (3)
descriptive information in both hard copy and virtual forms that describes
the operation and use of the programs

06/24/2025 5
 How do
we define
software
engineering?

The IEEE [IEE93a] has developed the following definition for software
engineering:

Software Engineering : (1) The application of a systematic, disciplined,

quantifiable
approach to the development, operation, and maintenance of software; that is,
the
application of engineering to software. (2) The study of approaches as in (1).

06/24/2025 6
 Software Processes
Coherent sets of activities for specifying, designing, implementing and testing
software systems

06/24/2025 7
 The software process
• A structured set of activities required to develop a
software system
– Specification
– Design
– Validation
– Evolution
• A software process model is an abstract representation of a process. It
presents a description of a process from some particular perspective
 What are
the five
generic process
framework
activities?

06/24/2025 9
 SOFTWARE ENGINEERING PRACTICE
The Essence of Practice

1. Understand the problem (communication and analysis).

2. Plan a solution (modeling and software design).
3. Carry out the plan (code generation).
4. Examine the result for accuracy (testing and quality assurance).

06/24/2025 10
 SOFTWARE PROCESS
STRUCTURE
What is
process
flow?

How does a
framework
activity change as
the nature of the
project changes?

06/24/2025 11
 How does a
framework
activity change as
the nature of the
project changes?
For a small software project requested by one person (at a remote location)
with simple, straightforward requirements, the communication activity might
encompass little more than a phone call or email with the appropriate
stakeholder.
Therefore, the only necessary action is phone conversation, and the work tasks
(the task set ) that this action encompasses are:
1. Make contact with stakeholder via telephone.
2. Discuss requirements and develop notes.
3. Organize notes into a brief written statement of requirements.
4. Email to stakeholder for review and approval.

06/24/2025 12
If the project was considerably more complex with many stakeholders, each
with a different set of (sometime conflicting) requirements, the communication
activity might have six distinct actions:
• inception,
• elicitation,
• elaboration,
• negotiation,
• specification,
• and validation.

Each of these software engineering actions would have many work tasks and a
number of distinct work products.

06/24/2025 13
 Process Patterns

 Process patterns define a set of activities, actions, work tasks, work products
and/or related behaviors
 A template is used to define a pattern
 Typical examples:
 Customer communication (a process activity)
 Analysis (an action)
 Requirements gathering (a process task)
 Reviewing a work product (a process task)
 Design model (a work product)

06/24/2025 14
 Process Assessment

 The process should be assessed to ensure that it meets a set of basic

process criteria that have been shown to be essential for a successful
software engineering.
 Many different assessment options are available:
 SCAMPI
 CBA IPI
 SPICE
 ISO 9001:2000

06/24/2025 15
 PROCESS
MODELS

• PRESCRIPTIVE PROCESS MODELS/“traditional” process models.

1. The Waterfall Model

Why does
the waterfall
model sometimes
fail?

06/24/2025 16
 Waterfall model problems

l Inflexible partitioning of the project into distinct stages

l This makes it difficult to respond to changing customer requirements
l Therefore, this model is only appropriate when the requirements are well-
understood

an Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 17

 The V-model

A variation in the representation of

the waterfall model is called the V-
model.

06/24/2025 18
 2. Incremental Process Models

06/24/2025 19
 3. Evolutionary Process Models

Exploratory development
Objective is to work with customers
and to evolve a final system from an
initial outline specification. Should start
with well-understood requirements
Throw-away prototyping
Objective is to understand the system
requirements. Should start with poorly
understood requirements

06/24/2025 20
 Evolutionary development
Concurr ent
activities

Initial
Specification
version

Outline Intermediate
Development
description versions

Final
Validation
version

an Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 21

 Evolutionary development

l Problems
• Lack of process visibility
• Systems are often poorly structured
• Special skills (e.g. in languages for rapid prototyping) may be required
l Applicability
• For small or medium-size interactive systems
• For parts of large systems (e.g. the user interface)
• For short-lifetime systems

an Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 22

 Two common evolutionary process
models.

06/24/2025 23
06/24/2025 24
 What are
the potential
weaknesses of
evolutionary
process models?
1. Despite the unquestionable benefits of evolutionary software
processes, we have some concerns. The first concern is that
prototyping [and other more sophisticated evolutionary processes]
poses a problem to project planning because of the uncertain
number of cycles required to construct the product . . .
2. Second, evolutionary software processes do not establish the
maximum speed of the evolution. If the evolutions occur too fast,
without a period of relaxation, it is cer- tain that the process will
fall into chaos. On the other hand if the speed is too slow then
productivity could be affected . . .
3. Third, [evolutionary] software processes should be focused on
flexibility and extensibility rather than on high quality. This
assertion sounds scary.

06/24/2025 25
 4. Concurrent Models

06/24/2025 26
 SPECIALIZED PROCESS MODELS
1. Component-Based Development
2. The Formal Methods Model
3. Aspect-Oriented Software Development

06/24/2025 27
 THE UNIFIED PROCESS

06/24/2025 28
 PERSONAL AND TEAM PROCESS MODELS

1. Personal Software Process (PSP) –What framework activities are used

during PSP?
2. Team Software Process

06/24/2025 29
 How to Apply a selected process model to a case study or project

Process Model Best Suited For

Waterfall Well-defined, sequential projects with stable
requirements.

V-Model Safety-critical applications requiring rigorous

verification and validation.

Incremental Large projects where functionality is

delivered in stages.

Agile Dynamic, evolving projects with frequent

feedback cycles.

Spiral High-risk projects needing continuous risk

assessment.

DevOps Projects requiring continuous integration

and deployment

06/24/2025 30
Suppose the project is a “Developing a Word Sense Disambiguation (WSD)
System for Sesotho sa Leboa using corpus-based ensemble methods,
transformer-based architectures, and deep learning models.”

• Which Process Model will be suitable and why:

• Given the dynamic nature of research, evolving linguistic datasets, and the
need for continuous model improvements, an Agile process modelan Agile
model is suitable due to the evolving research and need for iterative
improvements.

• Define Project Requirements & Goals

• Identify key objectives (e.g., improving WSD accuracy for a low-resource
language).
• Understand constraints (e.g., limited annotated corpus, computing
resources)
• Determine success criteria (e.g., F1-score > 85%).

06/24/2025 31
 Map the Project to the Selected Process Model

Agile Phase Application in WSD Project

Sprint Planning Identify tasks (e.g., data preprocessing,
model training).
Sprint Execution Develop and test different models (e.g.,
BiGRU, Transformer-based embeddings).
Daily Stand-ups Team discussions to resolve issues (e.g.,
data sparsity, overfitting).
Incremental Deliverables Deliver working prototypes after each
sprint (e.g., a functional BiGRU model in
Sprint 1).
Customer/Stakeholder Feedback Linguists validate word sense predictions,
suggest improvements.
Sprint Review Analyze model performance (e.g.,
comparing BERT vs. RoBERTa embeddings).
Sprint Retrospective Identify improvements for the next sprint
(e.g., adding more sense-labeled data).
Agile Phase Application in WSD Project

06/24/2025 32
 How will you Execute the Process Model

• Follow the defined stages iteratively (for Agile, run multiple sprints).
• Use appropriate tools (e.g., Jupyter Notebook for model training, Git for
version control).
• Ensure continuous testing and validation to refine models.
👉 Example:
• Sprint 1: Implement baseline models (e.g., FastText, GloVe).
• Sprint 2: Train BiGRU + Attention model.
• Sprint 3: Integrate BERT-based embeddings.
• Sprint 4: Fine-tune the best-performing model.

06/24/2025 33
 How will you evaluate and Improve the Project

• Monitor performance against key metrics (e.g., accuracy, precision, recall).

• Gather stakeholder feedback (e.g., linguists verifying sense
disambiguation).
• Adjust the process if needed (e.g., switch embeddings if one performs
poorly).
• 👉 Example: If BiGRU achieves 84% accuracy, but Hybrid BiGRU +
DeBERTa reaches 85%, prioritize DeBERTa for final deployment.

06/24/2025 34
06/24/2025 35