1. PRJ270: Essentials of Rational Unified Process
IBM Software Group
PRJ270: Essentials of Rational Unified Process
Module 2: Iterative Development
Module 2 Iterative Development

2. PRJ270: Essentials of Rational Unified Process
Module 2 Objectives
Be familiar with the guidance RUP provides for iterative development by investigating:
Phases and milestones
Iterations
Concepts that drive iterative development
Early mitigation of risk
Early baselining of architecture
Use of objective measurements
Characteristics of iterative development
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.
Module 2 Iterative Development

3. Instructor Demonstration of RUP
PRJ270: Essentials of Rational Unified Process
Instructor Demonstration of RUP
Your instructor will briefly demonstrate RUP, showing you:
Elements of the main interface
Where to access the Classic RUP Getting Started view and Team view
This is another opportunity to demo RUP. You can have students follow on their own computers if you wish.
Show students:
Main frame
navigation tree
tabs for different views of RUP
location of resources (Glossary, Index, Search, Print, etc)
Also show students where to access Classic RUP Team View, which is basically the full RUP.
At the end of this lesson, students will have 15 minutes to explore RUP on their own.
The Classic RUP Getting Started view contains information to help the new user of RUP. It offers explanations about the organization of the process and how to use the process.
The Classic RUP Team view is the main content of the process. It shows the “who does what when” details of the process. It is organized by time (phases) and “area of concern” (disciplines).
The other views in Classic RUP are organized by role, and contain subsets of the Team view.
Module 2 Iterative Development

4. RUP Organization Along Time
PRJ270: Essentials of Rational Unified Process
RUP Organization Along Time
Time
The time aspect of the process is enacted through phases, iterations, and milestones (end of phase objectives).
Progressing by meeting milestones helps minimize wasted resources since they are allocated only on a firm basis.
Organization by phases helps minimize the risks of resource allocation.
Module 2 Iterative Development

5. Major Milestones: Business Decision Points
PRJ270: Essentials of Rational Unified Process
Major Milestones: Business Decision Points
Customer
acceptance
or end of life
Product
Release
Phases represent the management perspective of the project, the “35,000 foot level.” The details are left to the engineering perspective, which is at the iteration level.
The names of the milestones are identical to the ones proposed by Barry Boehm in the article “Anchoring the Software Process,” IEEE Software, July 1996, pp
Product sufficiently mature for customers
Initial Operational
Capability
Milestone
Architecture
baselined
Lifecycle
Milestone
Scope and Business Case agreement
Lifecycle
Objective
Milestone
Inception
Elaboration
Construction
Transition
time
The phases of RUP were chosen such that phase boundaries correspond to significant decision points in the life of a project. For example, at the end of Inception, enough work has been done to capture the problem to be solved, and a vision of the system has been developed. An initial set of risks has also been identified and evaluated. Based on this information, a decision is made whether to fund the project. Similar decision points correspond to the end of Elaboration, Construction, and Transition.
Milestones help you to assess the progress of a project at key points. Management can use these to establish clear criteria from which to decide the course of a project. They provide opportunities to change course. However, unlike the waterfall approach, phases contain iterations which yield executable results.
Module 2 Iterative Development

6. Inception Phase: Objectives
PRJ270: Essentials of Rational Unified Process
Inception Phase: Objectives
Establish project scope and boundary conditions
Determine the use cases and primary scenarios that will drive the major design trade-offs
Demonstrate a candidate architecture against some of the primary scenarios
Estimate the overall cost and schedule
Identify potential risks (the sources of unpredictability)
Prepare the supporting environment for the project
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

7. Inception Phase: Evaluation Criteria
PRJ270: Essentials of Rational Unified Process
Inception 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
Agreement that the cost/schedule estimates, priorities, risks, and development process are appropriate
All risks have been identified and a mitigation strategy exists for each
For more information, see RUP Lifecycle->Inception in RUP.
Milestone: Lifecycle Objectives (LCO)
Module 2 Iterative Development

