Software Engineering Models

4/27/23 Sofware Engineering Model 1

 The software process
• A structured set of activities required to develop a
software system
– Software Requirement Specification
– Software Design Specification
– Coding /Implementation
– Validation : UNIT testing and Integrated Testing
– Evolution
– Beta Version
• A software process model is an abstract representation of a
process. It presents a description of a process from some
particular perspective.

4/27/23 Sofware Engineering Model 2

 Each Phase has an “Output”

Phase Output
• Requirements analysis • Software Requirements
Specification (SRS),
Use Cases
• Design • Design Document,
Design Classes
• Implementation • Code

• Test • Test Report,

Change Requests

4/27/23 Sofware Engineering Model 3

 Generic Software Process Models
• Waterfall
- Separate and distinct phases of specification and development
(linear sequential)
• Iterative
- waterfall in iterative manner
• Incremental
• RAD
• Prototyping model
- False or pseudo model
• Evolutionary
– Specification and development are interleaved
• Spiral model
- Combination of all models
• Formal Transformation
– A mathematical system model is formally transformed to an implementation
• Component Based -UML
– The system is assembled from existing components
4/27/23 Sofware Engineering Model 4
 Waterfall model
Requirements
definition

System and
software design

Implementa tion
and unit testing

Integration and
system testing

Oper ation and

maintenance

4/27/23 Sofware Engineering Model 5

 Waterfall Model
• Linear sequence of stages/phases
• Requirements –DD – Code – Test – Deploy
• A phase starts only when the previous has
completed; no feedback
• The phases partition the project, each
addressing a separate concern

4/27/23 Sofware Engineering Model 6

 Waterfall model phases
• Requirements analysis and definition
• System and software design
• Implementation and unit testing
• Integration and system testing
• Operation and maintenance
• The main drawback of the waterfall model is
the difficulty of accommodating change after
the process is underway. One phase has to be
complete before moving onto the next phase.
4/27/23 Sofware Engineering Model 7
 Waterfall Advantages
• Conceptually simple, cleanly divides the
problem into distinct phases that can be
performed independently
• Natural approach for problem solving
• Easy to administer in a contractual setup –
each phase is a milestone
• Cost effecient

4/27/23 Sofware Engineering Model 8

 Waterfall model problems
• Inflexible partitioning of the project into distinct stages makes it
difficult to respond to changing customer requirements.
• Therefore, this model is only appropriate when the
requirements are well-understood and changes will be fairly
limited during the design process.
• Few business systems have stable requirements.
• The waterfall model is mostly used for large systems engineering
projects where a system is developed at several sites.

4/27/23 Sofware Engineering Model 9

 Waterfall disadvantages
• Assumes that requirements can be specified
and frozen early
• May fix hardware and other technologies too
early
• Follows the “big bang” approach – all or
nothing delivery; too risky
• Very document oriented, requiring docs at the
end of each phase

4/27/23 Sofware Engineering Model 10

 Waterfall Usage
• Has been used widely
• Well suited for projects where requirements
can be understood easily and technology
decisions are easy
• Low Cost
• I.e. for familiar type of projects it still may be
the most optimum

4/27/23 Sofware Engineering Model 11

 Waterfall Model Documents
Activity Output documents
Requirements analysis Feasibility study, Outline requirements
Requirements definition Requirements document
System specification Functional specification, Acceptance test plan
Draft user manual
Architectural design Architectural specification, System test plan
Interface design Interface specification, Integration test plan
Detailed design Design specification, Unit test plan
Coding Program code
Unit testing Unit test report
Module testing Module test report
Integration testing Integration test report, Final user manual
System testing System test report
Acceptance testing Final system plus documentation

4/27/23 Sofware Engineering Model 12

 Iterative Models
What’s an Iteration?

• Iterative Design: Code as much as you can questions surface, then start over.
• Every model we’ll talk about below is a variation on the Iterative Model.
 Iterative Development
• Products almost always follow it
• Used commonly in customized development
also
– Businesses want quick response for sw
– Cannot afford the risk of all-or-nothing
• Newer approaches like XP, Agile,… all rely on
iterative development

4/27/23 Sofware Engineering Model 14

 Iterative Development
