Process Models

SE550 - Software Engineering

by Selma Nazlıoğlu

2024-25 Fall
What are the
elements of a
software
process?

2
To begin with …

What is a
process?

3
A Generic
Process Model
A software process - a
collection of activities,
tasks to create a product,
a roadmap to create a
product effectively

Process Framework -
communication with
customer, planning, modeling,
development, deployment

4
A Generic
Process Model
- sw project tracking and
control (progress
schedule)
Umbrella activities - risk management
- applied - sw quality assurance
throughout - technical reviews (uncover
software project errors)
and help team - measurement,
manage and control - sw configuration
progress, quality, management(manage
effects of change),
risk and change - reusability management
- work product preparation
and production

5
A Generic
Process Model
Tasks
- Actual work to be done to accomplish
objectives
- Work products to be produced
- Quality assurance filters to be applied

6
A Generic
Process Model
Tasks
- Actual work to be done to accomplish
objectives
- Work products to be produced
- Quality assurance filters to be applied

Interaction of tasks: Flow

- linear
- iterative
- evolutionary
- parallel

7
A Generic
Process Model
● Linear - in sequence
● Iterative - repeat one or more of activities
before proceeding to the next
● Evolutionary - in a circular manner - each
circle => more complete version
● Parallel - one or more activities in parallel
with other activities

8
Process Pattern
But first … what is a pattern?

9
Process Pattern

A solution to a recurring problem

10
Process Pattern
a recurring process model to solve a
problem = to accomplish a task
- Identifies the environment and possible
solution(s)
- a template - a consistent method for
describing problem solutions within the
context of the software process

11
Process Models
Prescriptive Models
- advocate an orderly approach to software engineering - structural
- prescribe a set of process elements - framework activities, actions and tasks

Questions

- If prescriptive process models strive for structure and order, are they
inappropriate for a software world that thrives on change?
- Yet, if we reject traditional process models (and the order they imply) and
replace them with something less structured, do we make it impossible to
achieve coordination and coherence in software work?

13
Waterfall Model
Linear Fashion

Pros Cons

14
Waterfall Model
Linear Fashion

Pros Cons
● It is easy to understand and plan. ● It does not accommodate change
● It works for well-understood small well.
projects. ● Testing occurs late in the process.
● Analysis and testing are ● Customer approval is at the end.
straightforward.

15
V Model Same as Waterfall with a difference of
how verification and validation actions
are applied to earlier work!

Pros

Cons

Linear Fashion 16
V Model Same as Waterfall with a difference of
how verification and validation actions
are applied to earlier work visually!

Pros
● It is easy to understand and plan.
● It works for well-understood small
projects.
● Analysis and testing are
straightforward.

Cons
● It does not accommodate change
well.
● Testing occurs late in the process.
● Customer approval is at the end.

Linear Fashion 17
Incremental Model
● Need to provide a limited set of
functionalities to users quickly
● Then refine and expand on
that functionality in later
software releases

Deliverable increments
● 1st increment = core product
● nth increment = core product +
more features
● Up to a complete product
Linear & Parallel Fashion
18
Incremental Model

19
Incremental vs Iterative

20
Incremental & Iterative

21
Evolutionary Models
Prototyping
Pros
● Reduced impact of requirement
changes.
● Customer is involved early and often.
● Works well for small projects.
● Reduced likelihood of product
rejection.

Cons
● Customer involvement may cause
delays.
● Temptation to “ship” a prototype.
● Work lost in a throwaway
prototype.
Iterative & Evolutionary Fashion ● Hard to plan and manage.

22
Evolutionary Models
Prototyping
Pros
● Reduced impact of requirement
changes.
● Customer is involved early and often.
● Works well for small projects.
● Reduced likelihood of product
rejection.

Cons
● Customer involvement may cause
delays.
● Temptation to “ship” a prototype.
● Work lost in a throwaway
prototype.
Iterative & Evolutionary Fashion ● Hard to plan and manage.

23
Evolutionary Models
Spiral
● Combined iterative fashion with
systemics aspects of waterfall
model
● Increasingly more complete
versions of software/product
● Early releases can be models or
prototypes, later releases
include increasingly more
complete version of the system
● Risk analysis is conducted for
each round
○ emphasis on risk
Iterative & Evolutionary Fashion
24
Evolutionary Models
Spiral
Pros
● Continuous customer involvement.
● Development risks are managed.
● Suitable for large, complex
projects.
● It works well for extensible
products.

