Software Development Process Models and Paradigms

1
Software DevelopmentProcess Models and Paradigms

• By Walter Maner
• ?

Based in part on presentations by Dr. Vojislav
Miic, who mostly used materials and diagrams
taken from Object-Oriented and Classical Software
Engineering, by Stephen R. Schach Terry Leeper,
Director Platform Strategy, Microsoft Theron
James, Common Technologies, Inc., The Agile
Approach Jim Murray, Introduction to Agile
Software Management
2
Preview

• Processes and Process Models
• How Process Models Differ
• Generic Activities (found in all models)
• Umbrella activities (span all phases within a
  model)
• Tour of Process Models
• Code and Fix Model
• Waterfall Model
• Prototyping Model
• Incremental Model
• Synchronize-and Stabilize Model
• XP Model
• Agile Model
• Spiral Model
• Formal Model
• Object-Oriented Models
• Conclusions

3
Processes and Process Models

• Hornby defines process as
• connected series of actions
• a series of operations deliberately undertaken
• Process models are used to describe software
  development strategies
• Visually, a process model is a graphical
  representation that shows
• linear connections among actions or operations
• hierarchical connections among actions or
  operations

4
How Process Models Differ

• Number and type of tasks or activities involved
• How these tasks or activities are partitioned
  into subtasks or subactivities
• How the tasks are coordinated
• How output from one phase is input to the next one

5
Generic Activities

• Found in all models
• Inception phaseThe Why
• Definition phaseThe What
• Development phaseThe How

6
Umbrella Activities (span all phases)

• Project tracking
• Version control
• Reviews and/or inspections
• Quality assurance
• Configuration management
• Document preparation and production
• Facilitating reuse
• Risk management
• Testing

7
? Code-and-Fix Model

• What we all do when left by ourselves ?
• In fact, this is not a model at all
• Problems
• No specifications
• No design

8
Code and Fix

• Add design and its not so bad anymore

9
? Waterfall Model

• Mostly documentation-driven
• Solid back-arrows represent failure-recovery
  modes
• Dashed back-arrows represent restarting of the
  model for next-generation product
• Advantages
• Documentation is availableat every stage
• Maintenance easier maybe
• Easy to sell to management

10
Problems with the Waterfall Model

• Real projects rarely follow a sequential flow
• Stating all requirements at the beginning of a
  project is difficult, maybe even impossible
• Customer must have patience (lots of it), since
  the product is not available until very late in
  the development cycle
• Still can work for projects that are well
  understood, especially projects contracted under
  milspec

11
? MinimalPrototyping Model

• Product developed as a sequence of prototypes
• Prototype may be thrown away, or may evolve into
  end product
• Used when
• Proof-of-concept needed to convince the
  management
• Requirements are not well known and understood
• Human-computer interaction is important

12
? Better Prototyping Model
Cutover
13
? MinimalIncremental Model

• Divide project into builds, then do follow the
  waterfall process for each build
• Successive builds add functionality, perhaps also
  quality
• Main idea is to have a functional product at the
  end of each build

14
? Better Incremental Model
15
? MS Synchronize-and Stabilize Model

• Interview paying customers
• Based on that, develop sellable requirements
• Based on that, develop system specifications
• Based on that, divide project into 3 or 4
  sequential subprojects
• If 3 subprojects, then each one covers 1/3 of
  the features
• Each subproject scheduled for 2-4 months, with
  20-50 buffer (slack)
• First subproject addresses the most critical
  features final subproject addresses the least
  critical features

16
MS Synchronize-and Stabilize Model

• Within a subproject, daily builds are performed
• For each daily build, many small teams work in
  parallel
• At the end of the day teams check in code,
  synchronize parallel threads
• Automated testing and debugging occurs overnight,
  after each sync
• Code that breaks a build must be fixed next day
  all other bugs added to active list
• At the end of a subproject the most recent
  build is stabilized and frozen

17
MS SS Daily Builds

• A new build of the product is built and
  released every day
• Forces engineering discipline
• Daily syncing assures minimal divergence between
  parallel threads
• Build number indicates build date (40730 July
  30th, 40810 August 10th)

18
MS SS Daily Builds

