Miscellaneous Stuff

 anyone new to the class?

 Assignment 1

 project website and proposal due next class

(Thursday)
 Project Stuff

 Team issues
 Proposal issues
– Project title
– Team members (skills, anticipated role within and
contributions to the project)
– Project website URL
– Objectives of project
– Description of project (why do you want to do it, what
features do you anticipate it will have, anticipated life-
cycle model, anticipate language(s), special needs)
 Website issues
– Title, names (contact info), meeting summaries, docs
 CHAPTER 3

SOFTWARE
LIFE-CYCLE
MODELS
 Software Life-Cycle Models

 Life-cycle model
 The steps through which the product
progresses
– Requirements phase
– Specification phase
– Design phase
– Implementation phase
– Integration phase
– Maintenance phase
– Retirement
 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
Build and Fix Model
 Build and Fix Model

 Problems
– No specifications
– No design
 Totally
unsatisfactory
 Need life-cycle
model
– “Game plan”
– Phases
– Milestones
Waterfall Model (contd)
 Waterfall Model (contd)

 Characterized by
– Feedback loops
– Documentation-driven
 Advantages
– Documentation
– Maintenance easier
 Disadvantages
– Specifications
 Rapid Prototyping Model

 Linear model
 “Rapid”
 Three Key Points

 Do not turn into product

 Rapid prototyping may replace specification
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 model
– Many successes
– Client needs
 Rapid prototyping model
– Not proved
– Has own problems
 Solution
– Rapid prototyping for requirements
phase
– Waterfall for rest of life cycle
 Incremental Model

 Divide project
into builds
 Incremental Model (contd)

 Waterfall, rapid prototyping models

– Operational quality complete product at end
 Incremental model
– Operational quality portion of product within weeks
 Less traumatic
 Smaller capital outlay, rapid return on investment
 Need open architecture—maintenance
implications
 Variations used in object-oriented life cycle
Incremental Model (contd)
 Incremental Model (contd)

 More risky version—pieces may not fit

 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

 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
XP Project
XP Iteration
XP Development
XP Coding
 Evaluating XP

 XP has had some successes

 Good when requirements are vague or
changing
 Too soon to evaluate XP
 Synchronize-and Stabilize Model

 Microsoft’s life-cycle model

 Requirements analysis—interview potential
customers
 Draw up specifications
 Divide project into 3 or 4 builds
 Each build is carried out by small teams
working in parallel
 Synchronize-and Stabilize Model (contd)

 At the end of the day—synchronize (test and

debug)
 At the end of the build—stabilize (freeze build)
 Components always work together
– Get early insights into operation of product
 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

 If risks
cannot be
resolved,
project is
immediately
terminated
Full Spiral Model (contd)
 Analysis of Spiral Model

 Strengths
– Easy to judge how much to test
– No distinction between development,
maintenance

 Weaknesses
– For large-scale software only
– For internal (in-house) software only
 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
 Object-Oriented Life-Cycle Models

 Need for iteration within and between phases

– Fountain model
– Recursive/parallel life cycle
– Round-trip gestalt
– Rational Unified Process (RUP)
 All incorporate some form of
– Iteration
– Parallelism
– Incremental development
 Rational Unified Process

 Commercial product from IBM

 http://www.rational.com/rup/
 RUP

 Four cycles
– inception
– elaboration
– construction
– transition
– each followed by a major milestone
 RUP: Inception Phase

 Purpose
– establish the business case and define the project
scope
 Selected deliverables
– A vision document
– An initial use-case model
– An initial project glossary
– An initial business case
– An initial risk assessment
– A project plan
– One or more prototypes
 RUP: Lifecycle Objectives Milestone

 Stakeholder buy-in
 Requirements understanding
 Credibility of estimates
 Prototype evaluation
 RUP: Elaboration Phase

 Purpose
– analyze problem, establish a sound architecture,
develop a project plan, and eliminate high risk elements
 Hardest phase
 Selected deliverables
– A use-case model
– An architecture description
– A development plan
 RUP: Lifecycle Architecture Milestone

 Is the vision stable?

 Is the architecture stable?
 Is the plan detailed enough?
 Does everyone agree the the plan can achieve the
vision?
 Re-evaluate estimates
 RUP: Construction Phase

 Purpose
– develop remaining components and into them into the
product
 Should be incremental
 Deliverables
– the software product
– the user manuals
– a description of the current release
RUP: Initial Operational Capability Milestone

 Is the product stable and mature enough for

users?
 All are stakeholders ready for release to users?
 RUP: Transition Phase

 Purpose
– to transition the product to the user community
 Selected objectives
– beta testing
– training
– roll-out to marketing, distribution, and sales
– achieving final product baseline as rapidly and cost
effectively as practical
 RUP: Product Release Milestone

 Is the user satisfied?

 RUP: Iteration

 Product release may coincide with the inception

phase for the next cycle
 Book Assignment

 Read chapter 3
– Problems 3.5, 3.6, 3.7, 3.8
– Follow (AND READ) the guided tour at
http://www.extremeprogramming.org
» DEMO
– Describe what you would like and not like if you worked
in an organization that used extreme programming.
– Due: February 3rd
 Project Assignment

 Website
 Proposal