Cons
● Risk analysis failures can doom
the project.
● Project may be hard to manage.
● Requires an expert
Iterative & Evolutionary Fashion development team.

25
Evolutionary Models
Spiral
Pros
● Continuous customer involvement.
● Development risks are managed.
● Suitable for large, complex
projects.
● It works well for extensible
products.

Cons
● Risk analysis failures can doom
the project.
● Project may be hard to manage.
● Requires an expert
Iterative & Evolutionary Fashion development team.

26
Evolutionary Models
Concurrent
● All software engineering activities exist
concurrently but in different states
Example - early in the project
● Communication - awaiting changes
● Modeling - None
○ then => under development
○ then may be => awaiting changes
Pictures a complete state of current activities
● network of actions
Better for product engineering projects involving
multiple different teams

Iterative & Evolutionary Fashion 27

Other Models?
● Component based development - how about component-oriented?
○ the process to apply when reuse is a development objective
● Formal methods
○ emphasizes the mathematical specification of requirements, and verification
● Aspect-oriented Software Development (AOSD)
○ provides a process and methodological approach for defining, specifying,
designing, and constructing aspects
● Unified Process
○ a “use-case driven, architecture-centric, iterative and incremental” software
process closely aligned with the Unified Modeling Language (UML)

28
Unified Software
Development Process
elaboration
The phases
Inception - determining the scope and
inception
purpose of the project
Elaboration - requirements capture
and determining the structure of the
system
Construction - build the software
system

Transition - product installation and

rollout

Captures many elements of best practice

29
Unified Software Development Process
elaboration

Pros
inception
● Quality documentation emphasized.
● Continuous customer involvement.
● Accommodates requirements
changes.
● Works well for maintenance projects

Cons
● Use cases are not always precise.
● Tricky software increment integration.
● Overlapping phases can cause
problems.
● Requires expert development team

use-case driven, architecture-centric, iterative and incremental 30

Unified Software Development Process
elaboration

Pros
inception
● Quality documentation emphasized.
● Continuous customer involvement.
● Accommodates requirements
changes.
● Works well for maintenance projects

Cons
● Use cases are not always
precise.
● Overlapping phases can cause
problems.
● Requires expert development
team

use-case driven, architecture-centric, iterative and incremental 31

Unified Software Development Process
Work Products

32
Unified Software
Development Process

The balance of effort spent in each

workflow varies from phase to phase 33
USDP vs Waterfall

Waterfall
34
USDP vs Waterfall

Waterfall
35
Personal Software Process
Planning High-level design

- isolates requirements and develops - An external specification is created

both size and resource estimates. for each component and a component
- a defect estimate (the number of design is created.
defects projected for the work) is - Prototypes are built when uncertainty
made. exists.
- all metrics are recorded on - All issues are recorded and tracked
worksheets or templates.
- development tasks are identified
and a project schedule is created.

personal measurement of work and

quality of resulting work 36
Personal Software Process
High-level design review Development.

- Formal verification methods are - The component level design is refined

applied to uncover errors in the and reviewed.
design. - Code is generated, reviewed,
- Metrics are maintained for all compiled, and tested.
important tasks and work results. - Metrics are maintained for all
important tasks and work results.

Postmortem.

- Using measures and metrics collected the effectiveness of the process is

determined.
37
Personal Software Process
High-level design review Development.

- Formal verification methods are - The component level design is refined

applied to uncover errors in the and reviewed.
design. - Code is generated, reviewed,
- Metrics are maintained for all compiled, and tested.
important tasks and work results. - Metrics are maintained for all
important tasks and work results.

identify errors early and make developer understand

types of likely errors
not widely adapted due to challenges
38
Team Software Process
objectives
- Build self-directed teams that plan and track their work, establish goals, and
own their processes and plans. These can be pure software teams or
integrated product teams (IPT) of three to about 20 engineers.
- Show managers how to coach and motivate their teams and how to help
them sustain peak performance.
- Accelerate software process improvement by making CMM Level 5 behavior
normal and expected.
- Provide improvement guidance to high-maturity organizations.
- Facilitate university teaching of industrial-grade team skills.

TSP framework activities: project launch, high level design, implementation, integration,
test and post-mortem
39
Discussion Question
● Let’s work on the discussion questions …

40
Next Week
Agile Development