8. Elaboration Phase: Objectives
PRJ270: Essentials of Rational Unified Process
Elaboration Phase: Objectives
Define, validate and baseline the architecture as rapidly as is practical
Baseline the vision
Refine support environment
Baseline a detailed plan for the Construction phase
Demonstrate that the baseline architecture will support the vision at a reasonable cost in a reasonable period of time
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

9. Elaboration Phase: Evaluation Criteria
PRJ270: Essentials of Rational Unified Process
Elaboration Phase: Evaluation Criteria
Product Vision and requirements are stable.
Architecture is stable.
Key test and evaluation approaches are proven; major risk elements have been addressed and resolved.
Iteration plans for Construction phase are of sufficient detail and fidelity to allow work to proceed, and are supported by credible estimates.
All stakeholders agree that current vision can be met if the current plan is executed to develop the complete system, in the context of the current architecture.
Actual resource expenditures versus planned expenditures are acceptable.
For more information, see RUP Lifecycle ->Elaboration in RUP.
Milestone: Lifecycle Architecture (LCA)
Module 2 Iterative Development

10. Construction Phase: Objectives
PRJ270: Essentials of Rational Unified Process
Construction 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, and other test releases) as rapidly as possible
Module 2 Iterative Development

11. Construction Phase: Evaluation Criteria
PRJ270: Essentials of Rational Unified Process
Construction Phase: Evaluation Criteria
The evaluation criteria for the Construction phase involve the answers to these questions:
Is this product release stable and mature enough to be deployed in the user community?
Are all the stakeholders ready for the product’s transition into the user community?
Are actual resource expenditures versus planned still acceptable?
For more information, see RUP Lifecycle ->Construction in RUP.
Milestone: Initial Operational Capability (IOC)
Module 2 Iterative Development

12. Transition Phase: Objectives
PRJ270: Essentials of Rational Unified Process
Transition Phase: Objectives
Achieve user self-supportability
Achieve stakeholder concurrence that deployment baselines are complete and consistent with the evaluation criteria of the vision
Achieve final product baseline in a rapid and cost-effective manner
During the Transition phase, a decision is made whether to release the product.
Module 2 Iterative Development

13. Transition Phase: Evaluation Criteria
PRJ270: Essentials of Rational Unified Process
Transition Phase: Evaluation Criteria
The primary evaluation criteria for the Transition phase involve the answers to these questions:
Is the user satisfied?
Are actual resources expenditures versus planned expenditures acceptable?
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: Product release (“GA”)
Module 2 Iterative Development

14. PRJ270: Essentials of Rational Unified Process
What Is an Iteration?
Iteration: A distinct sequence of activities with a baselined plan and evaluation criteria resulting in a release (internal or external).
In an iteration, you walk through all disciplines.
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 four phases of RUP, you are already using an iterative process, but more iterations can be added to each phase if needed.
Module 2 Iterative Development

15. Changing Focus of Phases Over Time
PRJ270: Essentials of Rational Unified Process
Changing Focus of Phases Over Time
Acceptance
or end of life
Product sufficiently mature for customers to use (Have a solution)
Architecture baselined (Understand the solution)
Scope and Business Case agreement (Understand the problem)
Planned (Business) Decision Points
Iterations represent the engineering perspective of the project. This is what concerns the developers on a day-to-day basis.
Inception
Elaboration
Construction
Transition
Preliminary
Iteration
Architecture
Architecture Iteration
Development
The dotted line indicates that the first product build may not be at executable level. However, later builds will have increasing functionality, culminating in the completed product.
Planned (Technical) Visibility Points
Module 2 Iterative Development

16. Changing Focus of Iterations Over Time
PRJ270: Essentials of Rational Unified Process
Changing Focus of Iterations Over Time
Iteration 1
Iteration 2
Iteration 3
Req
Design
Impl
The focus of an iteration and its emphasis on various activities change across the cycle.
Test
Deploy
Time
Module 2 Iterative Development

17. Duration of an Iteration
PRJ270: Essentials of Rational Unified Process
Duration of an Iteration
An iteration begins with planning and requirements and ends with an internal or external release.
Ideally an iteration should run from two to six weeks, depending on your project size and complexity.
Factors that affect duration of an iteration:
Size, stability and maturity of organization
Familiarity with the iterative process
Size of project
Technical simplicity of project
Level of automation used to manage code, distribute information, perform testing
For more information, see “The Rational Unified Process: An Introduction, 2nd Ed.” by Philippe Kruchten. Addison-Wesley, 2000, p
Module 2 Iterative Development

