9/3/09 15:07 EEC 521: Software Engineering 1
EEC 521: Software Engineering
The Software ProcessPrescriptive Process Models
9/3/09 15:07 EEC 521: Software Engineering 2
The Top Thrill Dragster• 420 ft tall• Max speed over 120
mph• World’s second
fastest roller coaster
9/3/09 15:07 EEC 521: Software Engineering 3
Roller Coaster Process• The park conceptualizes what it wants• Hires a company to build it; communicates its concept to
the builder• Builder plans the coaster, and communicates its plans and
the budget to park for approval• Builder then makes models of the coaster and makes sure
that all the requirements are met• The models also help understand the physics a little
better than plain calculations• The actual coaster is built, and tested• The coaster is delivered to the park and is opened to
public
Concept
Communication
Planning
Modeling
Construction
Deployment
9/3/09 15:07 EEC 521: Software Engineering 4
What is a Software Process?• A series of predictable steps that helps
produce a timely, high-quality result• What are the actual steps?
• Di!ers from one process model to another
• Important because it provides stability,control and organization
“A process de"nes who is doing what, when, and how to reach acertain goal” – Ivar Jacobson, Grady Booch, and James Rumbaugh
9/3/09 15:07 EEC 521: Software Engineering 5
Software Engineering:A Layered Technology
A quality focus
Process
Methods
Tools
It shoulddo X.
It shoulddo Y.
I’m notsure…
Software Engineering
Software requirements are embodiedknowledge that is initially dispersed, tacit,
latent, and incomplete.
Software engineering encompasses aprocess, management and technical
methods, and tools.
9/3/09 15:07 EEC 521: Software Engineering 6
Generic Software EngineeringPhases
• The de"nition phase• What product is going to be built?
• The development phase• How will the product be built, and how will it be
tested?• The support phase
• Incorporate changes from the four sources ofchange.• Correction• Adaptation• Enhancement• Prevention
9/3/09 15:07 EEC 521: Software Engineering 7
Process Framework• Provides the foundation for a complete
software process• Identi"es framework activities
• Applicable to all software projects• De"nes a set of software engineering actions• Each action has a set of work tasks
• De"nes umbrella activities• Applicable to the process across all process stages• Focus is on project management, tracking, and control
9/3/09 15:07 EEC 521: Software Engineering 8
Generic Framework Activities• Communication
– Communication/collaboration with customer• Planning
– Technical tasks, risks, resource requirements,schedule, etc.
• Modeling– Design, models, prototypes, customer feedback
• Construction– Coding, testing
• Deployment– Delivery
9/3/09 15:07 EEC 521: Software Engineering 9
Umbrella Activities• Software project tracking and control• Risk management• Software quality assurance• Formal technical reviews• Measurement• Software con"guration management• Reusability management• Work product preparation and production
9/3/09 15:07 EEC 521: Software Engineering 10
Process Variety• Prescriptive models
–Waterfall model–Spiral model–The Uni"ed Process–Formal methods
• In general, moredisciplined, and morerules
• Agile models– Extreme
programming– Adaptive software
development– Scrum– Feature-driven
Development
• Fewer rules, focus onend product
9/3/09 15:07 EEC 521: Software Engineering 11
SEI CMMI• Level 0: Incomplete
• No process• Level 1: Performed
• Speci"c goals of process area are performed• Level 2: Managed
• Work in process area conforms to a de"ned policy• Level 3: De"ned
• The process is tailored to the speci"c organization• Level 4: Quantitatively Managed
• Quantitative objectives are established and reviewed• Level 5: Optimized
• Process is adapted and optimized based on statisticalevidence
9/3/09 15:07 EEC 521: Software Engineering 12
Process Patterns• A consistent template for describing
important characteristics for the softwareprocess
• Provides suggested solutions to recurringproblems in the software process e.g.,customer-communication, project-teamassembly
• Can be reused in several di!erent contexts
9/3/09 15:07 EEC 521: Software Engineering 13
General Characteristics ofPrescriptive Models• Framework activities populated with
explicit tasks for software engineeringactions
• The models prescribe how the variousactions are to be executed
• The models prescribe a work!ow
9/3/09 15:07 EEC 521: Software Engineering 14
The Waterfall Model
• Sequential approach to softwaredevelopment
CommunicationProject initiationRequirements Planning
EstimationSchedulingTracking
ModelingAnalysisDesign Construction
CodeTest Deployment
DeliverySupportFeedback
9/3/09 15:07 EEC 521: Software Engineering 15
The Waterfall Model (2)Good for projects that can be planned completely rightat the beginning
– Well-de"ned requirements– No changes anticipated
Most real projects cannot be built sequentiallyMost new projects have inherent uncertaintyNo way of checking if requirements are met
9/3/09 15:07 EEC 521: Software Engineering 16
The Incremental Model
• Iterative application of the Waterfall• Product is “grown” through several
increments
CommunicationProject initiationRequirements
PlanningEstimationSchedulingTracking Modeling
AnalysisDesign
ConstructionCodeTest
DeploymentDeliverySupportFeedbackSo
ftwar
e fu
nctio
nalit
y
Project time
CommunicationProject initiationRequirements
PlanningEstimationSchedulingTracking Modeling
AnalysisDesign
ConstructionCodeTest
DeploymentDeliverySupportFeedback
CommunicationProject initiationRequirements
PlanningEstimationSchedulingTracking Modeling
AnalysisDesign
ConstructionCodeTest
DeploymentDeliverySupportFeedback
Release 1
Release 2
Release 3
9/3/09 15:07 EEC 521: Software Engineering 17
The Incremental Model(2)• The model is an evolutionary approach
– The product gains more features with everyiteration
• Similar to Waterfall– Each increment is built sequentially– Changes are expensive inside an increment
• Each increment is a usable, "nishedproduct– Not a prototype
9/3/09 15:07 EEC 521: Software Engineering 18
Prototyping• Requirements are very fuzzy
– Idea is there, but no details– Customer is not able to clearly state requirement
• Communication is key
Communication Quick plan
Modeling and Quick Design
Prototypeconstruction
Deployment, Delivery &Feedback
9/3/09 15:07 EEC 521: Software Engineering 19
Prototyping (2)
Great way to elicit requirements– Can serve as requirements gathering
technique for other process models– Saves a lot of change later on in the life-cycle
Customer may not like the “throw-away”nature of the prototype
May want to shorten schedule
Bad development choices may be made
9/3/09 15:07 EEC 521: Software Engineering 20
The Spiral Model
• The most mature of evolutionary models– Controlled and systematic, yet evolutionary
• Risk-driven process model– Cyclic approach
• Increase degree of de"nition and implementation• Decrease degree of risk
– Anchor point milestones
9/3/09 15:07 EEC 521: Software Engineering 21
The Spiral Model (2)PlanningEstimationSchedulingRisk analysis
ModelingAnalysisDesign
ConstructionCodeTest
DeploymentDeliveryFeedback
Communication
Start
9/3/09 15:07 EEC 521: Software Engineering 22
The Spiral Model (3)
Realistic model for large projectsPeriodic risk evaluation leads to betterutilization of resourcesWhen is the project !nished?Considerable risk assessment expertise isrequired
9/3/09 15:07 EEC 521: Software Engineering 23
The Uni"ed Process
• Uni"es important features of other processmodels
• Speci"cally targeted at Object-Orientedsystem development
• Based on the concept of use-cases• Includes a set of design tools
– Uni"ed Modeling Language
9/3/09 15:07 EEC 521: Software Engineering 24
The Uni"ed Process (2)
Communication
Planning
Modeling
Construction
Deployment
Software incrementRelease
Inception
ElaborationConstruction
Transition
Production
9/3/09 15:07 EEC 521: Software Engineering 25
The Uni"ed Process (3)• De"ned set of work products
– Use-case model (inception)– Non-functional requirements (elaboration)– Analysis model (elaboration)– Design model (construction)– Implementation model (construction)– Test cases (construction)– Beta test reports (transition)– User feedback reports (transition)
9/3/09 15:07 EEC 521: Software Engineering 26
Other PrescriptiveModels• Component-Based Development
– Integrating components with well-de"nedinterfaces to build system
• Formal Methods Model– Speci"cation, development, and veri"cation
of system using rigorous mathematicalnotation
9/3/09 15:07 EEC 521: Software Engineering 27
Reading AssignmentGilda Pour, Martin L. Griss, and Michael Lutz.The Push to Make Software EngineeringRespectable. IEEE Computer. May 2000. pages35 – 43.