Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Life-Cycle Phases
1
Introduction
2
Further, we need a process that supports this
balance.
4
Engineering and Production Stages
5
Two Stages: Far Too Abstract
a life cycle of two stages is far too abstract to track the many detailed activities all with
actors, activities, and artifacts.
Map RUP Phases into these more comprehensive phases.
Enter: Engineering Phase = Inception and Elaboration
Enter: Production Phase = Construction and Transition
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)
6
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);
7
Spiral Model - Overview
Spiral Model is another incremental model.
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..
8
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.
9
Previous Software Process Models
An evolution of models
Code & Fix
Stagewise & Waterfall
Evolutionary Development
Others
10
Stagewise & Waterfall
Born out of the shortsightedness of the Code & Fix
model.
- need for a design phase, requirements phase,
and a testing phase.
11
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.
12
Waterfall Model
Introduced:
Feedback loops across multiple stages: Validation and
verification steps.
Prototyping via a build it twice step alongside of
requirements and design.
13
14
Evolutionary Development
Evolution of the system in directions based on
experience.
Provides rapid initial operational capability.
I cant tell you what I want, but Ill know it when I see it.
Flexible, yet uncertain approach.
19
Spiral Model - more
May be several cycles of prototypingbut 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.
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
20
Spiral Model and the RUP Phases
R & D Stage Production Stage
26
Elaboration Phase (2 of 5)
Primary Objectives (at end of phase)
Base-lining the architecture asap (establishing
configuration management proceduresfor 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.
27
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!
28
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.
29
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? 30
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!!!
31
Construction Phase (2 of 5)
One very nice attribute in Construction:
Parallel development
Based on architecturedo 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.
32
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.
33
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.
34
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 perfectShowstoppers?
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?
35
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
36
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
37
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 developers site; on clients site.
Who pays for what? How does this work? Millions!!!
Usability problems and tuning,
38
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?
39
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.
40
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)
41
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,
meetings, subjective assessments, document production,
42