1. Iterative Development & SDLC
AN OVERVIEW
By Ahmad K. Shuja

2. IDLC, MAp, Waterfall & Iterative – Relationships Overview
IDLC / iSDLC
SDLC
MAp
Weak in
Mapping Business
Goals with IT
System Analysis &
Architecture
Development
Software Solution
delivered
Business Goals Analysis
Programs / Projects required to meet business goals identified
Waterfall SDLC
Solution Architecture completed
Waterfall
Business
Goal
(An Idea or
Problem)
Software
Solution
(Tangible
Solution)

3. Goals Model Overview
Each program refines goals from its parent program
ID&EM End-to-end Goals
ER Goals
PD Goals
CAAS Goals
ISTFI Goals
Xxx xxx xx x xx xxx x x
Xxx xxx xx x xx xxx x x
Xxx xxx xx x xx xxx x x
Xxx xxx xx x xx xxx x x
Xxx xxx xx x xx xxx x x
Xxx xxx xx x xx xxx x x
Xxx xxx xx x xx xxx x x
Legend
Goal
Goal refinement within a program
Goal refinement between programs
Xxx xxx xx x xx xxx x x
Xxx xxx xx x xx xxx x x
Xxx xxx xx x xx xxx x x
Xxx xxx xx x xx xxx x x

4. How the Blackbox and Whitebox relate
Other
System
ID&EM
Blackbox
Ports on blackbox become ports on whitebox
Note: This is a notional cartoon diagram
Port_C
Port_A
Port_C
Port_B
ID&EM Whitebox Assembly
Prov. /
De-Prov.
Port_D
Port_E
Port_A
Port_C
Port_B
Entitlement
Review
Port_G
CAAS
Port_F
Port_H
Port_J

5. Program Management
Q: How do we plan and manage large programs (multi-year) in IDLC, when they are targeted to retire existing systems?
Enterprise Level Goal
Associated Program to Meet that Goal
Current State
Business Modeling of the Current State
What is the problem that is preventing the enterprise to meet the goal stated above?
Migration Plan
What sub-goals, if realized, will enable the organization to transition from the current state to the desired state?
What programs, sub-programs, and projects need to be undertaken to realize these sub-goals?
Target State
Business Modeling of the desired or target state.
What state do we want to achieve where we enable the enterprise to realize the above stated goal?
Projects such as SOA Infrastructure
Sub-Program
Core Identity
SW Intensive Project
(IDLC)
Non-SW Project
Other Sub-Programs
Project
Iterative Development Lifecycle

6. Software-Intensive Project
Software Management
Software-Intensive Project
Project Goals
Captured in “Project Charter” & “Software Development & Project Management Plan”
Current State
What is the current state of the software system (if one exists), upstream and downstream systems that this system needs to integrate with, and the environment where this system will operate?
Migration Plan
What activities are required to be done to achieve this goal?
What resources are required to carry out those activities?
Target State
What target system and environment are required to ensure that project goals are accomplished?

7. IDLC, MAp, Waterfall & Iterative – Revisiting
IDLC / iSDLC
SDLC
MAp
System Analysis &
Architecture
Development
Software Solution
delivered
Business Goals Analysis
Programs / Projects required to meet business goals identified
Waterfall SDLC
Solution Architecture completed
Waterfall
Business
Goal
(An Idea or
Problem)
Software
Solution
(Tangible
Solution)

8. Development of IDLC Iterative Development Lifecycle Experience
Project Management Best Practices
“PMI PMBOK”
Iterative Development Framework
“Rational Unified Process”
Architecture Development Framework
“MAp”
Iterative Development Lifecycle
Software Development & Management Framework
Experience

9. PRJ270: Essentials of Rational Unified Process
One Iteration
Represents Single Iteration
2 to 8 weeks period
Business Modeling
Black Box Architecture
Planning
White Box Architecture
Evaluation
Project
Management
Implementation
The earliest iterations address greatest risks. Each iteration produces an executable release. Each iteration includes integration and test, both of which increase from a very low level in the first iteration of Elaboration to a very high level at the end of Transition.
Iterations help:
resolve major risks before making large investments and prove that the organization can afford to continue for both technical and business reasons
enable early user feedback.
make testing and integration continuous.
focus short-term project objective milestones.
make possible deployment of partial implementations.
Iterative processes were developed in response to waterfall characteristics. Instead of developing the whole system in lock step, an increment (i.e. a subset of system functionality) is selected and developed, then another increment, and so on. The selection of the first increment to be developed is based on risk, the highest priority risks first and the business needs. To address the selected risk(s), choose a subset of use cases. Develop the minimal set of use cases that will allow objective verification (that is, through a set of executable tests) of the risks that you have chosen. Then select the next increment to address the next highest risk, and so on. Thus the system evolves and grows through the iterations.
Deployment
Test
Each iteration results in an executable “Iteration Build”
Module 2 Iterative Development

