Software Engineering: A Practitioner’s Approach,
7/e
copyright © 1996, 2001, 2005
R.S. Pressman & Associates, Inc.
For University Use Only
May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly prohibited.
Coming up: Prescriptive Models 1

Prescriptive
Goal : Higher Quality Software
Philosophy :
• Bring order to chaos
• Provide repeatability/consistency
• Provide ability to control
• Provide ability to coordinate teams
Agile
Goal : Higher Quality Software
Philosophy :
• Individuals and interaction over process and tools
• Working software over large documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
2



We discussed how prescriptive models seems to have lost their popularity, while agile models have been gaining in popularity
What are some possible reasons for this?

 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?
Coming up: The Waterfall Model 4

Com m unic a t ion proje c t init ia t ion re quire m e nt ga t he ring
Planning es timating sc heduling track ing
Mode ling analysis design
Use when:
Requirements are stable and well-understood, very short timeline (maintenance fixes)
Const r uc t ion code t est
De ploy m e nt de liv e ry s upport f e e dba c k
Coming up: The V-Model 5



Invented in 1970
It is frequently true that time spent at the beginning of the product lifecycle cuts down on the work in later stages
 How much time does maintenance consume?
 The biggest lesson learned is that waterfall models


Generally don’t work
Because it’s unrealistic to not have change

Same as Waterfall, diagram used to emphasize types of testing are linked to different phases in the model
Requirements are stable and wellunderstood
Coming up: The Incremental Model 7

 Focuses on verification and validation

increment # n
C o m m u n i c a t i o n
P l a n n i n g increment # 2
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 a n a l y s i s d e s i g n
C o n s t r u c t i o n c o d e t e s t
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 deliv ery of
2nd increment increment # 1
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 a n a l y s i s d e s i g n
C o n s t r u c t i o n c o d e t e s t
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 deliv ery of
1st increment
M o d e l i n g a n a l y s i s d e s i g n
C o n s t r u c t i o n c o d e t e s t
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 deliv ery of n t h increment project calendar t ime
Coming up: The Incremental Model 9

Requires: Operational product that provides some value to users at each increment.
Advantages
-Helps users get software faster
-Provides ability for the team to evaluate and replan
-May complete an initial functionality to get buyin or funding for later increments
Disadvantages
-May not be good for very risky systems
-Full working systems may require long increments
Coming up: The RAD Model 10

Com m unicat ion
Team # n
M o d e lin g bus ines s m odeling dat a m odeling proc es s m odeling
Team # 2
Mo d el i ng b u si n e ss m o d e l i n g d a t a m o d e l i n g p ro ce ss m o d e l i n g
C o n s t r u c t io n c om ponent reus e aut om at ic c ode
generat ion t es t ing
Planning
Team # 1
Mode ling business modeling dat a modeling process modeling
Co nst r uct i o n co m p o n e n t re u se a u t o m a t i c co d e
g e n e ra t i o n t e st i n g
Const r uct ion component reuse aut omat ic code
generat ion t est ing
De ploym e nt int egrat ion deliv ery f eedback
6 0 - 9 0 days
Coming up: The RAD Model 11

RAD = Rapid Application Development
Requires : very well understood requirements.
Very fast cycles (60-90 days) to create a lot of functionality
Emphasizes use of existing components/ automatic code generation
Challenges :
- Large staff needed to form RAD teams
- Must have modularizable based software
- Developers and Customers must be willing to make quick decisions
- Time-consuming overall system tuning is difficult
Coming up: Evolutionary Models: Prototyping 12

Used when partial system can be delivered, then evolved into full system plan
Com m unicat ion communication
Prototyping is a tool that can be used during any process design
Used when customer only has a vague idea of what they want
Deployment
Deployment
De live r y delivery & feedback
Const r uct ion
Plan to either throw-away or evolve into real product -there will be pressure at the end to evolve into the real product
Coming up: Evolutionary Models: The Spiral 13

Complete highest risk items first planning estimation scheduling risk analysis communication
Used to mitigate risk on riskintensive projects start modeling analysis design
Every spiral revises cost/budget/sche dule/etc… deployment delivery
feedback construction code test
14 Coming up: 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, architecturecentric, iterative and incremental” software process closely aligned with the Unified Modeling Language
(UML)
Coming up: The Unified Process (UP) 15

 What is it?
 Phases: inception, elaboration, construction, transition


The phases are divided up into time-boxes (iterations)
Each of these iterations results in some deliverable increment

UP Phases
Incept ion Elaborat ion Const ruct ion Transit ion
Workflows
Requirements
Analysis
Design
Implementation
Test
Support
Iterations #1 #2 #n-1 #n
Product ion
Coming up: UP Work Products 20

Incept ion 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 y pes
I n c e p t i o n
Elaborat ion phase
Use-case model
Supplement ary requirement s
including non-f unct ional
Analy sis model
Sof t ware archit ect ure
Descript ion.
Execut able archit ect ural
prot ot y pe.
Preliminary design model
Rev ised risk list
Project plan including
it erat ion plan
adapt ed workf lows
milest ones
t echnical work product s
Preliminary user manual
Const ruct ion phase
Design model
Sof t ware component s
Int egrat ed sof t ware
increment
Test plan and procedure
Test cases
Support document at ion
user manuals
inst allat ion manuals
descript ion of current
increment
Transit ion phase
Deliv ered sof t ware increment
Bet a t est report s
General user f eedback
Coming up: Pick a model 21

 Developing software to automatically drive racecars through a track without crashing. This has never been attempted before under software control. The requirements are stable.
 Waterfall, Incremental, Spiral,
RAD?
Coming up: Pick a model 22



Developing software to track the financial bailout. The software requirements are very clear. You need to create a system to perform 3 distinct tasks:




Display where the money went
Display the amount of money left and how it’s allocated
Allow people to request funds from a particular subset of the money
All functions will interface with each other and the same underlying database.
Waterfall, Incremental, Spiral, RAD?
23 Coming up: Pick a model

 Just checking if you were awake
Coming up: Prescriptive Software Models 25





Variations of these models are VERY commonly used today
If you think about it, they are focused in different areas, but have many similarities (all do the basic structure -- communication, planning, construction, testing, deployment, maintenance)
You will almost definitely do some version of these processes when you graduate
If you had never been to CS421, and never learned them, and then started your own company, you would STILL do your own version of these processes… they make sense!
26 End of presentation