• Counters the “all or nothing” drawback of the
waterfall model
• Combines benefit of waterfall
• Develop and deliver software in increments
• Each increment is complete in itself
• Can be viewed as a sequence of waterfalls
• Feedback from one iteration is used in the future
iterations

4/27/23 Sofware Engineering Model 15

 Iterative Development
• Benefits: Get-as-you-pay, feedback for
improvement,
• Drawbacks: Architecture/design may not be
optimal, rework may increase, total cost may
be more
• Applicability: where response time is
important, risk of long projects cannot be
taken, all req not known

4/27/23 Sofware Engineering Model 16

 Another Form of Iterative
• The first iteration does the requirements and
architecture in the waterfall way
• The development and delivery is done
incrementally in iterations

4/27/23 Sofware Engineering Model 17

 Another form of Iteration…

4/27/23 Sofware Engineering Model 18

 Incremental
Incremental Model is combination of one or more Waterfall Models.
Project requirements are divided into multiple modules and each module is
developed separately.
Finally developed modules are integrated with other modules. During development
of each module, waterfall model is followed for each module development
separately.
Each developed module in Incremental Model is standalone feature and could be
delivered to the end users to use it.
In Incremental Model no need to wait for all the modules to be developed and
integrated.
As each module is standalone application and there is no dependencies on other
modules so we can deliver the project with initial developed feature and other
features could be added on incremental basis with new releases. Incremental
process goes until all the requirements fulfilled and whole system gets developed.

4/27/23 Sofware Engineering Model 19

 Incremental

4/27/23 Sofware Engineering Model 20

 RAD
Concurr ent
activities

Initial
Specification
version

Outline Intermediate
Development
description versions

Final
Validation
version

4/27/23 Sofware Engineering Model 21

 Prototyping
• Prototyping addresses the requirement
specification limitation of waterfall
• Instead of freezing requirements only by
discussions, a prototype is built to understand
the requirements
• Helps alleviate the requirements risk
• A small waterfall model replaces the
requirements stage

4/27/23 Sofware Engineering Model 22

 Prototyping (Cont…)

• what is software prototyping ?

It is the process of implementing the presumed software requirements
with an intention to learn more about the actual requirements or
alternative design that satisfies the actual set of requirements .

• Need for software prototyping

-To assess the set of requirements that makes a product
successful in the market
-To test the feasibility without building the whole system.
-To make end-user involved in the design phase

4/27/23 Sofware Engineering Model 23

 Prototyping
• Re-Visit and improve the
prototype to serve as a Listen To
“baseline” Customer

• Turns prototype into a

“rigged demo” Build/Revise
Mockup
• Show that to the Customer Test
customer Drives Mockup
 Prototyping

4/27/23 Sofware Engineering Model 25

 Prototyping
• Development of prototype
– Starts with initial requirements
– Only key features which need better
understanding are included in prototype
– No point in including those features that are well
understood
– Feedback from users taken to improve the
understanding of the requirements

4/27/23 Sofware Engineering Model 26

 Prototyping
• Cost can be kept low
– Build only features needing clarification
– “quick and dirty” – quality not important, scripting
etc can be used
– Things like exception handling, recovery, standards
are omitted
– Cost can be a few % of the total
– Learning in prototype building will help in building,
besides improved requirements

4/27/23 Sofware Engineering Model 27

 Prototyping
• Advantages: req will be more stable, req
frozen later, experience helps in the main
development
• Disadvantages: Potential hit on cost and
schedule
• Applicability: When req are hard to elicit and
confidence in reqs is low; i.e. where reqs are
not well understood

4/27/23 Sofware Engineering Model 28

 Types of Prototyping

• Throw away prototyping

• Evolutionary prototyping
.

• Operational prototyping

4/27/23 Sofware Engineering Model 29

 Evolutionary development
• 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
and add new features as proposed by the customer.
• Throw-away prototyping
– Objective is to understand the system requirements.
Should start with poorly understood requirements
to clarify what is really needed.

4/27/23 Sofware Engineering Model 30

 Evolutionary development

Concurrent
acti vities

Initial
Specification version

Outline Intermedia te
Development versions
description

Final
Validation version