• Central build lab picture on later slide
  produces daily builds for entire division
• Staffed 24/7
• Each product team has a build facilitation
  developer (BFD) on call with beeper to help with
  any build problems with that product

19
MS SS Daily Builds

• Build process
• Developers check in code changes late in workday
• Build team syncs source code tree ( midnight)
• Automated build launched ( 4 AM)
• Build Verification Testing (BVT) commences
• If a problem arises during BVT, the build team
  beeps the on-call BFD, gets hot fixes, restarts
  build from point of interruption
• Build is complete and verified ( 1 PM)

20
MS SS Daily Build Lab
21
MS SS Nominal Timeline
RTM Release to Manufacturing
1/3 of features
1/3 of features
1/3 of features
Design frozen
22
MS SS Milestones
23
MS SS Milestones ZBB
The devs are trying to get to zero bugs. The
testers are trying to find bugs. Once convergence
gets going, the daily open bug count starts to
decrease, as devs fix 'em faster than testers
find 'em. At some point, the number of bugs drops
to zero for a (usually) brief shining moment.
From Jason Zions via Eric Gunnerson's C
Compendium
24
MS SS Milestones ZBB
From this point forward, bugs are being resolved
faster than new bugs are found
25
MS SS Milestones ZBB
26
MS SS Milestones ZBB
27
Stabilization

• Code complete, major feature work complete
• Dependencies satisfied
• Focus shifts to fixing bugs in locked design
• Supreme justification now required for design
  changes
• Bug trends plotted
• Newly opened bugs
• Newly resolved bugs
• Trendline towards ZBB ?

Cutover
28
MS SS Progress Metrics
29
MS SS Bug Tracking

• Bugs and work-items tracked within internal
  bug-system
• Bugs triaged and assigned priority
• Priority 0, 1, 2, 3, 4
• Bugs fixed in priority order
• Daily status mails sent to entire division
  tracking bug status
• incoming bugs
• resolved bugs
• bugs per dev ouch!
• Once product is feature complete, team works to
  drive down the number of open bugs to near zero

30
MS SS Bug Query
31
MS SS Bug Detail
32
MS SS Ship Mode Glide Path

• Large projects glide in as opposed to end
  suddenly
• Like a super-tanker -- you cant dock the ship
  abruptly
• Key set of steps along the glide path to the
  end-game
• Lock the feature-set and stop adding/changing
  design of features
• Complete a full test pass to find all bugs in the
  locked design
• Push for a zero bug bounce (ZBB) on the locked
  design
• Triage all non-must-fix bugs out of the system

33
? Extreme Programming (XP) Model
34
Extreme Programming (XP) Model

• Predecessor of the Agile model
• Cousin of the incremental build model, with
  increased focus on people
• Requirements expressed as peoples stories
• Estimate duration and cost of each story
• Select stories for next build
• Each build is divided into tasks, which are
  continuously integrated
• Stories similar to a Use Case Scenario, but less
  formal

35
Extreme Programming (XP) Model
36
Extreme Programming (XP) Model
37
Extreme Programming (XP) Model
38
? Agile ModelNotable Features of XP Assimilated
into the Agile Model

• Trusting and empowering the client
• Client (or clients rep) is always present
• No permanent specializations within the team
• Pair programming, changing drivers
• Test-first approach (AKA TDD)
• Continuous refactoringrebuilding and
  improvement of the code without changing its
  external behavior

39
Agile Terminology Agility

• Agile nimble
• In humans
• Ability to start, stop, and move the body quickly
  in different directions
• In business
• Refers to the ability to respond quickly to micro
  changes, thereby reducing cycle times, especially
  in responding to customers
• Contrasts with adaptable, which refers to the
  ability to respond quickly to macro changes, such
  as a change in legislation, entrance of a strong
  competitor

40
Agile Terminology Chaordic

• Exhibiting properties of both chaos and order
• RealisticReflects the blend of chaos and order
  inherent in the external environment and in
  people themselves
• Anti-establishment assumption Things get done
  because people adapt, not because they slavishly
  follow processes

41
Agile Manifesto

• Individuals and interactions over processes and
  tools
• Working software over comprehensive
  documentation