18. PRJ270: Essentials of Rational Unified Process
Number of Iterations
Rule of thumb: Use 6 ± 3 iterations
Phase
Low
Medium
High
Inception 1
Elaboration 2 3
Construction
Transition
Total 6 9
Once you know the duration of an iteration appropriate to your organization, you can decide how many iterations to plan in each phase.
If Inception consists only of planning and marketing, then there may be no real iteration. If you need a prototype or need to immediately address a technical risk, you will need an iteration.
The number of iterations in Elaboration may depend on the complexity of the architecture, where you’re starting from, and the experience of the team.
During Construction, you can use iterations to do a good job of testing and integration. Sufficient automation can make more iterations easier to deal with. Also, a mature process could accommodate more iterations.
Transition would require at least one iteration, and more, if conditions at the time of transition make it necessary.
For more information, see “The Rational Unified Process: An Introduction, 2nd Ed.” by Philippe Kruchten. Addison-Wesley, 2000, p
Module 2 Iterative Development

19. Conditions that Increase the Number of Iterations
PRJ270: Essentials of Rational Unified Process
Conditions that Increase the Number of Iterations
Inception
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
Construction
Lots of code to write and verify
New technology or development tools
Transition
Need for alphas and betas
Conversions of customer base
Incremental delivery to customers
Module 2 Iterative Development

20. PRJ270: Essentials of Rational Unified Process
One Iteration
Artifact: Iteration Assessment
Artifact: Iteration Plan
Reduce risk
Accept change
Steer project
Start Iteration Using
Iteration Plan
Start Next Iteration
Complete Planned
Iteration Work
Adjust
Objectives
Adjust Target
Product
Adjust Remaining
Plan
Plan Next
Iteration
Project Stopped
Stop
Assess
Continue
Consider risks
Add Change Control Board- approved changes
The term “artifact” is defined for the first time in the Student Notes. It will be discussed in more detail later in the course.
Definition of Artifact: A piece of information that: 1) is produced, modified, or used by a process, 2) defines an area of responsibility, and 3) is subject to version control. An artifact can be a model, a model element, or a document. A document can enclose other documents.
Two iteration planning artifacts in RUP are the Iteration Plan and the Iteration Assessment. In combination, they facilitate decisions that allow you to reduce risk, accept change and steer the project through each iteration.
After an iteration starts, the teams complete the work specified in the Iteration Plan.
When work is complete, the Iteration Assessment is performed to determine if and how the iteration goals were achieved, using as many objective measurements as possible. Based on the assessment, a determination is made whether or not to continue the project.
If you decide to continue, you have to analyze Change Control Board(CCB)-approved project changes, revise your risk list and possibly modify the product’s objectives (requirements) or the specifications of the product itself (architecture and design). This revised specification for the project becomes the new target and allows you to steer the project, taking into consideration requirements and product changes. Based on this adjusted set of objectives, you can plan the next iteration, creating a new Iteration Plan.
Module 2 Iterative Development

21. Artifact: Iteration Plan
PRJ270: Essentials of Rational Unified Process
Artifact: Iteration Plan
A time-sequenced set of activities and tasks, with assigned resources, and containing task dependencies. A fine-grained plan, one per iteration.
The form an iteration will take varies, depending on its position within the overall lifecycle and the nature of the project. The Iteration Plan includes all relevant portions of the disciplines for that particular iteration.
Module 2 Iterative Development

22. Iteration Plan Example
PRJ270: Essentials of Rational Unified Process
Iteration Plan Example
Outline of an Iteration Plan
Shows timeframes and resources by discipline
Iteration Schedule section for Requirements discipline
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.
Module 2 Iterative Development

23. Artifact: Iteration Assessment
PRJ270: Essentials of Rational Unified Process
Artifact: Iteration Assessment
The Iteration Assessment captures the result of an iteration, the degree to which the evaluation criteria were met, lessons learned, and changes to be done.  
Artifact description can be found in RUP at Artifacts->Project Management Artifact Set->Iteration Assessment.
Module 2 Iterative Development

