slide1 l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Object-Oriented and Classical Software Engineering Fifth Edition, WCB/McGraw-Hill, 2002 Stephen R. Schach srs@vuse.vand PowerPoint Presentation
Download Presentation
Object-Oriented and Classical Software Engineering Fifth Edition, WCB/McGraw-Hill, 2002 Stephen R. Schach srs@vuse.vand

Loading in 2 Seconds...

play fullscreen
1 / 45

Object-Oriented and Classical Software Engineering Fifth Edition, WCB/McGraw-Hill, 2002 Stephen R. Schach srs@vuse.vand - PowerPoint PPT Presentation


  • 590 Views
  • Uploaded on

Object-Oriented and Classical Software Engineering Fifth Edition, WCB/McGraw-Hill, 2002 Stephen R. Schach srs@vuse.vanderbilt.edu CHAPTER 3 SOFTWARE LIFE-CYCLE MODELS Overview Build-and-fix model Waterfall model Rapid prototyping model Incremental model Extreme programming

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Object-Oriented and Classical Software Engineering Fifth Edition, WCB/McGraw-Hill, 2002 Stephen R. Schach srs@vuse.vand' - Olivia


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

Object-Oriented and Classical Software EngineeringFifth Edition, WCB/McGraw-Hill, 2002Stephen R. Schachsrs@vuse.vanderbilt.edu

chapter 3
CHAPTER 3

SOFTWARE

LIFE-CYCLE

MODELS

overview
Overview
  • Build-and-fix model
  • Waterfall model
  • Rapid prototyping model
  • Incremental model
  • Extreme programming
  • Synchronize-and-stabilize model
  • Spiral model
  • Object-oriented life-cycle models
  • Comparison of life-cycle models
software life cycle models
Software Life-Cycle Models
  • Life-cycle model (formerly, process model)
  • The steps through which the product progresses
    • Requirements phase
    • Specification phase
    • Design phase
    • Implementation phase
    • Integration phase
    • Maintenance phase
    • Retirement
build and fix model
Build and Fix Model
  • Problems
    • No specifications
    • No design
  • Totally unsatisfactory: expensive since it changes code after it is produced! Plus no documentation done!
  • Need life-cycle model
    • “Game plan”
    • Phases
    • Milestones
waterfall model
Waterfall Model
  • Requirements determined by client & SQA group
  • Specs drawn up. Checked by SQA. Client signs.
  • Draw up software project management plan (detailed timetable for developing software). Plan checked by SQA. Client approves time and cost estimates.
  • Design phase begins.
    • may find incomplete, contrary, or ambiguous specs.
    • Then feed back to step 2.
    • client must approve new specs
  • Program.
    • may find design flaws: too slow, etc.
    • feed back to step 4 or steps 1, 2
    • integrate code as modules are finished
waterfall model7
Waterfall Model
  • Testing.
    • client does acceptance testing
    • deliverables include user manual and other documents
  • Installation.
    • Now in maintenance phase
    • Maintenance may require changes in specs.
    • May require changes in documents
waterfall model8
Waterfall Model
  • Characterized by
    • Feedback loops
    • Documentation-driven (no phase is done until docs are done!)
  • Advantages
    • Documentation is enforced
    • Every deliverable checked by SQA
    • Testing done in every phase
    • Maintenance easier
waterfall model cont
Waterfall Model (cont)
  • Disadvantages
    • Specifications
      • Joe and Jane Johnson build house. Architect gives 20 page specification document. Joe and Jane sign, but don’t understand.
      • This is exactly what software specs are like.
waterfall model cont10
Waterfall Model (cont)
  • Disadvantages
    • Specifications
      • Mark Marberry buys suit by mail. Does not get photos, but a written description. Mark buys based on the written description.
      • In same way client rarely sees software until it is finished in waterfall model
      • Note that using flowcharts doesn’t help visualize what the final software will do.
rapid prototyping model
Rapid Prototyping Model
  • A rapid prototype is a working model functionally equivalent to a subset of the product.
    • if product is an accounting system, prototype might only be the screens and report printing, but not DB connectivity.
  • First step in model is to develop rapid prototype.
  • When client accepts prototype, specs are drawn up.
