Software Lifecycle Options - PowerPoint PPT Presentation

1 / 16
About This Presentation
Title:

Software Lifecycle Options

Description:

Software Lifecycle Options From Theory to Practice Goals Understand the drawbacks of the Waterfall Model in practice Understand the Spiral Model as an alternative to ... – PowerPoint PPT presentation

Number of Views:96
Avg rating:3.0/5.0
Slides: 17
Provided by: bobmo3
Learn more at: http://cs.iupui.edu
Category:

less

Transcript and Presenter's Notes

Title: 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?
Write a Comment
User Comments (0)
About PowerShow.com