Chapter 5

Life-Cycle Phases
From
Software Project Management
By
Walker Royce (of IBM)
And Slides on Spiral by Barry Boehm

1
 Introduction
 On one hand,
 Do we spend far too much time on analyses and paper
studies?
 Do we delay actually doing the builds: the development
baselines?
 Very easy to do… Some feel in general that this is true…
 On the other hand,
 Do we jump into designs and coding, and hack the heck
out of an application in attempts to get it to work?
 Lots of people think we do this too….
 Class discuss:
 What do you do?
 What do you think corporations think they do?
2
 Introductory Statement:

 Walker Royce feels that we need BALANCE

between research and development (R&D) and
production activities
 Need some kind of balance between:
 Concentrating on capturing and modeling functionality
and
 Building a robust product that has the performance,
reliability, and scalability customers desire….
 We are after a development life-cycle BALANCE…

3
 Finer Granularity

 Further, we need a process that supports this

balance.
 Need this stated more precisely:
  Need a process to help balance:
 Planning, capturing, and modeling requirements and
establishing a baseline architecture,
 with
 Continuous assessment, measuring risk, and
testing to ensure progress and quality
 with
 Evolution and verification of the application’s
functionality through series of customer
demonstrations and ultimate validation.
4
Engineering and Production Stages
 Royce claims to achieve the ROI for software
development, we need to use a ‘manufacturing
process’ that is characterized by the

 highest utilization of automated development tools and

 use of component-based approaches to development.

 He likens a desirable software process to a

manufacturing process:
5
Engineering and Production Stages
 He breaks all activities down into
 Engineering and Production

 Engineering work: This centers on risk

reduction, prototyping, establishing architectural
baseline, assessment, analysis, design, and
planning…
 Implies a smaller team up front.
 Production work: programming and unit test,
system and integration testing, demonstrations,
assessment, base-lining (alpha, beta, …)
configuration, and releases; operations
 Note that production includes operations… 6
 Two Stages: Far Too Abstract
 BUT, he argues a life cycle of two stages is far too abstract to track the many
detailed activities – all with actors, activities, and artifacts….
 So, he maps RUP Phases into these more comprehensive phases.
 Enter: Engineering Phase = Inception and Elaboration
 Enter: Production Phase = Construction and Transition

 To wit:

 Engineering, i.e., Inception and Elaboration, focuses on the concept (idea)

of the application and its architectural components (analysis and
preliminary design – perhaps a wee bit of detailed design)
 Artifacts are established and base-lined; (Configurations…)

 Production, i.e., Construction and Transition, focuses on programming,

testing, releases and converting / establishing operational capabilities
 Implies that artifacts from earlier stage (engineering) more difficult to
change as activities more ‘downstream activities’ occur

7
 Royce Claims that:
 These phases can be mapped into the famous
