M. Weintraub & F
Transcript of M. Weintraub & F
SOFTWARE DEVELOPMENT
LIFE CYCLE (SDLC)
M. Weintraub
& F.Tip
Thanks go to Andreas Zeller for allowing incorporation of his
materials
• noun pro·cess
a series of actions that produce
something or that lead to a particular result
http://www.merriam-webster.com/dictionary/process
PROCESS
3
Typical “Good” Qualities
Effective Actually Used
Efficient Reusable
Relevant Managed
Valid Measurable
Usable
WHAT EACH PARTY CONTROLS
Client Side Tech Side
4
Every software project has three client controls
The tech team has three controls
Cost
Functionality
Time
Process
People Technology
Software Engineering is about managing the client side and defining the tech side
while managing risk.
TEAMS
• Working with and within teams requires extra effort for
• Communication
• Documentation
• Tooling
• Hand-offs (process exchanges or role turn-over)
• Your process needs to be able to accommodate changes in team
composition
5
PROJECT INFLUENCES
• Scale
• Affects the ability to know “everything”
• Complexity becomes a critical factor, if it wasn’t already
• Legacy
• Rarely is everything from scratch
• Being able to extend others’ work is essential
6
1. Feasibility
2. Specification
3. Architecture and Design
4. Development
5. Validation
6. Evolution/Maintenance
Processes differ by the order and frequency of these elements
KEY ELEMENTS IN A PROCESS
7
CODE AND FIX: ISSUES
1. No process steps – no
specs, docs, tests…
2. No separation of
concerns – no
teamwork
3. No way to deal with
complexity
10
Waterfall Model(1968)
Communicationproject initiation
requirements gathering
Planningestimatingscheduling
tracking
Modelinganalysisdesign
Constructioncodetest
Deploymentdeliverysupport
feedback
WATERFALL MODEL
1. Real projects rarely follow a sequential flow
2. Hard to state all requirements explicitly
3. No maintenance or evolution involved
4. Customer must have patience
5. Any blunder can be disastrous
18
Boehm’s First Law
19
Errors are most frequent
during requirements and design
activities and are the more expensive
the later they are removed.
WHAT THIS MEANS IN PRACTICE
20
0
75
150
225
300
Requirements Design Code Unit Test System Test Field
Co
st
Project Phase
Relative cost of an error depending on when it is discovered
NEXT IDEA:
SPLIT THE WATERFALL IN TO INCREMENTS
21
Features
Time
Increment #1
Increment #2
Increment #3
INCREMENTAL MODEL
▪ Each linear sequence produces a particular “increment” to
the software
▪ First increment typically core product; more features added
by later increments
▪ Allows flexible allocation of resources
22
EVOLUTIONARY MODELS: PROTOTYPING
23
Quick Plan
Quick Design
PrototypeConstruction
Deployment and Feedback
Communication
PROTOTYPES
A horizontal prototype tests a particular layer
(typically the GUI) of the system
A vertical prototype tests a particular functionality
across all layers
Resist pressure to turn a prototype into a final result!
24
SPIRAL MODEL (1988)
• System is developed in series of
evolutionary releases
• Milestones for each iteration of the
spiral
• Process does not end with delivery
• Reflects iterative nature of
development
29
PlanningModeling
TestDeployment + Feedback
Communication
Construction
FORMAL INTEGRATION OF ITERATIVE AND
INCREMENTAL: UNIFIED PROCESS (1999)
30
Planning
Modeling
Construction
Deployment
CommunicationSoftware
Increment
Inception
Elaboration
ConstructionTransition
Production
INCEPTION
31
PlanningCommunication
Inception
Planning
Modelling
Construction
Deployment
CommunicationSoftware
Increment
Inception
Elaboration
ConstructionTransition
Production
• Encompasses communication with user + planning
• Results in a set of use cases
• Architecture is just a tentative outline
ELABORATION
32
Planning
Modelling
Elaboration
Planning
Modelling
Construction
Deployment
CommunicationSoftware
Increment
Inception
Elaboration
ConstructionTransition
Production• Refines and expands preliminary use cases
• Provides architecture and initial design model
CONSTRUCTION
33
Modelling
Construction
Planning
Modelling
Construction
Deployment
CommunicationSoftware
Increment
Inception
Elaboration
ConstructionTransition
Production
• Builds (or acquires) software components according to
architecture
• Completes design model
• Includes implementation, unit tests, acceptance tests
TRANSITION
34
Construction
Deployment
Transition
Planning
Modelling
Construction
Deployment
CommunicationSoftware
Increment
Inception
Elaboration
ConstructionTransition
Production
• Software given to end users for beta testing
• Feedback reports defects and changes
• Support information written
PRODUCTION
35
Deployment
Software Increment
Planning
Modelling
Construction
Deployment
CommunicationSoftware
Increment
Inception
Elaboration
ConstructionTransition
Production
• Software is deployed
• Problems are monitored
RE-ITERATION
36
Deployment
Communication Planning
Modelling
Construction
Deployment
CommunicationSoftware
Increment
Inception
Elaboration
ConstructionTransition
Production
• Feedback results in new iteration for next release
UNIFIED PROCESS
37
Planning
Modelling
Construction
Deployment
CommunicationSoftware
Increment
Inception
Elaboration
ConstructionTransition
Production
• Draws on best features of conventional process models
• Emphasizes software architecture and design
• Integrates with UML modeling techniques (more on this later)
AGILE SOFTWARE DEVELOPMENT
• Individuals and activities over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.
39
Manifesto for Agile Software Development (2001)
WHAT IS AGILE DEVELOPMENT?
• Fast development? Hacking? Prototyping?
Uncontrolled fun? Programmer heaven?
• Agility = ability to react to changing situations quickly,
appropriately, and effectively.
1. Notice changes early
2. Initiate action promptly
3. Create a feasible and effective alternative plan quickly
4. Reorient work and resources quickly and effectively
40
AGILE?
41
Communicationproject initiation
requirements gathering
Planningestimatingscheduling
tracking
Modelinganalysisdesign
Constructioncodetest
Deploymentdeliverysupport
feedback
AGILE PROCESSES
43
Time
Scope
Analyze
Design
Implement
Test
Waterfall Iterative Agile Processes
Credits: Prof. Bodik
AGILE VS. PLAN-DRIVEN
• Low criticality
• Senior developers
• Requirements change very
often
• Small number of
developers
• Culture that thrives on
chaos
44
• High criticality
• Junior developers
• Requirements don't
change too often
• Large number of
developers
• Culture that demands
order
Agile Plan-Driven
Design
CodingTest
Planning
Software Increment
PLANNING
• In XP, planning takes place
by means of stories
• Each story captures
essential behavior
46
Planning
DesignDesign
CodingTest
Planning
Software Increment 47
EXTREME PROGRAMMING
• Design is made on the fly, using the KISS (keep it simple) principle
• Virtually no notation besides CRC cards (object sketches) and
spike solutions (prototypes)
Coding
Design
CodingTest
Planning
Software Increment
• Each story becomes a unit
test that serves as
specification
• The program is
continuously refactored to
have the design match the
stories
48
CODING
Coding
Design
CodingTest
Planning
Software Increment
CODING
To ensure continuous
review, XP mandates
pair programming
49
Test
Design
CodingTest
Planning
Software Increment
TESTING
Unit tests
• Detect errors
• Find missing
functionality
• Measure progress
50
Test
Planning
Software Increment
Design
CodingTest
Planning
Software Increment
EXTREME PROGRAMMING
The resulting
prototypes result in
new stories 51
Design
CodingTest
Planning
Software Increment
Design
CodingTest
Planning
Software Increment
EXTREME PROGRAMMING
52
SCRUM
• An iterative and incremental agile software
development method for managing software
projects and product or application development.
• Small working teams to maximize communication,
minimize overhead and maximize knowledge
sharing.
• Adaptable to technical and business changes.
• Yields frequent software increments that can be
inspected.
55
SCRUM
• Development work and the people who perform it
are partitioned into clean, low coupling partitions.
• Constant testing and documentation is performed.
• Ability to declare project “done” whenever required.
56
Demos: Demonstrate software increment to the
customer for evaluation.
SCRUM
A prioritized list project requirements or
features that provide business value.Backlog:
Sprints: Consists of work units that are required to
achieve a defined backlog into a
predefined time-box (usually 14-28 days).
Scrums: Short (~15 mins.) daily meetings of the
scrum team. The Scrum master usually
leads the meeting.
• Puts test specification as the critical
design activity
• Understands that deployment comes
when the system passes testing
• Clearly defines what success means
• No more guesswork as to what
“complete” means
• The act of defining tests requires one
to understand how the solution works
TEST-FIRST DESIGN
59
Tests
Design
SpecificationDefines
(non)function
objectives
Defines
acceptance
objectives
System
under testDevelopment
Informs designs
Defines
system
Deployment
Verified
system
• What is the net tolerance for finding errors
in deployment?
• How fast is the market moving?
• Are the teams experienced with a
particular process?
• Is the contract fixed and firm?
• When do the clients expect to see
something?
KEY CONCERNS IN SELECTING A PROCESS
60
Adapted from
http://www.agilemodeling.com/essays/costOfChange.htm
Copyright © 2003 Scott W. Ambler
Typical view of
waterfall
Typical view of
iterative
EVEN WITH ADVANCES IN PROCESS, PROJECT
SUCCESS REMAINS RISKY
Pessimist View Optimist View
61
0 23 45 68 90 113
All projects
Success Challenged Failed
0% 25% 50% 75% 100%
Lean
Iterative
Agile
Ad-Hoc
Traditional
Successful Challenged Failed
Dr. Dobb’s Journal 2013 IT Project Success Survey posted at
www.ambysoft.com/surveys/Standish Group (UK), Chaos Study, 1995
http://geekandpoke.typepad.com/geekandpoke/2012/05/development-cycle.html