Assignment 1 – Software Process Models

1. Pros and Cons of Different Software Process Models

el Pros Cons Why Use It
erfall Model Simple and <font color='blue'><b>easy to follow</b></font>.
Rigid, <font color='red'><b>no
Phases are <font
going
color='blue'><b>well-structured</b></f
back</b></font>.
Use whenTesting
<font color='gree
is <font c
odel Strong <font color='blue'><b>testing at every Very
stage</b></font>.
<font color='red'><b>rigid</b></font>.
Detects <font color='blue'><b>defects
Costly
Use for
for<font
changes.
early</b></fon
color='green'
Requires
emental Model Software delivered in <font color='blue'><b>parts</b></font>.
Needs planning. Easier
<font color='red'><b>Integration
debugging and testing.
UseUsers
issues</b></font>
for <font
get <font
color='green'
color='bl
may
tive Model Provides <font color='blue'><b>early version quickly</b></font>.
Resource-heavy. RiskAllows
of <font
<fontcolor='red'><b>scope
color='blue'><b>requirement
Use when
creep</b></font>.
<font color='gree
changes<
otype Model Helps <font color='blue'><b>clarify requirements</b></font>.
Can increase cost
Users
withsee
many
<font
prototypes.
color='blue'><b>early
Not Best
goodfor
for<font
<font
models</b></font
color='green
color='red'>
al Model Strong focus on <font color='blue'><b>risk analysis</b></font>.
Expensive and <fontCombines
color='red'><b>complex</b></font>.
<font color='blue'><b>iterative
Use for <fontNeeds
color='green'
+ waterfall<
expert
eme ProgrammingContinuous
(XP) <font color='blue'><b>feedback and
Needs
testing</b></font>.
skilled team. Can
Very
be <font
stressful.
color='blue'><b>flexible</b></font>.
Not for Use
<fontfor
color='red'><b>big
<font color='green'
H
te
Bang Model Very <font color='blue'><b>simple</b></font>.High
Minimal
risk of
planning.
<font color='red'><b>failure</b></font>.
Flexible for small test projects.
Good for
Not<font
for <font
color='green
color='
(Rapid Application
Very
Development)
<font color='blue'><b>fast delivery</b></font>.
Needs skilled
Strong developers.
user involvement.
Not forQuick
<font prototypes.
color='red'><b>complex
Use when <font color='gree
projects
e Model Highly <font color='blue'><b>flexible</b></font>.
HardContinuous
to predict cost/time.
involvement.
Needs
Frequent
<font color='red'><b>constant
workingBest
releases.
for <font color='green
commun
m Model Strong <font color='blue'><b>team collaboration</b></font>.
Needs strong discipline.
Short <font
Daily
color='blue'><b>sprints</b></font>.
meetings can be
Usetiring.
when <font color='gree
Adapts t
ban Model Visual <font color='blue'><b>workflow</b></font>.
Not ideal
Flexible
for <font
and simple.
color='red'><b>strict
Good for ongoing
deadlines</b></font>.
maintenance.
Use for <font color='green'
n Model Focuses on <font color='blue'><b>efficiency</b></font>.
Can be hardReduces
to scale.<font
Requires
color='blue'><b>waste</b></font>.
discipline. Use for <font color='green'
Faster de
Ops Model Continuous <font color='blue'><b>integration Needs
& delivery</b></font>.
infrastructure and
Faster
<fontdeployment.
color='red'><b>tools</b></font>.
Collaboration
Use for <font
between
color='green'
Notdev
fora

2. Which Model Would I Adopt and Why?

If I were working with a small student team with limited resources, I would choose the
Prototype Model.

This is because as students, we often don’t have clear or fixed requirements at the start. Clients
(like teachers or end-users) may change their minds after seeing the first version. Prototypes let us
show an early working model, which helps refine the requirements. It reduces misunderstandings
and ensures the final system matches user needs.

■ In short: Prototype Model is best for student projects because it allows changes, ensures
better communication, and is cost-friendly for small projects.