10. Each Iteration Converges On Project Goal
Business Modeling
Business Modeling
Business Modeling
Business Modeling
Black Box Architecture
Black Box Architecture
Planning
Black Box Architecture
Black Box Architecture
Planning
Planning
Planning
Evaluation
Evaluation
Project
Management
Evaluation
Project
Management
Evaluation
White Box Architecture
Project
Management
White Box Architecture
Project
Management
White Box Architecture
White Box Architecture
Implementation
Implementation
Implementation
Implementation
Deployment
Deployment
Deployment
Deployment
Test
Test
Test
Test
REL 1.0
IB 1.1
IB 1.2
IB 1.3

11. Changing Focus of IDLC Iterations Over Time
PRJ270: Essentials of Rational Unified Process
Changing Focus of IDLC Iterations Over Time
Iteration 1
Iteration 2
Iteration 3
Business
Arch
Black
Box
Arch
White
Box
Arch
The focus of an iteration and its emphasis on various activities change across the cycle.
Imp
Deploy
Time
Module 2 Iterative Development

12. Iterative Development & IDLC
Definition
Elaboration
Creation
Validation I1 I WB BB BA T D I2 I WB BB BA T D I3 I WB BB BA T D I4 I WB BB BA T D I5 I WB BB BA T D I6 I WB BB BA T D
Frame the problem &
Agree on the scope
Product sufficiently mature
for use
I T E R A T I O N S
Time
PoC R1
Understand the solution &
Baseline Project Plan

13. IDLC – From WBS To Iteration Plan1 2 3 3 3 3 4 1 3 3 3. 4 4 3 3 3 3 4 4
Signoff 3 4 3 4 4 3
Signoff R1
Signoff
Signoff
Signoff 4 I1 I WB BB BA T D I2 I WB BB BA T D I3 I WB BB BA T D I4 I WB BB BA T D 2
Initiation 4
Signoff

14. PRJ270: Essentials of Rational Unified Process
What Is an Iteration?
In an iteration, you walk through all disciplines
Iteration: A distinct sequence of activities with a baselined plan and evaluation criteria resulting in a release (internal and external)
An iteration is one pass through all disciplines. The deliverables of a discipline vary, depending on its position within the overall lifecycle, and the nature of the project.
An iteration can be seen as a mini project with a plan, deliverables and assessment, in which periodic assessments and corrections are applied to the remainder of the project.
If you are using the six phases of IDLC, you are already using an iterative process, but more iterations can be added to each phase if needed.
If you are using the four phases of RUP, you are already using an iterative process, but more iterations can be added to each phase if needed.
An iteration consists of some some activities from each major “area of concern”. This graphic is taken from Rational Unified Process® or RUP®. RUP is organized into disciplines, where each discipline is a collection of related activities that belong to some major 'area of concern'.
Module 2 Iterative Development

15. Definition Phase: Objectives
PRJ270: Essentials of Rational Unified Process
Definition Phase: Objectives
Establish the project’s software scope and boundary conditions, including an operational concept, acceptance criteria, and descriptions of what is and is not intended to be in the product.
Discriminate the critical use cases of the system, that is, the primary scenarios of behavior that will drive the system’s functionality and will shape the major design trade-offs.
Exhibit, and perhaps demonstrate, at least one candidate architecture against some of the primary scenarios.
Estimate the overall cost and schedule for the entire project and provide detailed estimates for the elaboration phase that will immediately follow.
Customize the process to meet project-specific needs.
Estimate risks (the sources of unpredictability).
We only describe the phases at a very high level. RUP defines exit criteria, activities, and artifacts for each of these.
We don’t have time to go into them in that much detail.
Note: In addition to an estimate for the Elaboration phase, an overall estimate of cost and schedule to complete the project is usually made at this time. However, this estimate must be recognized as being very rough (low confidence) and subject to revision at the end of Elaboration.
Module 2 Iterative Development

