The document discusses several software process models: 1. The prototyping model allows developers to build prototypes when requirements are unclear to better understand the needs of customers. Prototypes are evaluated and refined through iterative prototyping. 2. The spiral model is an evolutionary approach that combines iterative prototyping and risk analysis. It involves progressing through risk assessment, engineering, construction, and evaluation in iterative cycles. 3. The V-model structures the software development process around each phase of design and its corresponding testing phase. Requirements lead to system testing, high-level design maps to integration testing, and so on down the left arm with coding at the bottom mapping to unit testing up the right arm.

1. SOFTWARE
ENGINEERING
ENGR.MUHAMMAD UMER HAROON

2. SOFTWARE PROCESS
MODELS

3. OUTLINE
Prototyping Model
Spiral Model
Win-win Spiral Model
V-Model
3

4. PROTOTYPING MODEL
Prototyping Model assists the software engineer and the customer
to better understand what is to be built when requirements are fuzzy.
Often customer defines a set of general objectives for software, but
does not identify detailed input, processing or output requirements.
In these situations a prototyping paradigm may offer the best
approach.
4

5. • Software engineer meet and define the overall objective of the
software
• Identify what requirements are known, and outline area where
further definition is mandatory.
Communication
• Prototyping iteration is planned quickly.
Quick Planning
• The quick design focuses on a representation of the
customer/user (e.g, input approaches and output formats).
Modeling And
Quick Design
• The prototype is the model of the software
• It could be working model or nonworking model.
• The prototype shows the functionality of the software.
• The Prototype serve as the “First System”
• Ideally, the prototype serves as a mechanism for identifying software
requirements.
Construction Or
Prototyping
• The prototype is deployed and evaluated by the customer/user.
• Feedback is used to refine requirements for the software to be developed.
• Prototyping iteration occurs as the prototype is tuned to satisfy the needs
of the customer,, while at the same time enabling the developer to better
understand what needs to be done.
Deployment
5

6. Advantages
• A prototype can be developed when the final properties
are not entirely clear. The direct contact between customer
and developer reduces misunderstandings. Inconsistent
requirements are discovered earlier, either by the
developer or by the customer who evaluates the prototype.
Challenge
s
• There is an inherent risk that side effects are not sufficiently
considered, especially nonfunctional requirements such as
reliability or safety.
Another risk is that the customer (or the developer)
considers the prototype as the first version of the system,
and that the system will be evolved from the prototype,
potentially leading to poorly documented, badly architected
systems.
• The prototyping phase of a project may also induce higher
costs compared to a non prototyped approach.
A prototype is a great way to clarify ambiguous or unknown
requirements; however, don’t ever confuse it with the first
version of the actual system!
6

7. SPIRAL MODEL
Combines iterative prototyping with systematic aspects of the
Waterfall model.
The spiral Model, is an evolutionary software process model that
couples the iterative nature of prototyping with the controlled and
systematic aspects of the linear sequential model.
It provides the potential for rapid development of incremental
versions of the software.
Using the spiral model, software is developed in a series of
incremental releases.
During early iterations, the incremental releases might be a paper
model or prototype.
During later iterations, increasingly more complete versions of the
engineered system are produced.
7

8. 8
A spiral model is divided into a number of framework activities also called task Regions.
 Spiral model that contains six task regions.
• Tasks required to
established
effective
communication
between developer
and customer.
Customer
communication:
• Tasks required to
define resources,
timelines, and
other project
related information.
Planning:
• Tasks required to
assess both
technical and
management
risks.
Risk analysis:
• Tasks required to
build one or more
representations
of the application.
Engineering:
• Tasks required to
construct, test, install,
and provide user
support (e.g.
documentation and
training).
Construction
and release:
• Tasks required to obtain customer
feedback based on evaluation of the
software representations created
during the engineering stager and
implemented during the installation
stage.
Customer
evaluation:

9. 9
Each of the regions is populated by a set of work tasks,
called a task set, that are adapted to the characteristics of
the project to be undertaken.
For small projects, the number of work tasks and their
formality is low.
For larger, more critical projects, each task region contains
more work tasks that are defined to achieve a higher level
of formality.

10. 10
Advantages
• Realistic to the development of large-scale
systems
• Iteratively reduces risk
• Allows repeated use of the prototyping
approach
Problems
• Customers may not like it, fearing lack of
control
• Demands risk assessment expertise and
relies on this expertise for success.
• If a major risk is not uncovered and
managed, problems will undoubtedly
occur.
• It is very lengthy process.

11. WIN WIN SPIRAL MODEL
The objective of this model is to elicit project
requirements from the customer.
The best negotiations strive for a “win-win”
result.
That is, the customer wins by getting the
system or product that satisfies the majority
of the customer’s needs and the developer
wins by working to realistic and achievable
budgets and deadlines.
11

12. V MODEL
12
It means verification and validation .
• Just like WATER FALL model, The life
cycle of the V model is a sequential
path of the execution of the process.
• Each phase must be completed before
the next phase begins.
• The testing of the product is planned
in parallel with corresponding phase of
development.

13. 13
It should be used for small to medium size
projects where requirements are clearly
defined.
It should be chosen when simple technical
resources are available with needed technical
expertise.
WHEN
TO
USE
V-MODEL?

14. 14
Requirements
High-Level
Design (HLD)
Low-Level
Design (LLD)
Implementatio
n
Coding
PHASES OF V-
MODEL

15. Verification: It involves a static analysis method
(review) done without executing code. It is the
process of evaluation of the product development
process to find whether specified requirements
meet.
Validation: It involves dynamic analysis method
(functional, non-functional), testing is done by
executing code. Validation is the process to classify
the software after the completion of the
development process to determine whether the
software meets the customer expectations and
15

16. 16
Requirements In this model the requirements are gathered before its development and a system
test plan is created. The plan test focuses on meeting the functionality specified in
the requirements gathering.
High-Level
Design
It focuses on system architecture and design. It provide overview of the solution,
platform system, product and services/process. An integrated test plan is created
here as well as in order to test the pieces of the software system ability to work
together.
Low-Level
Design
Here the actual software components of software are design . It defines the actual
logic for each and every component of the system. Component test are created in
this phase as well.
Coding It is that phase where all the coding take place. Once coding is complete, the path
of execution up the right side of the V where the test plans developed earlier are
now put to use.
Implementatio
n
This is at the bottom of the V-model. Module design is converted into code by
developer.

17. 17
Advantag
es
• Simple and easy to use.
Testing activities like planning, test
design happens well before coding.
• This saves a lot of time.
• Avoids the down word flow of the
defects.
• Works well for small projects where
requirements are easily understood.
Disadvantag
es
• Very rigid and cost flexible.
Software is developed during the
implantation phase, so no early
prototypes of the software are
produced.
•If any changes happens, then the
test
requirement documents has been
updated.

18. THANK YOU
Engr. Muhammad Umer Haroon