Software Development

Processes
Topics include:
•Process models
•Risk Management
•Prototyping

Readings:
•Sommerville, Chap. 3 and 17.1

(CS340 J. Knight & T. Horton 2008) 1

University of Virginia
The Software Lifecycle
Requirements Analysis Determine Customer Needs (What)

Specification State Customer Needs (What)

Design Design A Solution (How)

Implement Solution
Implementation
(How)

Show Solution Meets Specification Verification

Keep Solution Working Maintenance

2
(CS340 J. Knight & T. Horton 2008)
University of Virginia
Software Processes
 Process means the events or tasks a development
organization does, and their sequence
 Again, think about construction
 Organizations want a well-defined, well-understood,
repeatable software development process. Why?

 Find and repeat good practices

 Management: know what to do next; know when we’re
done with current task; know if we’re late; estimate time
to completion, costs; Etc.
 New team-members know what to do

3
(CS340 J. Knight & T. Horton 2008)
University of Virginia
What’s Your Process?
 Various Processes Are Advocated For SW Development:
 Models: Waterfall, Spiral Model
 Industry methodologies: Unified Process, XP, Scrum, etc.
 Government Imposed Standards:
 DoD Standards 2167, 2167A
 FAA Standard DO-178A, DO-178B
 Every organization does have a process
 Might be chaos every time
 Code And Fix - No repetitive organization
 But, should be defined, documented, planned and managed
 Should be based on the nature of the projects the team is building

4
(CS340 J. Knight & T. Horton 2008)
University of Virginia
Why Learn About Process Now?
 There are general principles about:
 What we do at various stages of SW development
 How to inject quality into SW
 How to avoid early problems that cause huge
problems later
 Recognize that SE is not just writing code
 No matter what process you end up doing,
these general principles are the most important
“take-away” from this material

5
(CS340 J. Knight & T. Horton 2008)
University of Virginia
Waterfall Model
 Early, simple model
 Do the phases shown before, in order
 Complete one phase before moving on to the next
 Produce a document that defines what to do at the start of
each phase
 At end of each stage, a document or other work-product is
produced: requirements doc, design doc, code, etc.
 Little or no iteration (going back to previous phase)
 The order of phases/stages is generally “right”, but…
 Following the waterfall precisely is not effective in real
development practice.

6
(CS340 J. Knight & T. Horton 2008)
University of Virginia
Flaws of the Waterfall
 Need iteration and feedback
 Things change (especially requirements)
 Change late requires updates to earlier work
 Often need to do something multiple times, in stages
 Customer only interacts at beginning and end
 As described, it’s very rigid
 Not realistic to freeze results after each phase
 The model does not emphasize important issues
 Risk management
 Prototyping
 Quality

7
(CS340 J. Knight & T. Horton 2008)
University of Virginia
A Quality-based View
 People who do testing and SW
Quality often re-draw the
waterfall to emphasize testing
activities that are not explicit in
the last diagram

 Is this a model organization a

group can “follow”?
 No. It’s a big-picture view for
understanding.
 A company might have a
detailed standard plan (their
process)
 It could reflect this.

8
(CS340 J. Knight & T. Horton 2008)
University of Virginia
The Spiral Model
 Important features
 Risk analysis and other management are explicitly
shown in the model at each stage
 Prototyping and iterative development “fit” in this
model
 Repetition of activities clearly in model
 Suggests that alternatives can be explored

9
(CS340 J. Knight & T. Horton 2008)
University of Virginia
The Spiral Model

10
(CS340 J. Knight & T. Horton 2008)
University of Virginia
Features of the Spiral Process
Model
 Each cycle around the spiral can be like a
phase
 Each cycle has four stages
1. Determine objectives, constraints (i.e. plan!)
2. Identify and manage risks. Explore alternatives as
part of risk management
3. Develop and verify next stage or level of the product
 Depending on the spiral, “Product” might be a requirements
document, a high-level design, code, etc.
4. Review results and plan for next stage
 May include getting client/customer feedback

11
(CS340 J. Knight & T. Horton 2008)
University of Virginia
Is the Spiral Model the Answer?
 For some situations, yes. (There is no one answer.)
 Original study that analyzed the spiral model says:
 Intended for internal development of large systems
 “Internal”: developers and clients in same organization
 Intended for large-scale systems where cost of not doing risk
management is high
 But, the spiral model is important
 Historically
 And as an illustration of many desired features of a software
development process

12
(CS340 J. Knight & T. Horton 2008)
University of Virginia
Iterative Development
 Build systems in planned stages, and…
 Give to customer for feedback

 A focus of Agile Methods

 Reduces risk

13
(CS340 J. Knight & T. Horton 2008)
University of Virginia
Agile Methods
 Many light-weight or Agile Process Models
 Many developers and organization feel existing
process models have been too “heavy weight”
 Too many rules and documents. Inflexible. Not fun.
 The Agile Manifesto
 Examples:
 Best known example: Extreme Programming
http://www.xprogramming.com/xpmag/whatisxp.htm
 Scrum
 Crystal Clear
 Etc.
14
(CS340 J. Knight & T. Horton 2008)
University of Virginia
XP Process “Map”

 How does this compare to waterfall and spiral?

15
(CS340 J. Knight & T. Horton 2008)
University of Virginia
Manifesto for Agile SW Dev.
“We are uncovering better ways of developing software by
doing it and helping others do it. Through this work we
have come to value:
 Individuals and interactions over processes and tools
 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan

That is, while there is value in the items on the right, we

value the items on the left more.”
(from http://www.agilemanifesto.org)

16
(CS340 J. Knight & T. Horton 2008)
University of Virginia
Extreme Programming
 XP and many other agile methods try to be
alternatives
 XP says it’s: “a deliberate and disciplined
approach to software development.” (So it is a
process model.)
 Claims to be good for risky projects with dynamic
requirements, and when continuous customer
involvement is crucial (and possible)
 Emphasizes
 Team development: pair-programming
 Write tests before code (unit testing)

17
(CS340 J. Knight & T. Horton 2008)
University of Virginia
The Unified Process
 A widely-adopted process model in industry
 Originally developed by Rational (now part of IBM)
 More complicated model that what we’ve seen
 Try looking for books on this with Google or at
Amazon

18
(CS340 J. Knight & T. Horton 2008)
University of Virginia
Final Thoughts on Process
Models
 Every organization does have a process
 Might be chaos every time
 But, should be defined, documented, planned and
managed
 Should be based on the nature of the projects the
team is building
 People have strong feelings on this subject
about what works!
 (IMHO) There is no “silver bullet” here.
 I.e. no one thing that will solve all your problems all
the time.
19
(CS340 J. Knight & T. Horton 2008)
University of Virginia