16. Definition Phase: Evaluation Criteria
PRJ270: Essentials of Rational Unified Process
Definition Phase: Evaluation Criteria
Stakeholder concurrence on scope definition and cost / schedule estimates
Agreement that the right set of requirements has been captured and that there is a shared understanding of these requirements. Such requirements understanding is achieved by the identification of the primary use cases
Agreement that the cost / schedule estimates, priorities, risks, and development process are appropriate
Development Case produced (What artifacts need to be produced and at what level of details in order to ensure success?).
For more information, see RUP Lifecycle->Inception in RUP.
Milestone accomplished: Lifecycle Objectives Milestone (LOM)
Module 2 Iterative Development

17. IDLC Rel 1.0 – Definition Phase WBS ElementsBB BA T D I2 I WB BB BA T D I3 I WB BB BA T D I4 I WB BB BA T D

18. Definition Phase – Process Model

19. From Activity to Steps to Iteration Plan Template
Business Architecture Template

20. Definition Phase – Iteration Plan Template

21. Iteration Plan Example
PRJ270: Essentials of Rational Unified Process
Iteration Plan Example
Outline of an Iteration Plan
Shows goals of an iteration, artifacts produced and evaluation criteria.
Definition Phase
Iteration Schedule section for Business Modeling
Iteration Plans usually show detailed planning of who will perform what task/activity according to what milestones or evaluation criteria. See Team view, Artifacts -> Project Management Artifact Set -> Iteration Plan for more information and examples.
Definition Phase
Module 2 Iterative Development

22. Review – Underlying IDLC Principles
Attack major risks early and continuously … or they will attack you
Ensure alignment of product development with real business problems / goals
Ensure that you deliver value to your customer through optimal visibility
Stay focused on executable software
Accommodate change early in the project
Baseline an executable architecture early on
Make quality a way of life, not an afterthought
Ensure well-defined customer involvement

23. Evolution of SDLC Initial Steps
Q: What is the learning curve for a technology team to learn iterative development and apply this effectively on a project?
Evolution of SDLC
Initial Steps
Evolve existing SDLC into iterative methodology - iSDLC
Set up the environment with right tools
First Phase – Use iSDLC methodology on a pilot project
Second Phase – To maximize benefits and ensure greater success, refine & evolve iSDLC to incorporate other industry best practices such as MDA / MAp, Goals Modeling, PMI PMBOK and others.
Third Phase – Build iSDLC Knowledge Center and integrate it with end-to-end portfolio management (from Problem Identification to Solution Rollout) for enhanced productivity.

24. Adding Iterations to Waterfall SDLC
Q: How can we incorporate some of the benefits of IDLC in our plans without jeopardizing the key milestone(s) dates?
iSDLC Evolution I
SDLC
DEFINITION
BRD, FRD, & L1
DESIGN
TDD & L3
CONSTRUCTION
Dev Acc Plan, Rel Plan
VALIDATION
UAT
Each Iteration must have:
Well Defined Goals
Sound Evaluation Criteria I1 I2 I3 I4 I5 I6 I7 I8

25. SDLC Phases vs. IDLC Iterations
Q: If a project already has 7 phases & an evolvable prototype is being developed as part of Phase I, how is different from IDLC Iterations?
SDLC Phases vs. IDLC Iterations I6 I5 I4 I3 I2 I1
SDLC
REQUIREMENTS
BRD & FRD
ANALYSIS & DESIGN
TDD
CONSTRUCTION
Development Test & Release Plans
VALIDATION
User Acceptance Approval & UAT
IMPLEMENTATION
Release to Production I7 I8 I9

26. Q: In iterative development, we would only develop a few components at a time. Having handful of components at a time, won’t let me retire the system until all components are available – in that case, the iterative development yields no benefits compared to SDLC.
DEFINITION
BRD, FRD, & L1
DESIGN
TDD & L3
CONSTRUCTION
Dev Acc Plan, Rel Plan
VALIDATION
UAT
IMPLEMENTATION
Production Handover R1
DEFINITION
BRD, FRD, & L1
DESIGN
TDD & L3
CONSTRUCTION
Dev Acc Plan, Rel Plan
VALIDATION
UAT
IMPLEMENTATION
Production Handover R1
Key benefits of Iterative Approach:
Optimal visibility to customer
Higher quality product?
Effective management of evolving requirements evolve

