Ch03-Software Engineering Model

Software Engineering:
Chapter 3
1 D.Balaganesh Lincoln university College

Prescriptive Models
2
 Prescriptive process models advocate an orderly approach to software
engineering
That leads to a few 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?
D.Balaganesh Lincoln university College

SDLC Model
D.Balaganesh LINCOLN UNIVERSITY
COLLGE3
A framework that describes the activities performed at each stage of a
software development project.

Waterfall Model
Requirements – defines needed
information, function, behavior,
performance and interfaces.
Design – data structures, software
architecture, interface representations,
algorithmic details.
Implementation – source code,
database, user documentation, testing.
D.Balaganesh LINCOLN
UNIVERSITY COLLGE 4

Waterfall Model
5
UNIVERSITY COLLGE

Waterfall Model
Test – check if all code modules work
together and if the system as a whole
behaves as per the specifications.
Installation – deployment of system,
user-training.
Maintenance – bug fixes, added
functionality (an on-going process).
UNIVERSITY COLLGE 6

Waterfall Strengths
COLLGE7
Easy to understand, easy to use
Provides structure to inexperienced staff
Milestones are well understood
Sets requirements stability
Good for management control (plan, staff, track)

Waterfall Deficiencies
COLLGE8
All requirements must be known upfront
Deliverables created for each phase are considered frozen –
inhibits flexibility
Does not reflect problem-solving nature of software
development – iterations of phases
Integration is one big bang at the end
Little opportunity for customer to preview the system (until
it may be too late)

When to use the Waterfall Model
COLLGE9
Requirements are very well known
When it is possible to produce a stable design
E.g. a new version of an existing product
E.g. porting an existing product to a new platform.

Spiral SDLC Model
Adds risk analysis, and 4gl
RAD prototyping to the
waterfall model
Each cycle involves the
same sequence of steps as
the waterfall process model
UNIVERSITY COLLGE 10

Spiral Quadrant
Determine objectives, alternatives and constraints
COLLGE11
Objectives: functionality, performance, hardware/software interface,
critical success factors, etc.
Alternatives: build, reuse, buy, sub-contract, etc.
Constraints: cost, schedule, man-power, experience etc.

Spiral Quadrant
Evaluate alternatives, identify and resolve risks
COLLGE12
Study alternatives relative to objectives and constraints
Identify risks (lack of experience, new technology, tight
schedules, etc.)
Resolve risks

Spiral Quadrant
Develop next-level product
COLLGE13
Typical activites:
Create a design
Review design
Develop code
Inspect code
Test product

Spiral Quadrant
Plan next phase
COLLGE14
Typical activities
Develop project plan
Develop a test plan
Develop an installation plan

Spiral Model Strengths
COLLGE15
Provides early indication of insurmountable risks,
without much cost
Users see the system early because of rapid prototyping
tools
Critical high-risk functions are developed first
Users can be closely tied to all lifecycle steps
Early and frequent feedback from users

Spiral Model Weaknesses
COLLGE16
Time spent for evaluating risks too large for small or low-
risk projects
Time spent planning, resetting objectives, doing risk
analysis and prototyping may be excessive
The model is complex
Risk assessment expertise is required
Spiral may continue indefinitely
Developers must be reassigned during non-development
phase activities

When to use Spiral Model
COLLGE17
When creation of a prototype is appropriate
When costs and risk evaluation is important
For medium to high-risk projects
Users are unsure of their needs
Requirements are complex
New product line
Significant changes are expected

Tailored SDLC Models
COLLGE18
No single model fits all projects
If there is no suitable model for a particular project,
pick a model that comes close and modify it for your
needs.
If project should consider risk but complete spiral model is too
much – start with spiral and simplify it
If project should be delivered in increments but there are
serious reliability issues – combine incremental model with the
V-shaped model
Each team must pick or customize a SDLC model to fit
its project

The Waterfall Model
D.Balaganesh Lincoln university College19
Communicat ion
Planning
Modeling
Const ruct ion
Deployment
analysis
design
code
t est
project init iat ion
requirement gat hering estimating
scheduling
tracking
delivery
support
f eedback