24. Concepts That Drive Iterative Development
PRJ270: Essentials of Rational Unified Process
Concepts That Drive Iterative Development
Some important concepts that affect iterative development are:
Early mitigation of risk
Early baselining of architecture
Use of objective metrics
Iterative development needs to have a focus. These are three main principles to guide the process.
Module 2 Iterative Development

25. PRJ270: Essentials of Rational Unified Process
Definition of Risk
An ongoing or upcoming concern that has a significant probability of adversely affecting the success of major milestones. (RUP Glossary)
Some Risk Types:
Technical/Architectural risks
Unproven technology, uncertain scope
Resource risks
People, skills, funding
Business risks
Competition, ROI, supplier interfaces
Schedule risks
Project dependencies
Only 24 hours in a day
Need to be identified and prioritized in Risk List artifact.
Module 2 Iterative Development

26. PRJ270: Essentials of Rational Unified Process
Risk Terms
Direct risk - the project has a large degree of control
Indirect risk - the project has little or no control
Risk Magnitude is used for ranking risks. It is a combination of:
Probability of occurrence
Impact on the project (severity) e.g. project delays
Risk management is an intrinsic part of planning and managing. Without knowing what our risks are, how do we know how many iterations to plan for and what the content should be?
The most important considerations in developing a project plan are the risks that the project faces. For example, if a brand new software architecture must be developed for the project, the project manager will schedule several iterations during the Elaboration phase. If reusing a proven architecture, one iteration might suffice.
Module 2 Iterative Development

27. Risk Management Strategies
PRJ270: Essentials of Rational Unified Process
Risk Management Strategies
Risk avoidance, risk transfer OR risk acceptance
Mitigate accepted risks by:
Creating a Risk List artifact
Taking some immediate, pro-active steps to reduce the probability or the impact of the risk
Defining a contingency plan
Risk Management Strategies:
Risk avoidance - reorganize the project so that it will not be affected by the risk
Risk transfer - reorganize the project so that someone else bears the risk
Risk acceptance - live with it. This means you must attempt to mitigate risk, that is, reduce the probability or impact and find a contingency plan (“Plan B”)
The Risk List is created early in Inception and updated for every iteration.
Module 2 Iterative Development

28. PRJ270: Essentials of Rational Unified Process
Risk Profiles
Risk Reduction
Waterfall Risk
Risk
Iterative development produces the architecture first, allowing integration to occur “as a verification activity” and allowing design flaws to be detected and resolved earlier in the lifecycle.
Continuous integration throughout the project replaces the “big bang” integration at the end of a project.
Iterative development also provides much better insight into quality, because system characteristics that are largely inherent in the architecture (for example, performance, fault tolerance, maintainability) are tangible earlier in the process. Thus, issues are still correctable without jeopardizing target costs and schedules.
Iterative Risk
Time
Module 2 Iterative Development

29. Risk Reduction Drives the Iterative Lifecycle
PRJ270: Essentials of Rational Unified Process
Risk Reduction Drives the Iterative Lifecycle
Early iterations should address the risks of highest magnitude.
Risk assessment is a continuous process; risks change over time.
An updated Risk List is input to the activity Develop Iteration Plan.
Module 2 Iterative Development

30. More RUP Resources for Managing Risk
PRJ270: Essentials of Rational Unified Process
More RUP Resources for Managing Risk
Risk List artifact at Artifacts->Project Management Artifact Set->Risk List
Risk List Guideline and Risk Concept under Artifacts->Project Management Artifact Set->Risk List
Risk Management Plan artifact at Artifacts->Project Management Artifact Set->Software Development Plan->Risk Management Plan
Module 2 Iterative Development

31. An Executable Architecture
PRJ270: Essentials of Rational Unified Process
An Executable Architecture
A (testable) validation of the architecture
Tested via architecturally-significant use cases
The baseline for the rest of development
Provides mitigation for numerous risks
System-
software
Middleware
Business-
specific
Application-
Components of the architecture need to be validated as early as possible because they have a significant effect on the development project. Validation is done by executing (not just diagramming) these components using specifically selected application components that exercise the architectural functions.
Module 2 Iterative Development