27. Goals Driven Development
Q: How do we ensure that the team does not indulge into doing throw away work when doing iterative development? How do we measure our productivity in IDLC compared to SLDC?
Goals Driven Development
Definition
Elaboration
Creation
Validation I1 I WB BB BA T D I2 I WB BB BA T D I3 I WB BB BA T D I4 I WB BB BA T D I5 I WB BB BA T D I6 I WB BB BA T D
Frame the problem &
Agree on the scope
Product sufficiently mature
for use
I T E R A T I O N S
Time
PoC R1
Understand the solution &
Baseline Project Plan

28. CTS Release I – A Roadmap View
Q: How do we ensure that the team does not indulge into doing throw away work when doing iterative development? How do we measure our productivity in IDLC compared to SLDC?
CTS Release I – A Roadmap View
04/29
06/30
09/06
09/30
06/02
08/03
DEFINITION
ELABORATION
CREATION
VALIDATION
Project Charter
Understand the problem
Establish CTS Project Goals
Project Charter
April 29
User-Interface Prototypes completed
Draft Reqs Architecture Specs ready
Draft Design Specs ready
User-Interface Prototype
User-Interface Prototype
CTS IB 1.1
Refine the User-Interface based on customer feedback.
Implement the following Use Cases in parallel:
“Track Company Info”
“Track Company Revenue Objects” &
“Manage Company Docs”
June 2
Test & Deploy CTS IB 1.1
User-Interface refined
Reqs Arch Specs signed-off
Draft Design Specs ready
CTS IB 1.1
Based on customer feedback, refine use cases implemented in earlier builds.
Implement the following Use Cases in parallel:
“Track Company Contacts”,
“Record Company Opinions & Experiences” &
“Provide Search Capability”
CTS Prototype
CTS IB 1.2
June 30
Test & Deploy CTS IB 1.2
Analyze Applicable Standards & Policies
Investigate Training Needs
CTS Prototype (PoC) ready
CTS Prototype
CTS IB 1.2
CTS IB 1.3
Based on customer feedback, refine use cases implemented in earlier builds.
Implement the following Use Cases in parallel:
“Use Case VII”,
“Use Case VIII” &
“Use Case IX”
August 3
Test & Deploy CTS IB 1.3
Address applicable standards & policies
Address training needs
Based on customer feedback, refine use cases implemented in earlier builds.
Implement the following Use Cases in parallel:
“Use Case X” &
“Use Case XI”
September 6
Test & Deploy
CTS Build 1.4
CTS IB 1.3
CTS IB 1.4
CTS
Rel 1.0

29. Successive Refinement
PRJ270: Essentials of Rational Unified Process
Successive Refinement
Each consecutive iteration should be marked by:
Growth of capability, as measured by the implementation of additional functionality during each iteration
Greater depth, as measured by a more complete implementation of the product
Greater stability, as measured by a reduction in the number of changes to the product
Module 2 Iterative Development

30. Typical Effort and Time Percentages by Phase
Q: How does one go about staffing using the Iterative Model? How does it differ from the SDLC waterfall model?
Time
People
Cre
Ela
Val
Def
Definition
Elaboration
Creation
Validation
Effort 5%
20%
65%
10%
Time/Schedule
30%
50%

31. Error in Cost to Complete Estimate
Cost Estimate Refinements 4X
Definition
Elaboration
Creation
Validation
Over-estimated
Error in Cost to Complete Estimate
Under-estimated
X/4

32. Iteration Length and Number of Iterations
PRJ270: Essentials of Rational Unified Process
Iteration Length and Number of Iterations
Q: How many iterations are standard for a project?
Length varies according to the objective.
Iteration length may vary by phase.
Typically, Elaboration iterations are longer than Construction iterations.
Within a phase, iterations are generally the same length.
Total # of iterations
[I,D,E,C,V,P]
Low 3
[0,0,1,1,1,0]
Typical 7
[0,1,2,2,1,1]
High 11
[0,1,3,3,2,2]
Very High 13
[0,2,3,3,2,3]
For most projects, the iteration length should be between 1 and 2 months.
Iterations of more than 6 months probably need to have intermediate milestones built in to keep the project on track. Consider reducing the scope of the iteration to reduce its length and ensure a clear focus.
Iterations of less than 1 month need to be scoped carefully. Typically, short iterations are more suitable for the Construction phase, where the degree of new functionality to be included and the degree of novelty are low. Short iterations may require little or no formal analysis or design, and may simply be incrementally improving well-understood functionality.
Module 2 Iterative Development