The Incremental Model
C o m m u n i c a t i o n
P l a n n i n g
M o d e l i n g
C o n s t r u c t i o n
D e p l o y m e n t
d e l i v e r y
f e e d b a c k
analy s is
des ign c ode
t es t
increment # 1
increment # 2
delivery of
1st increment
delivery of
2nd increment
delivery of
nt h increment
increment # n
project calendar time
P l a n n i n g
M o d e l i n g
D e p l o y m e n t
d e l i v e r y
f e e d b a c k
analy sis
des ign c ode
t es t
P l a n n i n g
M o d e l i n g
D e p l o y m e n t
d e l i v e r y
f e e d b a c k
analy s is
des ign
c ode
t es t

The RAD Model
Communicat ion
Planning
Modeling
business modeling
dat a modeling
process modeling
Const ruct ion
component reuse
aut omat ic code
generat ion
t est ing
Deployment
60 - 90 days
Team # 1
Modeling
business m odeling
dat a m odeling
process m odeling
Const ruct ion
com ponent reuse
aut om at ic code
generat ion
t est ing
M o d e lin g
business m odeling
data m odeling
process m odeling
Co n st ru ct io n
com ponent reuse
autom atic code
generation
testing
Team # 2
Team # n
int egrat ion
delivery
feedback

Evolutionary Models: Prototyping
Communicat ion
Quick plan
Const ruct ion
of
prot ot ype
Mode ling
Quick de sign
Delivery
& Feedback
Deployment
communication
Quick
plan
Modeling
Quick design
Construction
of prototype
Deployment
delivery &
feedback

Component Assembly Model
Identify
candidate
components
Look up
components
in library
Available?
Extract
components
Build
components
Construct
System
yes
no

Component Assembly
Characteristics
Use of object-oriented technology
Components - classes that encapsulate both data and
algorithms
Components developed to be reusable
Paradigm similar to spiral model, but engineering activity
involves components
System produced by assembling the correct components

Fourth Generation Techniques
(4GT)
"Design"
Strategy
Testing
Requirements
gathering
Implementation
using 4GL

4GT Characteristics
Use of software tools that allow software engineer to specify
s/w characteristics at higher level
The tools generate codes based on specification
More time in design and testing - increase productivity
Tools may not be easy to use, codes generated may not be
efficient

Other Process Models
 Component assembly model—the process to apply when reuse is a
development objective
 Concurrent process model—recognizes that different part of the project
will be at different places in the process
 Formal methods—the process to apply when a mathematical specification is
to be developed
 Cleanroom software engineering—emphasizes error detection before
testing

Evolutionary Models: Concurrent
Under review
Baselined
Done
Under
revision
Await ing
changes
Under
development
none
Modeling act ivit y
represents the state
of a software engineering
activity or task

Still Other Process Models
Component based development—the process to apply when
reuse is a development objective
Formal methods—emphasizes the mathematical specification of
requirements
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)

Conclusion
The paradigm used for development of software depends on a
number of factors
People - staff & users
Software product
Tools available
Environment
Existing models makes development process clearer, but they
can be evolved to become new paradigms

The Unified Process (UP)
inceptioninception
soft ware increment
Release
Incept ion
Elaborat ion
const ruct ion
t ransit ion
product ion
inception
elaboration

UP Phases
Inception Elaboration Construction Transition Production
UP Phases
Workflows
Requirements
Analysis
Design
Implementation
Test
Iterations #1 #2 #n-1 #n
Support

UP Work Products
Inception phase
Elaboration phase
Construction phase
Transition phase
Vision document
Init ial use-case model
Init ial project glossary
Init ial business case
Init ial risk assessment .
Project plan,
phases and it erat ions.
Business model,
if necessary.
One or more prot ot ypes
I nc e pt i o
n
Use-case model
Supplement ary requirement s
including non-funct ional
Analysis model
Soft ware archit ect ure
Descript ion.
Execut able archit ect ural
prot ot ype.
Preliminary design model
Revised risk list
Project plan including
it erat ion plan
adapt ed workflows
milest ones
t echnical work product s
Preliminary user manual
Design model
Soft ware component s
Int egrat ed soft ware
increment
Test plan and procedure
Test cases
Support document at ion
user manuals
inst allat ion manuals
descript ion of current
increment
Delivered soft ware increment
Bet a t est report s
General user feedback

Ch03-Software Engineering Model

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Ch03-Software Engineering Model

Semelhante a Ch03-Software Engineering Model (20)

Mais de Bala Ganesh

Mais de Bala Ganesh (20)

Último

Último (20)

Ch03-Software Engineering Model