32. Intellectual Control: 4+1 Architecture Views
PRJ270: Essentials of Rational Unified Process
Intellectual Control: 4+1 Architecture Views
The 4+1 model is introduced here and because it is important for the students to see how the views fit together up front, in order to set context.
Discuss the 4+1 views at a high level. These are covered in detail in RUP.
Emphasize that the architectural views are the architecturally-significant subsets of system models.
Not all systems require all views (e.g., single processor: drop deployment view; single process: drop process view; small program: drop implementation view, etc.). A project may document all of these views or additional views. The number of views is dependent on the system you’re building.
These views and their representation in UML are discussed in the Artifacts module.
Note: More information than the views is required to capture the software architecture. This information is captured in the Software Architecture Document (SAD).
Logical View
Implementation View
End-user
Functionality
Analysts/Designers
Structure
Programmers
Software management
Use-Case View
Process View
Deployment View
Many different parties are interested in the architecture (such as the system analyst, the designers, the end users, and so on). To allow these parties or stakeholders to communicate, discuss, and reason about architecture, you need to have an architectural representation they understand. Because different stakeholders have different concerns and because architecture is quite complex, multiple views are required to represent architecture adequately. An architectural view is a simplified description (an abstraction) of a system from a particular perspective or vantage point, covering particular concerns, and omitting entities that are not relevant to this perspective.
While many views of architecture can be useful, RUP identifies 4+1 views as a standard set:
The logical view addresses the conceptual structure of the system. It is an abstraction of the design model, identifying major design packages, subsystems, and classes.
The implementation view describes the organization of static software modules in the development environment, in terms of packaging, layering, and configuration management.
The deployment view shows how the various executables and other run-time components are mapped onto the underlying platforms or computing nodes.
The process view addresses the concurrent aspects of the system at run-time: tasks, threads or processes, and their interactions.
The use-case view contains a few key scenarios or use cases that are used to drive and validate the architecture.
Performance
Scalability
Throughput
System integrators
System engineering
System topology
Delivery, installation
communication
Module 2 Iterative Development

33. Architecture Description
PRJ270: Essentials of Rational Unified Process
Architecture Description
Software Architecture Document
Represents comprehensive overview of the architecture of the software system
Includes
Architectural Views
Goals and constraints
Requirements that architecture must support
Technical constraints
Change cases
Size and performance characteristics
Quality, extensibility, and portability targets
The Software Architecture Document serves as a communication medium between the architect and other project team members regarding architecturally significant decisions which have been made on the project.
For more information, see Artifacts->Analysis and Design Artifact Set->Software Architecture Document in RUP.
Module 2 Iterative Development

34. Architecture Description (cont.)
PRJ270: Essentials of Rational Unified Process
Architecture Description (cont.)
Views are pulled from other artifacts
Design Model
Deployment Model
Implementation Model
In addition to its own data, the Software Architecture Document reports on architectural features contained in other artifacts. Note that both the Logical View and Process View are subsets of the Design Model.
Module 2 Iterative Development

35. Architecture As a Basis for Project Management
PRJ270: Essentials of Rational Unified Process
Architecture As a Basis for Project Management
A stable architecture represents a significant project milestone.
Poor architecture is often a reason for project failure.
Architecture is a prerequisite for predictable planning.
Architecture is the source of numerous high-payoff/high-risk decisions.
In RUP, the architecture is primarily an outcome of the Analysis & Design discipline workflow. As the project re-enacts this workflow, iteration after iteration, the architecture evolves and becomes refined and polished. As each iteration includes integration and test, the architecture is quite robust by the time the product is delivered. This architecture is a main focus of the iterations of the Elaboration phase, at the end of which the architecture is normally baselined.
Module 2 Iterative Development

36. Early Baselining of Architecture
PRJ270: Essentials of Rational Unified Process
Early Baselining of Architecture
Architecture
drives the definition of phases
drives the content of iterations
drives team organization
In RUP, you baseline your architecture at the end of Elaboration, and refine your architecture in following iterations.
Since architectural components define a structure for the product, its elements provide a natural way of organizing plans, deliverables, and responsibilities.
Module 2 Iterative Development