rapid prototyping model12
Rapid Prototyping Model
  • Linear model
    • less need for feedback
    • working prototype has been verified by client, so specs more likely correct.
    • many design problems have already been identified.
  • “Rapid”
    • prototype built quickly
    • less feedback so entire process completed more quickly.
three key points
Three Key Points
  • Do not turn prototype into product
  • Rapid prototyping may replace requirements phase—never the design phase
  • Comparison:
    • Waterfall model—try to get it right first time
    • Rapid prototyping—frequent change, then discard
waterfall and rapid prototyping models
Waterfall and Rapid Prototyping Models
  • Waterfall model
    • Many successes
    • Client needs may not be met
  • Rapid prototyping model
    • Not proved
    • Has own problems
  • Solution
    • Rapid prototyping for requirements phase
    • Waterfall for rest of life cycle
incremental model
Incremental Model
  • Software is built piece by piece.
  • Divide project into builds
    • a build consists of code pieces from various modules interacting to provide a specific functional capability.
incremental model16
Incremental Model
  • Example builds:
    • project is a submarine
    • the navigation system is a build
    • the weapons control system is a build.
    • project is an OS
    • the scheduler is a build
    • the file management system is a build.
incremental model17
Incremental Model
  • At each stage of the model,
    • a new build is coded
    • then integrated into the structure
    • which is tested as a whole.
  • Process stops when product achieves target functionality (ie, satisfies specs).
incremental model18
Incremental Model
  • Manager decides how to break product into builds.
    • too few: get build-and-fix approach
    • too many: more time spent in integration testing than in implementing.
incremental model contd
Incremental Model (contd)
  • Waterfall, rapid prototyping models
    • Operational quality complete product at end
    • adequate testing and documentation.
    • had projected delivery date
  • Incremental model
    • Operational quality portion of product within weeks (at each build)
    • this satisfies a subset of requirements and client can begin using immediately.
  • Less traumatic…don’t change system all at once.
  • Smaller capital outlay, rapid return on investment
incremental model contd20
Incremental Model (contd)
  • Each additional build has to be incorporated into the existing structure.
  • Existing structure must be extensible.
  • Thus need open architecture—
    • maintenance easier….can add features easier
incremental model contd21
Incremental Model (contd)
  • Too easy to degenerate into the build-and-fix model.
  • Requirements, specs, and architectural design must be completed before implementing builds.
  • Contradictory requirements:
    • developer must view product as a whole to begin with a design that will support the entire product.
    • must also view product as a sequence of builds, each independent of the next
  • Variations used in object-oriented life cycle
incremental model contd22
Incremental Model (contd)
  • More risky version—pieces may not fit
    • As soon as the specs of one build finished, start the specs on the next, etc.

What if builds don’t fit together?

extreme programming
Extreme Programming
  • Somewhat controversial new approach
  • Stories (features client wants)
  • Estimate duration and cost of each story
  • Select stories for next build
  • Each build is divided into tasks
  • Test cases for task are drawn up first
  • Pair programming
  • Continuous integration of tasks
unusual features of xp
Unusual Features of XP
  • Computers are put in center of large room lined with cubicles
  • Client representative is always present
  • Cannot work overtime for 2 successive weeks
  • No specialization
  • Refactoring
evaluating xp
Evaluating XP
  • XP has had some successes
  • Good when requirements are vague or changing
  • Too soon to evaluate XP
synchronize and stabilize model
Synchronize-and Stabilize Model
  • Microsoft’s life-cycle model
  • A version of the incremental model
  • Requirements analysis—interview numerous potential customers
  • Extract a list of features with priorities set by the customers.
  • Draw up specifications
synchronize and stabilize model contd
Synchronize-and Stabilize Model (contd)
  • Divide project into 3 or 4 builds
  • Each build is carried out by small teams working in parallel
  • First build consists of the most critical features
  • Next build consists of next most critical features
  • etc