33. Conditions that Increase the Number of Iterations
PRJ270: Essentials of Rational Unified Process
Conditions that Increase the Number of Iterations
Initiation
There are no iterations during the “Initiation” phase. This phase concludes with the creation of “Project Charter” which forms the foundation of a project.
Definition
Working with new functionality
Unknown business environment
Highly volatile scope
Make-buy decisions
Elaboration
Working with new system environment (new architectural features)
Untested architectural elements
Need for system prototypes
Creation
Lots of code to write and verify
New technology or development tools
Validation
Need for alphas and betas
Conversions of customer base
Incremental delivery to customers
Production
Number of enhancements required
Module 2 Iterative Development

34. Managing Iterative Dev Projects
Q: What does IDLC do to the Project Management Disciplines? Is it the same as before or should PMs think in a different and new way?
Managing Iterative Dev Projects
You apply PM principles to each iteration in iterative development vs. once to the entire project in SDLC (PMBOK 2003 recommendation).
Accept evolving nature of requirements and manage them appropriately compared to signoff requirements document in SLDC.
Prepare to do multi-tasking as follows:
Monitor and Manage current iteration
Based on iteration performance and risk evaluation, plan for the next iteration keeping not only phase goals but overall project goals in mind
Adjust plans to ensure that key milestones are achieved as required.

35. Other Questions from GTPL Team
If Iteration 1 can be completed anywhere between 2 to 8 weeks, when to get a development hardware purchase from CTI (which takes from 8 to 12 weeks)?
What is the ideal size (in function points) for running one iteration (2-8 weeks)? What is an ideal team size for an iteration?
For a large program like GTPL, a lot of time is spent upfront in defining requirements. Is the same done in IDLC under the MAp model prior to initiating Iteration 1? Are we really gaining time? Or is it being spent anyway under MAp?
How can we engage the CIBTech SDLC’s (Mariam Barack) team to get their buy-in to include this approach in PlanView and SDLCW?
How do we handle the Change Management Process in iterative model?
What testing tools / practices need to be in place for iterative development?

36. Questions? For questions and inquiries, please contact: Ahmad K. Shuja
Cell:

37. Appendix – Addition Information

38. Initiation Phase: Objectives
To state the business problem to be solved
To establish a well-researched project goal and have it approved by the Senior Management / Sponsor to dedicate organizational resources to it for further exploration
To prioritize and rationalize the project
To determine estimates of resources requirements
Optionally, to create Level 0 Estimates (-25% to +75%)

39. Initiation Phase: Evaluation Criteria
Project goal is well-established and overview of the project’s product (which will help the team realize the project goal) has been understood
Common understanding of the high-level project goal between the project team members has been achieved
Project has been rationalized and prioritized.
Project Charter has been completed, reviewed, and approved or rejected.
Milestone accomplished: Goals & Prioritization Milestone (GPM)

40. Initiation Phase – Process Model
Project Charter Template

41. Elaboration Phase: Objectives
PRJ270: Essentials of Rational Unified Process
Elaboration Phase: Objectives
Define, validate, and baseline the architecture as rapidly as practical.
Demonstrate that the baseline architecture will support the goal for a reasonable cost in a reasonable time.
Establish concurrence among senior management and / or sponsor on the accuracy of cost / schedule estimates
The cost and schedule to complete are re-estimated at the end of this phase. At this point they are considered stable (high confidence), and firm commitments can be made.
Module 2 Iterative Development

42. Elaboration Phase: Evaluation Criteria
PRJ270: Essentials of Rational Unified Process
Elaboration Phase: Evaluation Criteria
Software Development & Project Management Plan (SDPM) is baselined – Stable Product Scope, Level 3 Cost / Schedule Estimates (-5% to +10%), and baselined Project Plan
Iteration plans for Construction Phase are of sufficient detail and fidelity to allow work to proceed, and are supported by credible estimates.
PoC concluded – Stable Architecture, key test and evaluation approaches are proven, and major risk elements have been addressed and resolved
All stakeholders agree that the current goal can be achieved if the current plan is executed to develop the complete system, in the context of the current architecture
For more information, see RUP Lifecycle ->Elaboration in RUP.
Milestone accomplished: Lifecycle Architecture (LCA)
Module 2 Iterative Development

43. IDLC Rel 1.0 – Elaboration Phase WBS Elements2 2 2 2 2 2 2 2 2 2 2 2 I1 I WB BB BA T D I2 I WB BB BA T D I3 I WB BB BA T D I4 I WB BB BA T D 2 2

44. Elaboration Phase – Process Model

45. Elaboration Phase – Iteration Plan Template