4/27/23 Sofware Engineering Model 31

 Process Model Problems
• Waterfall
– High risk for new systems because of specification and
design problems.
– Low risk for well-understood developments using familiar
technology.
• Prototyping
– Low risk for new applications because specification and
program stay in step.
– High risk because of lack of process visibility.
• Transformational
– High risk because of need for advanced technology and
staff skills.

4/27/23 Sofware Engineering Model 32

 Hybrid Process Models
• Large systems are usually made up of several
sub-systems.
• The same process model need not be used for
all subsystems.
• Prototyping for high-risk specifications.
• Waterfall model for well-understood
developments.

4/27/23 Sofware Engineering Model 33

 Spiral Model
Determine Evaluate
objectives, alternatives,
alternatives, identify and
constraints resolve risks

Plan next Develop verify

phases next level
product
 Risk Assessment
• Spiral Model – risk driven rather than
document driven
• The "risk" inherent in an activity is a
measure of the uncertainty of the
outcome of that activity
• High-risk activities cause schedule
and cost overruns
• Risk is related to the amount and
quality of available information. The
less information, the higher the risk
• What happened with Denver Airport
Luggage System?
 Spiral Model
Strength and Weaknesses
• Strengths
– Introduces risk management
– Prototyping controls costs
– Evolutionary development
– Release builds for beta testing
– Marketing advantage

• Weaknesses
– Lack of risk management experience
– Lack of milestones
– Management is dubious of spiral process
– Change in Management
– Prototype Vs Production
4/27/23 Sofware Engineering Model 36
 Win Win Spiral Model

• Win-Win Spiral Process Model is a model of a

process based on Theory W, which is a
management theory and approach "based on
making winners of all of the system's key
stakeholders as a necessary and sufficient
condition for project success."

4/27/23 Sofware Engineering Model 37

 WinWin Spiral Model
• Identify Stake holders win conditions
• Identify Next Level Stake holders
• Reconcile Win conditions
 Win Win Spiral Cont
• Identifying the system's stakeholders and their win
conditions and
• reconciling win conditions through negotiation to arrive
at a mutually satisfactory set of objectives, constraints,
and alternatives for the next level.
• Evaluate Product and Process Alternatives. Resolve Risks
• Define next level of product and process - including
partitions
• Validate Product and Process Definitions
• Review, commitment

4/27/23 Sofware Engineering Model 39

 Spiral Process Model
Determine ob jectiv es
Ev aluate alt ern atives
alternatives and id en tify, resolve risk s
cons traints Risk
analys is
Risk
analys is
Risk
analys is Opera-
Prot otyp e 3 ti onal
Prot otyp e 2 protoyp e
Risk
REVIEW analysis Proto-
ty pe 1
Requi rements plan Simulati ons, models, b en ch marks
Li fe-cycle plan Concept o f
Operati on S/W
requirements Prod uct
design Detailed
Requi rement design
Develop ment
plan valid ati on Code
Design Unit tes t
Integration
and test p lan V&V Integr ation
Plan next p has e test
Accep tance
Serv ice test Develop, v erify
next-level p rod uct

4/27/23 Sofware Engineering Model 40

 Spiral Model Advantages
• Focuses attention on reuse options.
• Focuses attention on early error elimination.
• Puts quality objectives up front.
• Integrates development and maintenance.
• Provides a framework for hardware/software
development.

4/27/23 Sofware Engineering Model 41

 Process Visibility
• Software systems are intangible so managers
need documents to assess progress.
• Waterfall model is still the most widely used
model.

4/27/23 Sofware Engineering Model 42

 Spiral Model Advantages
• Focuses attention on reuse options.
• Focuses attention on early error elimination.
• Puts quality objectives up front.
• Integrates development and maintenance.
• Provides a framework for hardware/software
development.

4/27/23 Sofware Engineering Model 43

 UML

4/27/23 Sofware Engineering Model 44

 Process Visibility
• Software systems are intangible so managers
need documents to assess progress.
• Waterfall model is still the most widely used
model.

4/27/23 Sofware Engineering Model 45

 Ethical Issues
• Confidentiality
• Competence
• Intellectual property rights
• Computer misuse

4/27/23 Sofware Engineering Model 46