coming up: prescriptive models 1 software engineering: a practitioner’s approach, 7/e chapter 2...
TRANSCRIPT
Coming up: Prescriptive Models 1
Software Engineering: A Practitioner’s Software Engineering: A Practitioner’s Approach, 7/eApproach, 7/e
Chapter 2Chapter 2Prescriptive Process ModelsPrescriptive Process Models
copyright © 1996, 2001, 2005
R.S. Pressman & Associates, Inc.
For University Use OnlyMay 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.
Last time: Different families of Last time: Different families of modelsmodels
2
Prescriptive Agile
Goal: Higher Quality Software
Philosophy:•Bring order to chaos•Provide repeatability/consistency•Provide ability to control•Provide ability to coordinate teams
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
Last time
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?
Coming up: The Waterfall Model 4
Prescriptive ModelsPrescriptive Models
Prescriptive process models advocate an orderly approach Prescriptive process models advocate an orderly approach to software engineeringto software engineering
That leads to a few questions …That leads to a few questions … If prescriptive process models strive for structure and If prescriptive process models strive for structure and
order, order, are they inappropriate for a software world that are they inappropriate for a software world that thrives on change?thrives on change?
Yet, if we reject traditional process models (and the order Yet, if we reject traditional process models (and the order they imply) and replace them with something less they imply) and replace them with something less structured, structured, do we make it impossible to achieve do we make it impossible to achieve coordination and coherence in software work?coordination and coherence in software work?
Coming up: The V-Model 5
The Waterfall The Waterfall ModelModel
Communication Planning
ModelingConstruction
Deployment analysis design code
test
project initiation requirement gathering estimating
scheduling tracking
delivery support feedback
Use when:
-Requirements are stable and well-understood, very
short timeline (maintenance fixes)
Why was the waterfall model designed?
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
The V-ModelThe V-Model
7
Same as Waterfall, diagram used to emphasize types of testing are linked to different phases in the model
-Requirements are stable and well-understood
Coming up: The Incremental Model
Coming up: The Incremental Model 9
The Incremental The Incremental ModelModel
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 ry f e e d b a c k
analys is
des ign code
t es t
increment # 1
increment # 2
delivery of 1st increment
delivery of 2nd increment
delivery of nth increment
increment # n
project calendar time
C o m m u n i c a t i o nP 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
De p l o y m e n t
d e l i v e r y
f e e d b a c k
analys is
des ign code
t es t
C o m m u n i c a t i o nP 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
analys is
des igncode t es t
Coming up: The RAD Model 10
The Incremental The Incremental ModelModel
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 buy- in 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 11
The RAD ModelThe RAD Model
Communication
Planning
Modelingbusiness modeling data modeling process modeling
Constructioncomponent reuse automatic code generation testing
Deployment
60 - 90 days
Team # 1
Modelingbusiness modeling
data modeling process modeling
Constructioncomponent reuse automatic code
generation test ing
Modelingbusiness modeling data modeling process modeling
Const ruct ioncomponent reuse automatic code generation testing
Team # 2
Team # n
integration delivery feedback
Coming up: Evolutionary Models: Prototyping 12
The RAD ModelThe RAD Model
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: The Spiral 13
Evolutionary Models: Evolutionary Models: PrototypingPrototyping
Communication
Quick plan
Construction of prototype
Modeling Quick design
Delivery & Feedback
Deployment
communication
Quickplan
ModelingQuick design
Constructionof prototype
Deploymentdelivery &feedback
Used when partial system can be delivered, then evolved into full system
Prototyping is a tool that can be used during any process
Used when customer only has a vague idea of what they want
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: Still Other Process Models 14
Evolutionary Models: The Evolutionary Models: The SpiralSpiral
communication
planning
modeling
constructiondeployment delivery feedback
start
analysis design
code test
estimation scheduling risk analysis
Complete highest risk items first
Used to mitigate risk on risk-intensive projects
Every spiral revises cost/budget/schedule/etc…
Coming up: The Unified Process (UP) 15
Still Other Process Still Other Process ModelsModels
Component based developmentComponent based development—the process to —the process to apply when reuse is a development objectiveapply when reuse is a development objective
Formal methodsFormal methods—emphasizes the mathematical —emphasizes the mathematical specification of requirementsspecification of requirements
AOSDAOSD—provides a process and methodological —provides a process and methodological approach for defining, specifying, designing, and approach for defining, specifying, designing, and constructing constructing aspectsaspects
Unified ProcessUnified Process—a “use-case driven, architecture-—a “use-case driven, architecture-centric, iterative and incremental” software process centric, iterative and incremental” software process closely aligned with the Unified Modeling Language closely aligned with the Unified Modeling Language (UML)(UML)
The Unified Process
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
Coming up: UP Work Products 20
UP PhasesUP Phases
Inception Elaboration Construction Transition Production
UP Phases
Workflows
Requirements
Analysis
Design
Implementation
Test
Iterations #1 #2 #n-1 #n
Support
Coming up: Pick a model 21
UP Work ProductsUP Work ProductsInception phase
Elaboration phase
Construction phase
Transition phase
Vision document Init ial use-case model Init ial project glossaryInit ial business case Init ial risk assessment. Project plan, phases and iterations. Business model, if necessary. One or more prototypes Incept io n
Use-case modelSupplementary requirements including non-functional Analysis model Software architecture Description. Executable architectural prototype. Preliminary design model Revised risk listProject plan including iteration plan adapted workflows milestones technical work products Preliminary user manual
Design modelSoftware components Integrated software increment Test plan and procedure Test cases Support documentation user manuals installat ion manuals description of current increment
Delivered software increment Beta test reports General user feedback
Pick a modelPick a model
Developing software to automatically drive Developing software to automatically drive racecars through a track without crashing. This racecars through a track without crashing. This has never been attempted before under software has never been attempted before under software control. The requirements are stable.control. The requirements are stable.
Waterfall, Incremental, Spiral, Waterfall, Incremental, Spiral,
RAD?RAD?
22Coming up: Pick a model
Pick a modelPick a model
Developing software to track the financial Developing software to track the financial bailout. The software requirements are very bailout. The software requirements are very clear. You need to create a system to perform 3 clear. You need to create a system to perform 3 distinct tasks:distinct tasks: Display where the money wentDisplay where the money went Display the amount of money left and how it’s allocatedDisplay the amount of money left and how it’s allocated Allow people to request funds from a particular subset Allow people to request funds from a particular subset
of the moneyof the money All functions will interface with each other and the All functions will interface with each other and the
same underlying database.same underlying database. Waterfall, Incremental, Spiral, RAD?Waterfall, Incremental, Spiral, RAD?
23Coming up: Pick a model
Pick a modelPick a model
25
Just checking if you were awakeJust checking if you were awake
Coming up: Prescriptive Software Models
26
Prescriptive Software ModelsPrescriptive Software Models
Variations of these models are VERY commonly used todayVariations of these models are VERY commonly used today If you think about it, they are focused in different areas, If you think about it, they are focused in different areas,
but have many similarities but have many similarities (all do the basic structure -- (all do the basic structure -- communication, planning, construction, testing, communication, planning, construction, testing, deployment, maintenance)deployment, maintenance)
You will almost definitely do some version of these You will almost definitely do some version of these processes when you graduateprocesses when you graduate
If you had never been to CS421, and never learned them, If you had never been to CS421, and never learned them, and then started your own company, you would STILL do and then started your own company, you would STILL do your own version of these processes… they make sense!your own version of these processes… they make sense!
End of presentation