37. More RUP Resources About Architecture
PRJ270: Essentials of Rational Unified Process
More RUP Resources About Architecture
Disciplines->Analysis and Design-> Concepts/Guidelines
Software Architecture Document artifact description at Artifacts->Analysis and Design Artifact Set->Software Architecture Document
Architecture-related guidelines at Artifacts -> Analysis and Design Artifact Set-> Software Architecture Document-> Guidelines
Architecture-related concepts at Artifacts-> Analysis and Design Artifact Set-> Software Architecture Document-> Concepts
Module 2 Iterative Development

38. Use of Objective Measurements
PRJ270: Essentials of Rational Unified Process
Use of Objective Measurements
Measurements are used to provide the development team with:
An accurate assessment of progress to date
Insight into the quality of the evolving software product
A basis for estimating the cost and schedule for completing the product with increasing accuracy over time
Measurements should reflect the “real” state of what is measured. Subjective measurements have much less value.
Module 2 Iterative Development

39. Use of Measurements in Iterations
PRJ270: Essentials of Rational Unified Process
Use of Measurements in Iterations
Measurements are used to assess iterations.
They are built into the Iteration Plan evaluation criteria.
Start Iteration Using
Iteration Plan
Start Next Iteration
Complete Planned
Iteration Work
Adjust
Objectives
Adjust Target
Product
Adjust Remaining
Plan
Plan Next
Iteration
Project Stopped
Stop
Assess
Continue
Measurements
Measurements are one of the inputs to iteration assessment and subsequent planning. Low grades on some measurement (when compared to requirements or estimates) may require rework and/or redirection in the next iteration.
Module 2 Iterative Development

40. Measurements Collection
PRJ270: Essentials of Rational Unified Process
Measurements Collection
Measurements should:
Be simple and objective
Be easy to collect
Be easy to interpret and hard to misinterpret
Measurements collection should:
Be automated and non-intrusive for developers
Contribute to quality assessment early in the lifecycle, when efforts to improve software quality are effective
Measurements absolute values and trends should:
Be actively used to communicate progress and quality in a consistent format
The selection of a set of measurements will depend on the project's characteristics and context.
Module 2 Iterative Development

41. PRJ270: Essentials of Rational Unified Process
Seven Core Metrics
There are seven core metrics that should be used in iterative development:
Management Indicators:
Work and progress (work performed over time)
Budgeted cost and expenditures (cost incurred over time)
Staffing and team dynamics (personnel changes over time)
Quality Indicators:
Change traffic and stability (change traffic over time)
Breakage and modularity (average breakage per change over time)
Rework and adaptability (average rework per change over time)
Mean time between failures (MTBF) and maturity (defect rate over time)
“Software Project Management – A Unified Framework.” Walker Royce, Addison-Wesley, 1998 p Note [Royce 1998] uses the term “metrics.” For the purposes of this course, the terms “metrics” and “measurements” are used interchangeably.
Module 2 Iterative Development

42. Purpose of Seven Core Metrics
PRJ270: Essentials of Rational Unified Process
Purpose of Seven Core Metrics
Metric
Purpose
Work and progress
Iteration planning, plans vs. actuals, management indicator
Budgeted cost and expenditures
Financial insight, plan vs. actuals, management indicator
Staffing and team dynamics
Resource plan vs. actuals, hiring rate, attrition rate
Change traffic and stability
Iteration planning, management indicator of schedule convergence
Breakage and modularity
Convergence, software scrap, quality indicator
Rework and adaptability
Convergence, software rework, quality indicator
MTBF and maturity
Test coverage/adequacy, robustness for use, quality indicator
Module 2 Iterative Development