46. Creation Phase: Objectives
PRJ270: Essentials of Rational Unified Process
Creation Phase: Objectives
Complete the software product for transition to production
Minimize development costs by optimizing resources and avoiding unnecessary scrap and rework.
Achieve adequate quality as rapidly as is practical.
Achieve useful versions (alpha, beta, or other appropriate test releases) as rapidly as practical.
Module 2 Iterative Development

47. Creation Phase: Evaluation Criteria
PRJ270: Essentials of Rational Unified Process
Creation Phase: Evaluation Criteria
Product release stable and mature enough to be deployed in the user community
All stakeholders are ready for the transition into the user community.
For more information, see RUP Lifecycle ->Construction in RUP.
Milestone accomplished: Initial Operational Capability (IOC)
Module 2 Iterative Development

48. IDLC Rel 1.0 – Creation Phase WBS Elements3 3 3 3 3 3. 3 3 3 3 3 3 3 3 I1 I WB BB BA T D I2 I WB BB BA T D I3 I WB BB BA T D I4 I WB BB BA T D

49. Creation Phase – Process Model

50. Creation Phase – Iteration Plan Template

51. Validation Phase: Objectives
PRJ270: Essentials of Rational Unified Process
Validation Phase: Objectives
Achieve user self-supportability through training and knowledge sharing.
To transition any resources (human, documentation, or systems) required to successfully support the production system to the product owner
Achieve stakeholder concurrence that deployment baselines are complete and consistent with the evaluation criteria of the goal.
Achieve final product baseline as rapidly and cost- effectively as practical.
During the Transition phase, a decision is made whether to release the product.
The purpose of the transition phase is to move the software product to the pre-production environment which will serve as an incubator prior to the release of the product to the end user community. After the product has been transitioned to production, issues usually arise that require you to evolve the product and develop new releases, correct some problems, or the finish features that were postponed.
It should be noted that the Transition phase in the RUP approach differs radically from traditional development, primarily because you enter the phase with a reasonably stable, integrated, and tested version of the system. Conversely, in the traditional waterfall approach, the final integration phase often starts with major breakage – sometimes you cannot even compile the whole system, interfaces between subsystems are not compatible, or the system crashes frequently, resulting in major rework for your team and several weeks’ delay before the system is up and running and ready to test. The introduced delays result in a large portion of management time being spent on resetting and renegotiating expectations from key stakeholders.
Module 2 Iterative Development

52. Validation Phase: Evaluation Criteria
PRJ270: Essentials of Rational Unified Process
Validation Phase: Evaluation Criteria
User and / or Customer is satisfied with the product and is able to operate and support it
Product solves the problem stated in the charter and meets project goals
At the end of the Transition Phase is the fifth important project milestone: the Initiation Product Release Milestone (IPRM). At this point, you decide whether the objectives were met and whether you should start another development cycle or follow-up evolution cycle. In some cases, this milestone may coincide with the end of the inception phase for the next cycle.
The decision about whether to release the product will be based primarily on the level of user satisfaction achieved during the Transition phase. Often this milestone coincides with the initiation of another development cycle to improve or enhance the product. In many cases, this new development cycle may already be underway.
For more information, see RUP Lifecycle ->Transition in RUP.
Milestone accomplished: Initial Product Release (IPR)
Module 2 Iterative Development

53. IDLC Rel 1.0 – Validation Phase WBS Elements4 4 4 4 4 4 4 4 4 I1 I WB BB BA T D I2 I WB BB BA T D I3 I WB BB BA T D I4 I WB BB BA T D 4

54. Validation Phase – Process Model

55. Validation Phase – Iteration Plan Template

56. Production Phase: Objectives
PRJ270: Essentials of Rational Unified Process
Production Phase: Objectives
To gain formal acceptance of the product by the stakeholders (customer, business or technology owner).
To formally dis-engage EAD resources from the project completely
To ensure that any (if at all) gaps identified in the product during the transition or production phase have been satisfactorily met.
The goal of the Production Phase is to keep systems useful and productive after they have been deployed to the user community. This process will differ from system to system and project to project, but the fundamental goal remains the same – keep the system running, help owners support (operate and monitor) it, and assist users use it.
Module 2 Iterative Development

57. Production Phase: Evaluation Criteria
The product is completely handed over to the owner
Product owner is satisfied with the product and its transition
Product owner is now able to operate and support the product without EAD’s assistance
EAD team is no longer engaged.
Milestone accomplished: Final Product Release (FPR)