Software Life-Cycle Models

Hans Van Vliet, Software Engineering: Principles and Practices, 3rd

edition, Wiley 2008. (Chapter 3)

Eric J. Braude, Software Engineering, An Object-Oriented
Perspective, Wiley, 2001. (Section 2.4. Identifying and retiring risks)

Roger S. Pressman, Software Engineering, A Practitioners
Approach, 6th edition, McGraw Hill, 2005. (Chapter 25. Risk
Management)
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
Q: In what order to perform these steps?
2
Many Life-Cycle Models
Several dimensions
Sequential vs. iterative
Whole vs. incremental
Elaborative vs. transformational
Use of prototype

Examples
Waterfall, Rapid prototyping, Incremental, Spiral,
Model-driven, Feature-driven, Unified Process
(UP), Extreme Programming (XP),
3
Build and Fix Model
Problems
No specifications
No design
Totally unsatisfactory
Need life-cycle model
Game plan
Phases
Milestones
4
Waterfall Model
Characterized by
Feedback loops
Documentation-driven
Operational product at end
Advantages
Documentation
Maintenance may be easier
Disadvantages
Customer may not be aware of
what getting
Costly when discrepancy found
in later stages
Sometimes freezes part of
development
May lead to badly structured
systems
5
Rapid Prototyping Model
(Throwaway)
Determine needs of
customer
Refine with interaction of
customers
Experiment with parts not
understood
Prototype system poorly
structured
Operational product at end



6
Evolutionary Prototyping
Process not visible (need
deliverables)
Need highly skilled team
Appropriate
Small teams
Part of system not well
understood
Short lifecycle system


7
Problem description
(outline)
Specification
Development
Validation
Initial version
Intermediate version
Final version
Concurrent
activities
Incremental Model
Divide project into builds
Operational quality portion
of product within weeks
Smaller capital outlay,
rapid return on investment
Need open architecture
maintenance implications
Requires skilled
developers
8
Incremental Model (Variation)
More risky versionpieces may not fit
9
Transformation Model
Viewed as a sequence of steps that transforms a specification
into an implementation
Use of formal specifications/models and transformation rules
Correctness by construction <-> program correctness proof
E.g., Model-driven development (MDD)
10
Transformation
/optimization
Requirements
analysis and
specification
Development
history
Reusable
components
Requirements
Formal
specifications
Formal specifications
(lower level)
Decisions, rationale
and trans. rules
Spiral Model
Keys: risk analysis and evaluation
Simplified form: Waterfall model
plus risk analysis
Precede each phase by
Alternatives
Risk analysis
Follow each phase by
Evaluation
Planning of next phase
11
Simplified Spiral Model
Focus on eliminating errors early
Examines level of effort
Accommodates growth and
change (evolution)
Restrictions
In-house development (not
contracted)
Good for large-scale systems
Requires training in risk
analysis and resolution

12
Full Spiral Model (contd)
13
Risk
A risk is something that may occur in the course of a
project, and which, under the worst outcome, would affect
it negatively and significantly [Braude 2001, Section 2.4].
Two types:
Those that can be avoided or worked around
Those cannot be avoided
Problems are those risks that have not been identified.
Risks must be managed!
Risk retirement is process whereby risks are reduced or
eliminated.
14
Risk Management Activities
Identification
Mindset: try to continually identify risks
Write down concerns and press all team members to think of
more
Retirement planning
Outline the steps that can be taken to retire the risk.
Prioritization
Options: likelihood (10 most likely), impact (10 most impact),
retirement cost (10 highest cost)
Formula: (11 - l) (11 - i) rc
Lowest is first to address
Retirement or mitigation
15
Types of Risks (Pressman 2005, Chapter 25)
Generic (every project)
Product size
Business impact (constraints imposed by mgmt)
Customer characteristics
Process definition
Development environment
Technology to be built
Staff size and experience
Product-specific (characteristics of product)
Examples?
16
Example Risks
Underestimation of size
Time lag in learning new tools
Lack of top management commitment
Personnel resign
Changing scope and/or objectives
Technical breakthroughschange in product
Unrealistic schedule
Personnel lack required knowledge or skills
17
Feature Driven Development (FDD)
Develop an
Overall
Model
Build a
Feature List
Plan by
Feature
Design by
Feature
Build by
Feature
1) Selection of domain
experts and development
teams
2) Completion of
requirements definition by
guidance team
Entry Criteria
Completion of:
a) the object model
(class, sequence
diagrams and
explanatory notes)
b) Interview Report
c) Feasibility Report
d) Use case scenarios
Exit Criteria
Completion of the
develop an overall
model process
Entry Criteria
Completion of the
build a feature list
process
Completion of the
plan by feature
process
Completion of the
design by feature for
each of the selected
features
Entry Criteria
Entry Criteria
Entry Criteria
Completion of:
a) feature list, including a
list of major feature sets
and a list of features
within each feature set
b) GUI
c) Models
d) Requirements
Completion of:
a) development plan,
consisting feature sets
with completion dates
Completion of:
a) design package,
comprising a design
document, referenced
requirements in the form of
documents, memos,
supporting documentation,
design alternatives, latest
object model, class and
method prologues, to do
task list on affected classes
for each team members
Completion of:
a) development of
one or more
features (client-
valued functions)
Exit Criteria
Exit Criteria
Exit Criteria
Exit Criteria
18
Exam Questions
What is Extreme Programming?
What are the advantages and disadvantages
of using Extreme Programming as
development model?
19