Software Lifecycle Options

1
Software Lifecycle Options

• From Theory to Practice

2
Goals

• Understand the drawbacks of the Waterfall Model
  in practice
• Understand the Spiral Model as an alternative to
  the Waterfall Model
• Understand the phases of the Spiral Model
• Understand how Software Inspection works

3
The Waterfall Model
Adapted from The Engineering of Software by
Hamlet Maybee (2001)
4
More on Modeling

• The Waterfall Model provides a convenient
  delineation of software phases, with clear,
  distinct boundaries.
• Unfortunately, though the Waterfall Model
  organizes phases well in theory, the development
  process in practice is very rarely as ordered.
• Other models lend themselves more to the actual
  practice of development ...

5
Other Models of the Lifecycle

• Exploratory Programming
• Good for small problems
• Good for problems that are not well-defined
• Usually seen as a sub-component of the Spiral
  Model
• Spiral Model
• Developed by the same person as the Waterfall
  Model
• Based on risk
• Goal is to develop intermediate products
  (prototypes) that can be tested to see if it is
  worth pursuing the product line any further.
• Product can be abandoned at any time (minimal
  loss)

6
The Spiral Model
Coding
Design
Testing
START
Requirements/Specification
Adapted from The Engineering of Software by
Hamlet Maybee (2001)
7
Balancing Theory Practice

• The Waterfall Model should be seen as a goal to
  attain, with each of its distinct phases in mind.
• In practice, the Spiral Model might fit better.
• Regardless, Hamlet and Maybee (2001) identify two
  important, sometimes competing, pressures on the
  process
• Keeping out-of-phase activities to a minimum.
• Tracking solid ideas, even if they dont fit in
  the current phase.

8
Requirements/Specification

• Requirements
• Documentation of user requirements
• INPUT User comments and needs
• PRODUCT Document for both internal use and the
  user
• Specification
• Difficult sometimes to distinguish from
  Requirements
• More precise statement of the what of the
  application
• Avoid describing the how
• INPUT The Requirements documentation features
  added that need no user input
• PRODUCT A document to be used by code designers

9
Design

• Two Phases
• Architecture High Level design that
  identifies subsystems, how subsystems communicate
  with one another and how each subsystem is
  mapped to individual requirements (listed in
  the Specification)
• Detailed design Low Level design that
  deconstructs each subsystem similar to algorithm
• Hamlet Maybee (2001) report that a good Design
  Document should be detailed enough that coders
  will be able to code and test a subsystem without
  understanding how that subsystem fits outside it.
• INPUTS The Specification Document
• PRODUCT Design Document for use by coders.

10
Coding

• Most of the work should be done in the design
  phase.
• Inverse relationship
• More work in the Design Phase Shorter time
  spent on coding
• Poor work in the Design Phase Much longer time
  spent on coding
• Code Re-use
• Finding larger modules that can be re-used
  throughout the application is time-saving
• Possible Hurdles
• Documenting exactly what the module does
• Understanding how the module will fit in the
  larger picture Will it work properly with the
  rest of the product?

11
Coding (continued)

• INPUTS The Design Document
• OUTPUTS Individual application modules that can
  be tested.

12
Testing

• Most of the work should be done before the phase
  begins creating of a testing document.
• Two types of testing
• Testing for errors
• Quality/Usability testing

13
Software Reviews

• Document authors are poor critics of their own
  work
• Should be done at the end of each phase
• Types of Reviews
• Walkthrough Less formal Document author takes
  a listener on a verbal tour (Hamlet Maybee,
  2001) through the document.
• Inspection More formal process

14
Software Inspection

• Finds many problems normally uncovered in testing
  preemptively.
• Requires a large investment upfront
• The Software Inspection team
• Author answers questions about the product.
• Moderator keeps the discussion on track.
• Recorder documents all problems uncovered in
  detail At the end of the discussion, creates an
  Inspection Report with the moderator.
• Inspectors raise questions about the product
  Must seek to ask questions and not suggest
  immediate solutions.
• Goal of Inspections To uncover errors, NOT to
  suggest immediate solutions.

15
Resources

• Hamlet, Dick and Joe Maybee. The Engineering of
  Software Technical Foundations for the
  Individual. Boston Addison Wesley Longman, Inc.,
  2001.

16
Questions?