43. PRJ270: Essentials of Rational Unified Process
Metrics Over Phases
The metrics shown in the previous slide will evolve across the lifecycle of the project. A mature organization will be able to describe much more precise targets.
Examples:
Metric
Inception
Elaboration
Construction
Transition
Expenditures
Effort
Schedule
Low 5%
10%
Moderate
25%
40%
High
90%
100%
Stability
Architecture
Applications
Volatile*
Volatile
Moderate*
Stable
Stable*
The guidance given here for these metrics is intended to emphasize the spirit of the milestones in RUP rather than exact numeric values.
Information adapted from “Software Project Management – A Unified Framework.” Walker Royce, Addison-Wesley, 1998 p. 200
*Objective measure must be defined.
Module 2 Iterative Development

44. More Resources About Measurements
PRJ270: Essentials of Rational Unified Process
More Resources About Measurements
In RUP
Metrics guideline at Artifacts->Project Management Artifact Set->Software Development Plan-> Measurement Plan-> Metrics (Guideline)
Metrics concept at Roles and Activities->Managers->Project Manager->Assess Iteration->Metrics (Concept)
Rational® ProjectConsole
Collects metrics from Rational tools and other sources
Displays metrics in form of charts, bar graphs, and so on
Module 2 Iterative Development

45. Characteristics of Iterative Development
PRJ270: Essentials of Rational Unified Process
Characteristics of Iterative Development
You can control allocation of resources by phase.
You can evolve artifacts as required by phase.
You can increase the precision of your cost estimates from phase to phase.
Module 2 Iterative Development

46. Typical Effort and Time Percentages by Phase
PRJ270: Essentials of Rational Unified Process
Typical Effort and Time Percentages by Phase
Time
People
Const
Elab
Trans
Inc
Note the fact that a relatively small part of the expense is incurred by the end of Elaboration, when the all significant architectural risks are removed and the product can be built with high confidence.
Note also that Inception and Elaboration can be considered the Engineering Stage (where discovery and invention are firmed up) and that Construction and Transition can be considered the Implementation Stage (where work can proceed on a firm foundation).
Inc
Elab
Const
Trans
Effort 5%
20%
65%
10%
Time/Schedule
30%
50%
Module 2 Iterative Development

47. Lifecycle Evolution of Artifacts
PRJ270: Essentials of Rational Unified Process
Lifecycle Evolution of Artifacts
Artifacts are organized into sets, one set per discipline. In an iterative development process, the various artifacts are not produced in one phase, completed or even frozen before moving on to the next phase. Instead, the artifact sets evolve throughout the development cycle.
With the iterative approach, artifact sets mature over time.
Module 2 Iterative Development

48. Cost Estimate Fidelity
PRJ270: Essentials of Rational Unified Process
Cost Estimate Fidelity 4X
Inception
Elaboration
Construction
Transition
Over-estimated
Error in Cost to Complete Estimate
In an iterative process such as RUP, cost estimations can be done with increasing levels of precision as phases progress.
Information adapted from “Software Project Management – A Unified Framework.” Walker Royce, Addison-Wesley, 1998 p. 265 .
Under-estimated
X/4
Module 2 Iterative Development

49. PRJ270: Essentials of Rational Unified Process
Review
The Rational Unified Process:
Is divided into four phases, each with a distinct milestone. These phases are further divided into iterations.
Addresses several areas of concern (disciplines) repeatedly in each phase. Each area is addressed at different levels in each phase.
Contains artifacts that help you plan and assess each iteration.
Contains information and guidance to help you address the major concerns in iterative development. These major concerns are:
Early mitigation of risk
Early executable architecture
Use of objective measurements for planning
Allows you to control allocation of resources by phase, to evolve artifacts as required by phase, and to increase the precision of your cost estimates from phase to phase.
Module 2 Iterative Development

50. Exercise: Student Exploration of RUP
PRJ270: Essentials of Rational Unified Process
Exercise: Student Exploration of RUP
15 minute student exploration of RUP to review module. Explore:
RUP Lifecycle
Inception
Elaboration
Construction
Transition
Iteration Plan artifact description and related guidelines/concepts
Iteration Assessment artifact description and related guidelines/concepts
Risk resources
Architecture resources
Measurements/Metrics resources
Allow students about fifteen minutes to navigate to areas indicated. RUP tree browser paths were given in previous slides in this module.
RUP tree browser paths were provided in previous slides and notes in this module. .
Module 2 Iterative Development