SOFTWARE Presented by:
DEVELOPMENT Dr. Yasmine Afify
PROCESS MODELS [Link]@uofca
[Link]
SOFTWARE PROCESS
MODEL
Software process model is an abstraction of the
software development process. It is a representation of
the order of activities of the process and
the sequence in which they are performed.
A model will define the following:
•The tasks to be performed
•The input and output of each task
•The pre/post-conditions for each task
•The flow and sequence of each task
SOFTWARE DEVELOPMENT
PROCESS MODELS
The Waterfall model
V-Shape Model
Evolutionary Prototyping
The Spiral Method
Iterations and Increments
Agile Software Development
WATERFALL MODEL
WATERFALL MODEL
•A waterfall model is a sequential approach in
which each step must be completed before
moving on to the next step. It proceeds in
phases.
•The outcome of one step becomes the input for
the next phase in sequence.
•The waterfall model is easy to understand and
follow. It doesn’t require a lot of customer
involvement after specification is done.
•The waterfall model has a rigid structure, it can’t
adapt to changes. There is no way to see or try
the software until the last phase.
•Since it’s inflexible, it should be used in cases
WATERFALL MODEL
When to use:
• When you know exactly what you want the
result to look like.
• Concept and definition are critical for success
(but not speed).
• Developing desktop applications.
V-M0DEL
V-MODEL
Verification Phases
•Requirement Analysis: In the verification phase,
the initial step involves comprehending customer
expectations for our products through extensive
communication with them.
•System Design: Once the customers’
requirements and product expectations are
identified, a comprehensive system design is
created to guide product development.
•Architectural Design: The system design is broken
down into various modules based on their
functions, and the data exchange between these
internal modules and other systems is defined.
•Module Design: Further division of the designs into
V-MODEL
Validation Phases
•Unit Testing: is performed to identify and rectify
code-level or unit-level bugs.
•Integration Testing: is conducted to verify the
internal communication between the different
modules within the system.
•System Testing: assesses both the functional and
non-functional requirements of the developed
application.
•User Acceptance Testing (UAT): assesses the
usability of the developed system in a real-world
context.
V-MODEL
The V-Model is an extension of the Waterfall model.
All the requirements are gathered at the start and
cannot be changed.
It creates a 'V' shape by matching each
development phase with a corresponding testing
phase, ensuring verification throughout the project
lifecycle.
Best Suited For:
• Projects where testing is a critical component.
• Systems requiring high reliability.
• Projects with strict regulatory compliance needs.
INCREMENTAL MODEL
INCREMENTAL MODEL
•Incremental development divides the system’s
functionality into small increments and it delivers
the software in functional parts.
•Features are delivered incrementally. An initial
implementation is developed first, exposing it to
user feedback, and evolving it through new versions.
•The most important functionality is implemented
in the initial increments. The subsequent
increments expand on the previous ones until
everything has been updated and implemented.
INCREMENTAL MODEL
•The incremental model lets stakeholders and
developers see results with the first increment. If
the stakeholders don’t like anything, everyone finds
out a lot sooner.
•It is efficient as the developers only focus on what
is important and bugs are fixed as they arise (but
you need a clear and complete definition of the
whole system before you start)
Best suited for:
•Early delivery of large projects
•Projects with loosely coupled parts
•Projects with complete and clear requirements
ITERATIVE MODEL
ITERATIVE MODEL
•The development process is divided into
small iterations.
•Each iteration represents a percentage of the
overall development process, and the
software is built, tested, and refined in
repeated cycles.
•Complete features are developed in each
iteration.
•This approach allows for continuous
refinement and change of requirements
throughout the development lifecycle,
delivering increasingly upgraded versions
of the software.
ITERATIVE MODEL
The iterative model allows you to see the results at
the early stages of development. This makes it easy
to identify and fix any functional or design flaws. It
also makes it easier to manage risk and change
requirements.
The deadline and budget may change throughout
the development process, especially for large
complex projects.
Best Suited For
•Projects with evolving requirements.
•Projects with flexible deadline.
•Customer willing to be involved in regular feedback
cycles.
SPIRAL MODEL
SPIRAL MODEL
•The spiral model is a risk driven iterative
software process model.
•The spiral model delivers projects in loops. Unlike
other process models, its steps aren’t activities
but phases for addressing whatever problem has
the greatest risk of causing a failure.
•You develop the concept in the first few cycles,
and then it evolves into a fully-functional software
product.
•Though this model is great for managing
uncertainty, it can be difficult to have stable
documentation.
SPIRAL MODEL PHASES
Planning Phase: Initially, objectives and goals
are identified and established. Subsequently,
various alternative approaches that offer the
best potential for achieving these objectives are
presented. This stage heavily relies on ongoing
communication between the customer and the
project management team.
Risk Analysis Phase: During this phase,
potential hazards are identified while planning
and finalizing the risk reduction strategy. Each
identified risk undergoes a thorough
examination, and if necessary, prototypes may
be developed to eliminate any ambiguity in
requirements.
SPIRAL MODEL PHASES
Engineering Phase: This stage involves the
actual coding, testing, and deployment of
the software. The choice of the development
model is determined by the level of risk
identified for that specific phase, as per the
risk assessment conducted.
Evaluation Phase: Here, the client evaluates
the software program. It is decided whether
to proceed with the next cycle or not, and
planning for the subsequent phase of the
project takes place.
SPIRAL MODEL
Best Suited For
• Large-scale, complex systems.
• Projects with high-risk features.
• High-budget projects with significant risks.
• Projects with unclear needs or projects still in
research and development.
PROTOT
YPE
MODEL
[Link]
PROTOTYPE MODEL
PHASES
• Requirement Identification: The model’s
outset involves the identification of necessary
requirements for envisioned system.
• Design: A fundamental conceptual design is
crafted.
• Prototype Development: An operational
prototype is constructed for the intended
system.
• Initial Assessment: Client assesses the
prototype to assess its functionalities and
constraints.
• Prototype Enhancement: Building upon the
client’s evaluation, the prototype undergoes
PROTOTYPE MODEL
When applying Prototype Model, teams will focus
on develop early visualization of the system
through working prototypes.
This enables customers to interact with and
provide feedback on an initial version of the
software before final development, ensuring
alignment between expectations and
deliverables.
Best Suited For:
• Systems with significant user interaction.
• New technology or innovative features.
• Complex systems requiring visualization.
AGILE MODEL
AGILE MODEL
The Agile model is an iterative, flexible
approach to software development that
emphasizes rapid delivery through
collaborative teams.
It breaks projects into small increments,
allowing for quick adaptations to
changing requirements.
Though agile provides a very realistic
approach to software development, it
isn’t great for complex projects. It can
also present challenges during transfers
AGILE MODEL
Agile development considers the following:
• Requirements are assumed to change
• The system evolves over a series of short
iterations
• Customers are involved during each
iteration
• Documentation is done only when needed
AGILE MODEL
Best Suited For
• Projects with evolving requirements.
• Small to medium-sized teams.
• Innovative projects where user feedback
is crucial.
• When a client demands a highly tailored
development approach for a specific
product.
AGILE
FRAMEWORKS
[Link]
PROCESS MODELS
No one-size-fit-all solutions in software
development. Each model offers unique benefits
yet faces certain limitations.
If you know your requirements well, it will be
easier to select a model that best matches your
needs. Requirem Cost of
Resources
ents delay
Customer
Complexit
Size involveme
y
nt
Technolog
y
knowledg
FACTORS FOR
CHOOSING A
SOFTWARE PROCESS
Project requirements
Before you choose a model, take some time to
go through the project requirements and
clarify them alongside the team’s
expectations. Will the user need to specify
requirements in detail after each iterative
session? Will the requirements change during
the development process?
Project size
Consider the size of the project you will be
working on. Larger projects mean bigger
FACTORS FOR
CHOOSING A
SOFTWARE
Project complexity
PROCESS
Complex projects may not have clear
requirements. The requirements may change
often, and the cost of delay is high. Ask
yourself if the project requires constant
monitoring.
Cost of delay
Is the project highly time-bound with a huge
cost of delay, or are the timelines flexible?
Customer involvement
Do you need to consult the customers during
the process? Does the user need to participate
FACTORS FOR
CHOOSING A
SOFTWARE PROCESS
Familiarity with technology
This involves the developers’ knowledge and
experience with the project domain, software
tools, language, and methods needed for
development.
Project resources
This involves the amount and availability of
funds, staff, and other resources