synchronize and stabilize model contd28
Synchronize-and Stabilize Model (contd)
  • At the end of the day—synchronize
    • put together the partially completed components
    • test and debug the resulting product
    • ensures that components always work together
  • At the end of the build—stabilize
    • test the build
    • freeze build (no more changes to specs allowed
  • Components always work together
    • Get early insights into operation of product from the frequent synchronizations
    • allows detection of bad requirements and early modification
spiral model
Spiral Model
  • Every software development project has risks
    • key personnel leave
    • hardware manufacturer goes backrupt
    • find too little (or much) has been spend on testing and QA
    • new breakthroughs render the product useless
    • competitor releases a cheaper/better product
    • components of an incremental process don’t fit together
    • etc.
spiral model30
Spiral Model
  • One approach to reduce risks: prototypes
    • rapid prototyping models used prototypes to reduce risk during requirements phase.
    • example: can build a simple form of a product to test a new algorithm.
    • The spiral model is based on the use of prototypes through all phases of the development cycle.
spiral mode l
Spiral Model
  • Simplified form
    • Waterfall model plus risk analysis
  • Precede each phase by
    • Alternatives
    • Risk analysis
  • Follow each phase by
    • Evaluation
    • Planning of next phase
simplified spiral model
Simplified Spiral Model
  • If risks cannot be resolved, project is immediately terminated
  • prototypes used to provide info about certain classes of risks.
    • example: timing measurements on a prototype indicate if product will be too slow
simplified spiral model33
Simplified Spiral Model
  • Prototypes cannot solve all risks:
    • example: can a software team that builds small products also build a large one?
    • example: can a hardware contractor be trusted to deliver on time?
full spiral model
Full Spiral Model
  • Radial dimension: cumulative cost to date
  • Angular dimension: progress through the spiral
  • Each cycle of the spiral corresponds to a phase
    • phase begins in top left quadrant
full spiral model35
Full Spiral Model
  • Stage 1
    • determine objectives for that phase
    • determine alternatives for achieving those objectives
    • constraints imposed on those alternatives
    • result: strategy for achieving objectives.
    • strategy analyzed from the viewpoint of risk
      • attempt to resolve every potential risk
      • build prototypes if necessary
      • If risks cannot be resolved, may terminate immediately
      • or may scale back project
full spiral model37
Full Spiral Model
  • Stage 2
    • Development step
    • corresponds to the requirement phase of the waterfall model
    • validate requirements
    • life-cycle plan developed
    • go to next phase
analysis of spiral model
Analysis of Spiral Model
  • Strengths
    • Emphasis on alternatives and constraints support software reuse
    • Easy to judge how much to test: analysis of risks shows how much testing to be done
    • No distinction between development, maintenance so maintenance not overlooked by software professionals
analysis of spiral model40
Analysis of Spiral Model
  • Weaknesses
    • For large-scale software only
      • if risk analysis costs as much as development not worth it!
    • For internal (in-house) software only
      • external developers don’t want the project halted!
      • plus, can’t break a contract with an external contractor
      • internal developers can just be reassigned to a new project
    • Need highly trained software developers who are skilled at pinpointing and analyzing possible risks.
object oriented life cycle models
Object-Oriented Life-Cycle Models
  • Need for iteration within and between phases
    • Fountain model
    • Recursive/parallel life cycle
    • Round-trip gestalt
    • Unified software development process
  • All incorporate some form of
    • Iteration within phases
    • Parallelism between phases (overlap of activities)
    • Incremental development
  • Danger
    • CABTAB (code-a-bit test-a-bit)
    • danger of disintegrating into random approach of developing piecemeal.
fountain model
Fountain Model
  • Circles represent phases
  • Overlapping circles indicate parallelism
  • Arrows represent iteration within a phase
  • Smaller maintenance circle represents reduced maintenance in OOP
conclusions
Conclusions
  • Different life-cycle models
  • Each with own strengths
  • Each with own weaknesses
  • Criteria for deciding on a model include
    • The organization
    • Its management
    • Skills of the employees
    • The nature of the product
  • Best suggestion
    • “Mix-and-match” life-cycle model