• Customer collaboration over contract
  negotiation
• Responding to change over following a plan

42
Agile Objectives

• To increase responsiveness of teams to
• evolving requirements
• an involved client (participatory development)
• To reduce overhead, speed development
• To focus on people, collaboration, communication
• To deliver a useful system
• Not a showcase system, but
• Meets the clients business needs

43
Agile Objectives

• To craft well-(re)factored code
• To use low-tech tools
• To empower developers and clients
• Dis-empowers management because
• Developers get some budgetary authority
• Clients get full approval authority
• To put iterations in a time box
• To get and give immediate feedback

44
Agile Project Planning

• Plan in appropriate detail
• in depth for the short term
• in broad strokes for the long term

45
Agile Project Planning

• The initial scoping plan get an overall feel
  of where your project is going and come up with
  some broad estimates for these
• The broad increment plan prioritizing and
  scoping.
• The customer is responsible for determining
  business priority
• The detailed increment plan will contain a list
  of tasks and who is responsible for them

46
Agile Project Planning

• Realities drive the planning, not vice versa
• Examples of realities
• feedback on estimates
• feedback from the customer
• potential design improvements
• new or changed requirements
• bug reports and fixes

47
Visual Agile Model
48
Visual Agile Model
49
Visual Agile Model
50
Visual Agile Model
51
When to Apply Agile Methodologies

• Problems characterized by change, speed, and
  turbulence are best solved by agility
• Accelerated time schedule combined with
  significant risk and uncertainty that generate
  constant change during the project.
• Is your project more like drilling for oil or
  like managing a production line?
• Oil exploration projects need Agile processes
• Production-line projects are often well-served by
  rigorous methodologies

52
Adoption Rate of Agile Techniques
(c) 2007 by Scott W. Ambler www.ambysoft.com/surve
ys
53
Length of Iterations ( respondents)
(c) 2007 by Scott W. Ambler www.ambysoft.com/surve
ys
54
Agile Team Size
(c) 2007 by Scott W. Ambler www.ambysoft.com/surve
ys
55
Effectiveness of Various Practices on Agile Teams
(out of 5)
(c) 2007 by Scott W. Ambler www.ambysoft.com/surve
ys
56
? Spiral Model

• Waterfall model risk analysis iteration
• Radial dimension of the spiral cumulative cost
  to date
• Angular dimension of the spiral progress toward
  the goal

57
Spiral ModelFull Version
58
Spiral Model Risk Analysis
59
Spiral Model Somewhat Simplified
60
Spiral Model Very Simplified
http//bruce.engr.ucf.edu/swe/project/project_eel
5881/fig-3.gif
61
Spiral Model Overview

• Each phase preceded by
• Analysis and evaluation of alternatives
• Risk analysis
• For each proposed next step, how would taking
  that step affect the overall project?
• Each phase followed by
• Evaluation
• Planning of next phase

62
Analysis of Spiral Model

• Strengths
• Iterative
• Concentrates on risk analysis and management
• No distinction between development and
  maintenance both consist of modifying the model
• Capable of tackling problems of any size
• Weaknesses
• For large-scale software only
• For internal (in-house) software only difficult
  to do for external customers because of risk
  analysis

63
? RAD Model
64
? Formal Methods Model
65
Formal Methods Model

• Specify, develop, verify a system by applying
  rigorously defined mathematical transformations
• Discovers ambiguity, incompleteness,
  inconsistency by mathematical analysis
• Main problem understandability
• Users dont know cannot read, validate models
• Developers dont know need special training
• Functionality may be difficult to express in
  mathematical terms
• Once thought very promising, but not any more

66
? Fountain Model

• Overlap implies parallelism
• Arrows imply recycling (addition of reusable
  components to the pool)

67
? Component Assembly Model

• Object technologies are a necessary but not a
  sufficient condition
• Building blocks must offer customization and
  introspection
• Problems
• Finding reusable components
• Adapting components to a specific task

68
Conclusions

• Different life-cycle models exist, each with its
  own strengths and weaknesses
• Criteria for deciding on a model include
• Nature of the project
• Management preferences
• Skills and experience of developers
• Nature of the product