Spiral Model for Software Development
developed by (Barry Boehm) (shall see ahead)
 Now have:
 Conventional Software Development Model (as
represented by the Waterfall Model and its many
variants;
 OOSE approach (as represented by the RUP);
 Spiral Model…Let’s discuss this important model…

8
 Spiral Model - Overview
 Spiral Model is another incremental model.
 Embraces (well known for these:)
 prototyping,
 iterative software development, and
 risk assessment.
 Model is graphed like a spiral.
 Development can be halted at the end of any
cycle…depending on evaluation of previous
‘cycle.’
 IS ROI still looking good?
 Are expended costs in line with anticipated costs –
so far?
 Have risks been mitigated?
 Functionality delivered evolving properly via high
priority requirements? And much more….. 9
 Spiral Model
 Very much a Risks-Driven Approach
 Different idea of software development.
 How does this project affect the developers
and the clients?
 How does each step in the project affect
its overall development?
 Not used in previous development models.
 They were usually code-driven or document-driven.

10
Previous Software Process Models
 An evolution of models
–Code & Fix
–Stagewise & Waterfall
–Evolutionary Development
–Others…

 Code & Fix

• First,
elementary model
• Write code now; fix it later
• No planning involved
• Problems:
– Code is poorly structured.
– The software developed was usually a poor match for users’
needs.

11
 Stagewise & Waterfall
Born out of the shortsightedness of the Code &
Fix model.
- need for a design phase, requirements phase,
and a testing phase.

 First used to develop SAGE (Semi-Automated

Ground Environment), an early warning
system for the Cold War era.
12
 Stagewise
 A development process of successive phases.
– Phases included operational plan, operational
specs, coding specs, coding, parameter
testing, assembly testing, shakedown, system
evaluation.
 Underwent two refinements in 1970.
 Now referred to as the Waterfall Model.

13
 Waterfall Model
Introduced:
– Feedback loops across multiple stages:
Validation and verification steps.
– Prototyping via a “build it twice” step alongside of
requirements and design.

• Difficulties exposed even as revisions were made to

the model.
– Required elaborated documents. (Document-
driven; lengthy development cycles, etc.
– Led to pursuing stages of development in the
wrong order

14
15
 Evolutionary Development
Evolution of the system in directions based on
experience.
Provides rapid initial operational capability.
“I can’t tell you what I want, but I’ll know it when I see it.”
Flexible, yet uncertain approach.

Evolutionary Development Problems:

No formal design phase (same problem as Code & Fix).
One bad assumption – the unplanned paths “will” be
compatible.
Hard-to-change code resulted.
Many problems when new software was incrementally 16
replacing old software
17
18
 Spiral Model - Overview
 In the Spiral Model, prototyping, evaluation, planning, and all engineering
and production activities are executed in different quadrants. (Different
variations of the model…)

 But the basic notion of iteration is very firmly established.

 For each ‘cycle’:

 risk is assessed,
 more design and development is undertaken,
 the work products and evaluated, and
 planning for the next cycle in the spiral is undertaken;
 Iterate…..

 Please note that in reality, the Spiral Model curve is actually

skewed to the right, as the spirals do not ‘carve’ out equal
‘areas.

 Area in each cycle is a determinant of effort and cost…. 19

 Spiral Model - Overview
 Quadrants in a cycle:
 Creation of a prototype as a means to gather and lock
in requirements; gain customer buy-in.
 Risk is assessed and if acceptable,
 Development activities then follow using the waterfall
model
 Specifications are created from the prototyping
effort, Then Requirements, Analysis, Design,
Implementation, … ensue
 Review and release are undertaken…

 Restart and iterate as above…

 Planning for next iteration is undertaken – or not…
 Iterate until application is developed fully and totally
released to the clients. 20
 Spiral Model - more
 May be several cycles of prototyping…but as prototypes
evolve, these may become official releases of the product
(internal or external).
 Before a cycle ends, the review discusses experiences,
assesses risk, and decision made whether or not to proceed.

 Note: for each cycle, FIRST thing before embarking is to

decide what are the major requirements to be handled.
 Adjust the architecture and requirements and/or project
plan as needed.

 The Spiral forms the basis for entire life cycle of the product.
 Thus, the Spiral Model continues the spiral process for
Maintenance, and the model continues until the application is
ultimately retired or replaced…
21
 Spiral Model and the RUP Phases
R & D Stage Production Stage

Inception Elaboration Construction Transition

Idea Architecture Beta Releases Products

Prototypes Change managed baselines

Coarse artifacts Elaborate artifacts
Major risk items Low Risk Items
Creative, judgment Engineering, reasoned
Business Rules Well-instrumented processes22
Stakeholder Vision ‘Skewness:
 Back to our Process Model (RUP)
 Let’s look more closely at the phases for our process
model:
 Inception
 Elaboration
 Construction
 Transition
 Each phase has
 primary objectives,
 essential activities, and
 primary evaluation criteria
to judge its success at milestone time.
Since the process that is underpinning our management
of software processes and personnel course is the RUP,
it is imperative that we understand this management
process, the RUP, as much as possible 23
 Inception Phase (1 of 3)
 Overriding Goal: achieve concurrence among
stakeholders on life-cycle objectives for the project
(milestone: LCO)
 Primary Objectives: (by end of phase…)
 Establish project software scope and boundary conditions
 Includes operational concept, acceptance criteria, and a clear
understanding of what is and what is not intended in the product
 Identify critical use cases (core functionalities) of system
and the primary scenarios that will drive the activities
 Demonstrate at least one candidate architecture against
some of the primary scenarios (walk through it…)
 Estimate the cost and schedule for the entire project
(including detailed estimates for the elaboration phase)
 Estimate potential risks (sources of unpredictability)
 Know These!
24
 Inception Phase (2 of 3)
 Essential Activities
 Develop Project Scope
 Capture requirements and concept of operations  repository
 Describes users’ view of the requirements
 Repository contains information used to define problem space
 Repository must contain information to capture acceptance criteria
 Develop a Candidate Architecture and Demonstrate it
 Repository contains enough information to demonstrate at least a
single candidate architecture
 This might be at a very high level, such as deployment level;
 A general layered architecture may also be demonstrated.
 But considerable Requirements have not yet been done and almost NO
Analysis and Design have been undertaken.
 Repository must include enough data to support make/buy
decisions so that cost, schedule, resources can be ‘costed out.’
 Planning and Preparing the Business Case
 Risk management strategies, staffing, general iteration plans,
cost/schedule/profitability tradeoffs are all evaluated.
 Environmental (Infrastructure) support is defined.
 ROI, market share, etc.
25
 Inception Phase (3 of 3)
 Primary Evaluation Criteria
 Stakeholder concurrence on scope definition and
cost/schedule estimates?
 Do critical use cases demonstrate that the
requirements are understood?
 Do we have credible estimates for
cost/schedule/resources/risks/development?
 Does the architectural prototype support previous
items? (Does the prototype indicate that the scope of
project is understood, and does the development
group indicate prevalent understanding?)
 Are actual expenditures verses planned expenditures
acceptable? <<end inception>>
 LCO Milestone…
26
 Elaboration Phase (1 of 5)
 Clearly the most important phase! Overriding
goals are several, varied, and critical!
  At end of phase:
 engineering is complete,
 almost all use cases are designed (certainly all critical use cases and
flows),
 a prototype for gathering requirements and to demonstrate proof of
concept is accommodated, and
 an analysis model is constructed, and
 a baseline executable architecture is established and demonstrated.
 Risks have to have been addressed and strategies understood;
 Business Rules have been subscribed to closely;
 Cost and schedule are acceptable and predictable and updated, if
necessary,
 Stakeholder acceptance is achieved (the vision is realized in the
artifacts), etc. and
 We have stability…
  We want to graduate from a low-cost effort into a full-blown 27
production process, where costs are maxed and personnel are on staff.
 Elaboration Phase (2 of 5)
  Primary Objectives (at end of phase…)
 Base-lining the architecture asap (establishing
configuration management procedures…for
tracking all artifacts!
 Base-lining the Vision. It is now ‘solid’ and
accommodated in the artifacts so far.
 Base-lining a detailed plan for Construction
 Demonstrating the baseline architecture such
that it clearly supports the vision – at, of course,
reasonable cost in reasonably time.
28
 Elaboration Phase (3 of 5)
 Essential Activities
 Detail the Vision.
 Ensure all have this shared functional vision and that this is
reflected in the Use Cases that will drive the architecture and
planning….
  Discuss: What does this mean to you??? Explain!
 Detail the process (to come) and the infrastructure
support.
 Must be spelled out; the plans for each iteration in
Construction (project management supporting discipline) and
the anticipated assessment at the end of each iteration, the
functionality accommodated by each iteration must be
spelled out in general.
 Detailed iteration planning (after first iteration or two) will
come later. But overview planning is now!
  Discuss: What does this mean? Explain!
29
 Elaboration Phase (4 of 5)
 Essential Activities – continued
 Build the Architecture…
 Group classes into packages; subsystems; consider
existing executable components that may be reusable – e.g.
GUI Components (commonly available); can you reverse
engineer existing components? (Should you seek to buy
components? Contract for them? Develop them?)
 But you MUST integrate these into architectural units (layers,
packages, subsystems, all with dependencies, well-defined
interfaces, …)
 Bounce your candidate architecture against your primary
scenarios to trace that all functionality is accommodated by
these artifacts.
 May result in a number of design choices and changes in model
elements (e.g. classes, responsibilities…)
 May point out some requirements missing…
  Remember, requirements are singular; but there is not a
single, perfect design.
30
 Elaboration Phase (5 of 5)
 Primary Evaluation Criteria
 Remember, at the end of Elaboration Phase we have
the LCA – Life Cycle Architecture Milestone. So, …
 Is the Vision solid? Stable?
 Is the architecture stable? Demonstratable?
 Execute example of addressing a high risk scenario?
 Does the architecture indicated that all risk elements have
been addressed/mitigated?
 Have we looked carefully into Construction and established
sufficient planning detail to project credibility in our estimates?
(initial iteration – one or two – carefully planned?)
 Do we have stakeholder buy-in that their vision can be
accommodated if we proceed as plans indicate?
 Are actual resource expenditures verses planned resource
expenditures acceptable so far?
 Achieve this Milestone! Press on – with concurrence.31
 Construction Phase (1 of 5)
 Great mindset change: now interested in
producing a deployable product! (implementation)
 iterate, iterate…, integrate/assess/plan as we go.
 No longer ‘engineering;’ rather, production!!!

 Need to manage resources, control operations to

optimize costs, schedules, and quality.
 Emphasis on the development of intellectual
property shifts to the reality of usable products.
32
 Construction Phase (2 of 5)
 One very nice attribute in Construction:
 Parallel development
 Based on architecture…do homework up front!!!!
 Accelerates delivery of deployable releases
 Downside: complicates project management and
synchronization of teams, integration, and workflow.
 Architecture will drive this
 A good architecture will support parallel development
 Emphasized during Elaboration – planning for
Construction.

33
 Construction Phase (3 of 5)
 Primary Objectives
  Develop the system rapidly but with high
quality – that is, construction (programming
and unit testing) ‘implements’ the design;
‘realize’ the design…
 Take advantage of the process, versioning,
reviews, assessment, etc. to minimize costs
due to needless rework and scrap.
 Develop alpha, beta, ‘or what have you’
releases for Transition phase.

34
 Construction Phase (4 of 5)
 Essential Activities
 Manage resources; control development (via
plans, configuration management, change
management, …);
 Perform unit testing (component testing)
against requirements (verification)
 Assess releases against acceptance criteria
cited in vision. (validation)
 V&V …Discuss….
35
 Construction Phase (5 of 5)
 Primary Evaluation Criteria (at end)
 Milestone is ‘Initial Operational Capability’ (IOC)
 Is the product reliable enough for deployment?
 Does not mean everything must be perfect…Showstoppers?
 Does it fail frequently??
 Is product ‘stable’ enough for deployment?
 Pending changes are okay
 But are we getting change requests a-plenty?
 Are defects being identified rapidly ‘as we speak?’
 How significant are the changes??
 Is the stakeholder community ready to transition?
 Are actual expenditures reasonably close to planned
expenditures?
36
 Transition Phase
 Recall end of phase milestone: product release to
user domain.
 Implies product is stable, has high quality, has
accompanying user documentation (on-site or web-based
training…), customer support is ‘ready’, etc...
 Phase ‘could’ include any of these…
 Beta testing to validate new system against expectations
 Beta testing in parallel with legacy system to be replaced
 Installation
 Conversion of operational data bases
 Training users, maintenance team, customer support…

37
 Transition Phase
 Phase concludes when the baseline realizes the
original vision and we are ready to put it in the
users’ hands.
 Might be end of project development or starting
point for next cycle, or starting point for next
version of deployable version...
 Might be forwarding ‘whole shooting match’ over
to
 the maintenance group or
 third party for future work…

38
 Transition Phase
 Transition is not uncomplicated
 May involve several iterations including
 Beta1, beta2, … testing and ‘levels’ of releases (all
releases may not be equal…)
 Custom software?
 Conversion software?
 Development of user documentation,
 User training, especially in initial use of product
 Web-X; on developer’s site; on client’s site.
 Who pays for what? How does this work? Millions!!!
 Usability problems and tuning,
 (Un)solicited feedback, and more….

39
 Transition Phase
 Essential Activities
 “Synchronization and integration of concurrent
construction increments into consistent deployable
baselines” – ensure all flows…
 Installation / Conversion
 Cut over (complete switch to new application)
 Run in parallel, or
 Phased…
 Assessment against vision and acceptance criteria.
 Evaluation Criteria
 Is user satisfied?
 Are actual expenditures reasonably close to planned
expenditures?
40
 Summary - Know These
 Recognize each phase has one or more
iterations
 Phases end with major milestones; (Know
these!)
 Iterations within phases have minor milestones.
 Each have deliverable(s) and undergoes assessment
against criteria
 Each iteration entails a sequence of activities that
culminate in a minor milestones or major milestones
(if iteration ends phase)
 Scope and results of iterations are captured via
artifacts produced. 41
 Summary (continued) – Know!
 Major Milestones (phase end):
 Approved by stakeholders
 Map to significant management/business decisions rather than
to completion of a specific software development activity.
 Minor milestones (iteration end):
 Approved internally and
 Realized by artifacts / new versions of artifacts in repository;
 internal synchronization,
 internal assessment,
 Additional planning take place…
 ‘Executable’ releases (not necessary deployable…)

42
 Lessons Learned – Organizational Change
 Middle management is where the war is won
 Championed by respected leaders who own the plan and
execution.
 Project Management: Can be immense pressures from
above (Sr. Management) and different sets of
problems/issues from below (actual developers)
 ROI on first implementation
 Disruption costs must be absorbable in the benefit
 Implemented on business critical project
 This is where the A-players are
 Success breeds success – (like the NFL)
 First increment needs to be ambitious, but realistic
 Results drive incentives
 Such as: milestone demonstrations, release timeliness,
release content, etc
 Not: processes, methods, expended energy, reuse, audits,
43
meetings, subjective assessments, document production,…