OUM - Level 1 & 2 Certification Content

<Insert Picture Here>
OUM Level 1 & 2 Training for Partners

Sarkis Kerkezian – CEP Enablement Manager
Agenda
1. Why OUM ?
2. Key Concepts of OUM
3. A Deep Dive into OUM
4. Gathering Requirements: use cases intro
5. OUM on Application implementation project
6. Material Available to Partners
7. Key Take Aways
8. Open Discussion
2/159
1. Why OUM ?
Why a method is necessary?
4/159
Compass Upgrade View
EasiPath Migration Method
Compass Standard View CDM FT RBGU – Retek et al
Siebel Analytics CDM Classic
CGBU - Portal Xcellerate
OTM – G-Log
AIM Foundation
Siebel Results Roadmap Data Warehouse Method FT

AIM for Business Flows Compass Accelerated View
Stellent Hyperion
Revenue Tangosol Agile
5/159
Basics
OUM
Oracle® Unified Method (OUM)
A single, integrated method, to support the

entire Oracle ecosystem, across the
complete suite of Oracle products
6/159
Oracle Unified Method Vision
“The vision for the Oracle® Unified Method is to support

the successful implementation of every Oracle product
– application, middleware, and database.
Oracle has two objectives for the method –
Ensure that usage of our products meets our customer's
business objectives.
Ensure that customers are able to take full advantage of our
products' rich capabilities.
The net result being a Superior Ownership Experience
for all of Oracle's customers.”
7/159
Basics
Oracle Unified Method Goals
• “Best of the Best”
• Single Method Framework
• Fusion Technology Foundation
• Release Independent
• Tight Integration with
Sales Methodology
and Enterprise-Level Processes
8/159
OUM Benefits
• Common language across

Oracle ecosystem
• More readily accommodate
future acquisitions
• Reduce confusion for our customers
• Focus methods investment on deeper materials
rather than duplicative maintenance
9/159
Why in Oracle ?
• Our clients ask for proof of a sophisticated professional
methodology
• Develop consistent processes, tools and templates that
– support quality, speed and cost effectiveness of implementation
projects
– improve profitability and the ability to grow the business
– provide a common language across different organizations
• Oracle supports our partners/clients in implementing end-to-end
Oracle solutions that can consist of:
– Oracle Application products (EBS, Siebel,...)
– Oracle Technology products (AIA, ...)
• Oracle projects use Application Implementation approach as well
as a Technology Implementation approach.
10/159
2. Key Concepts of OUM
OUM Training for Partner Dubai 12 - May - 2011

OUM is…
• A product and technology agnostic methodology
• Standards based –
– Unified Process (UP)
– Project Management Institute Body of Knowledge (PMI PMBOK)
– Business Analysis Body of Knowledge (IIBA BABOK)
– Unified Modeling Language (UML)
– Business Process Modeling Notation (BPMN)
• Business Process and Use Case-driven
• Architecture-centric
• Iterative & incremental
• Risk-focused
• Flexible and Scalable
12/159
OUM is Flexible and Scalable
– Do not serve the method; make it serve you.

• If you are not going to need it, don’t do it.
13/159
– OUM may be scaled in a number of dimensions or better

stated, OUM employs the concept of “fit-for-purpose” by:
• Eliminating unnecessary tasks from the workplan
• Combining tasks or executing at the activity level
• Starting with a core set of tasks and adding tasks as
risks and scope are identified
• Reducing the depth to which specific tasks and activities
are executed
14/159
Flexible and Scalable: Fit-for-Purpose
• Adopted from Dynamic Systems Development Method
(DSDM)
• Focused on delivering necessary functionality
within the required timebox
• Also refers to defining level of rigor
and ceremony appropriate to project
15/159
Basics
Comprehensive Toolkit
Templates
Guidelines Create high quality Tailored
Focus areas, views, work products Workplans
phases, activities,
processes, and Accelerated starting
tasks point
Overview Supplemental
Material Guidance
Approach and
OUM Products, tools,
techniques, and
standards technologies
Easy Access
Hosted or installed locally
16/159
OUM Structure
Views
17/159
OUM Structure
Supplemental Guidance
Supplemental
Guides
White Papers
Review Viewlets
Checklists and
Guidelines
Cross
References
Helpful Discipline/Industry/View Resources and Samples
18/159
OUM Principles
Business Process
& Use Case-Driven
OUM
Flexible Iterative &
& Scalable Envision Implement Incremental
Manage
Risk-Focused Architecture-Centric
19/159
3. A Deep Dive into OUM

OUM Focus Area Views:
Envision – enterprise level processes Implement

• • Supports software engineering
Enterprise Business Analysis
and implementation of Oracle
• Enterprise Architecture
OUM application and technology
products
• IT Portfolio Management
• IT Governance • Business Process and
Use Case-driven
• Adoption and Learning
• Iterative and Incremental
Envision Implement • Architecture-centric
• Standards-based
• Balanced and Flexible
Manage
Manage
• Promotes disciplined management
of information technology
Projects and Programs
• Aligns with Project Management
Institute (PMI)
21/159
Implement Focus Area
22/159
Implement Focus Area Structure
AIM Methodology
• 6 Phases
• 11 Processes
• 0 Iterations
23/159
ABF Methodology
• 5 Phases
• 9 Processes
• n Iterations
24/159
Key Terms & Concepts
• Phase
• Lifecycle Milestone
• Process
• Activity
• Task
• Dependency
• Work Product
25/159
Key Terms & Concepts: Phase
Phases are chronological grouping of
tasks in an approach. Services are Phases
delivered by phase in order to reduce
project risk. Each phase allows a Inception Elaboration Construction Transition Production
checkpoint against project goals, and

measurement against quality criteria
to be made.
Phases are temporal groupings

Phases cut vertically through
project activities
Are natural points to establish
milestones for progress
checkpoint
26/159
Key Terms & Concepts: Lifecycle
Milestones
Unified Process – Lifecycle Phases
Milestones are major
synchronization points that occur Inception Elaboration Construction Transition Production
at phase boundaries.
Assure objectives of the phase
have been met
Decisions are made on readiness
for the next phase
Decisions on Schedule, Budget,
Requirements to go forward into
the next phase
Major LO LA IOC SP SO
Milestones
27/159
Implement Lifecycle Major Milestones
Inception Elaboration Construction Transition Production
LO LA IOC SP SO
• Inception – Lifecycle Objectives Milestone (LO)

• Elaboration – Lifecycle Architecture Milestone (LA)
• Construction – Initial Operational Capability Milestone (IOC)
• Transition – System Production Milestone (SP)
• Production – Sign-Off Milestone (SO)
28/159
Key Terms & Concepts: Process
A process is a discipline or
sub-project that defines a
set of tasks related by Inception Elaboration Construction Transition Production
subject matter, required

skills and common
Processes
dependencies.
Examples:
• Business Requirements
• Data Acquisition &
Conversion
• Operations & Support
OUM Training for Partner Dubai 12 - May - 2011 29/159

Key Terms & Concepts: Activity
An Activity is a set of tasks related
either by topic, dependencies, data, Activities
common skills/roles, or work
products. The tasks in an activity Inception Elaboration Construction Transition Production
may be from different OUM

processes. Activities in OUM begin
and end in the same method phase.
An activity is the next level of
organization below a phase
Examples:
• Analyze & Design
• Gather Solution
Requirements
• Develop Use Cases
30/159
Key Terms & Concepts: Task
A task is a unit of work that is
done in delivering a service. A Tasks
task is the smallest traceable
item on a project workplan, and Inception Elaboration Construction Transition Production
forms the basis for a work

breakdown structure.
• Tasks may have one or more outcomes/outputs:
– Setup of an application
– Creation or update of a document
– Execution of an activity (i.e. Test Plan)
• A “Work Product” MAY become a “Deliverable”
– Not all workproducts are given to clients
• A work product must be tangible and
measurable.
31/159
Key Terms & Concepts: Dependency
A Dependency is an
indication that one task Dependencies
cannot begin until another
task has ended, or
progressed to a certain
specified level of completion
Predecessor task(s), Successor
task(s)
Overlap
– time in days that two tasks can
overlap each other
Gap
– time in days that two tasks must
be separated by
32/159
Key Terms & Concepts: Work Product
A Work Product is something a project must
produce in order to meet its objectives. It must be
tangible and measurable. An output of a Task is a
Work Product.
• Templates and examples can be found in the method for work products
• A work product does not need to be a document
• May or may not be delivered to the client
• Work products can easily be –
• a model in a repository
• a prototype
• a set of application code
• tacit knowledge contained in the brain of a project team member
33/159
OUM Components
Work Product
• Output of a task Document
• Required to meet
project objectives
• No need to be a Knowledg Work
e Products Model
document
• May or may not
be a “deliverable”
Application
Code
Working
Software
34/159
Agenda of deep dive
 OUM Approach  Implement Focus Area
 Unified Process Structure
• Business Process Driven  Phases
• Use Case Driven  Milestones
• Architecture Centric  Processes
• Iterative
• Incremental
• Releases  Key Concepts & Principles
• Risk Focussed  Key Terms
 Key Concepts & Principles
 OUM Implement
Components  Applying OUM
 Focus Areas  OUM Key to Success Concepts
• Manage Focus Area  Balancing Agility and Discipline
• Envision Focus Area
• Implement Focus Area
 OUM Views
• Focus Area Views  Working with Templates
• Disciplinne Views  Demo
• Service Offering Views  Navigation Practice
35/159
Agenda of deep dive
• Iterative
• Incremental
 OUM Implement
 OUM Views
36/159
OUM Approach
What is the Unified Process (UP) ?
• “The Unified Software Development Process or
Unified Process is a industry standard iterative and
incremental software development process
framework.
• The best-known and extensively

Unified Process
documented refinement of the
Unified Process is the Rational
Unified Process or RUP.”
~ Wikipedia.org
37/159
OUM Approach
UP Characteristics
• Use Case-Driven
• Architecture-Centric
• Risk-Focused
Unified Process
38/159
OUM Approach
OUM expands on UP Characteristics
• Use Case-Driven
• Risk-Focused
• Business Process and Use Case-Driven
• Fit-for-Purpose
39/159
OUM Approach
Business Process-Driven
• Business Processes and Use Cases are the primary
requirements gathering mechanisms
• Requirements are documented through
– Business Process Models
– Use Cases
– Written supplemental and quality of service requirements
40/159
OUM Approach
Use Case-Driven
• Provide a consistent mechanism to link system requirements to
design and test tasks
• Bridge the gap between business modeling, business processes,
and software system functionality
• Provide a consistent thread through OUM – use cases help
amplify and consolidate the many other benefits of the method
• Identify implicit or unstated requirements, i.e. items that are not
typically shown on a process model
• And finally, manage traceability of requirements through testing
41/159
OUM Approach
Architecture-Centric
• Architecture
– More than just “technical architecture”
– Refers to the set of significant decisions about the organization of a
software system
– Contains the organization of the system with structural elements and
interfaces, and their behavior
– Is the collection of models that describe the system
– The system’s architecture is used as a primary artifact for
conceptualizing, constructing, managing, and evolving the system
• The Baseline Architecture is a key work product of Elaboration
42/159
OUM Approach
Iteration
– An iteration is a distinct set of activities conducted
according to a devoted (iteration) plan and evaluation
criteria that results in a release, either internal or
external.
– Iterative is redoing something several times, increasing
its richness, comprehensiveness, and consistency each
time.
43/159
OUM Approach
Increment
– An increment is the difference between the release of
one iteration and the release of the next iteration.
– Incremental is creating something one piece at a time

and integrating the pieces into the whole a little at a
time.
44/159
OUM Approach
Release
• A Release is a relatively complete and consistent set of
artifacts or work products – possibly, but not necessarily
including a software build – delivered to an internal or
external user.
• Releases act as a forcing function that drives the

development team to get closure at regular intervals,
avoiding the "90% done, 90% remaining" syndrome.
45/159
OUM Approach
Iterations, Increments, Releases
• OUM employs an iterative and incremental approach to
implementing software systems.
• In OUM, the result of an iteration is an increment.
• This may differ from the definitions used in other Oracle
methods, like CDM Fast Track and DWM Fast Track.
• The terms iteration and increment are defined in OUM
to be consistent with this concept.
• A release is a set of artifacts or work products, possibly
but not necessarily including a software build, delivered
to an internal or external user.
46/159
OUM Approach
Iterative Development
Business Requirements Analysis Design Implementation Test

Requirements Analysis


47/159
Iterations Can Be Considered Mini-Waterfalls
RD 1 2 3 4 5 6
RA 1 2 3 4 5 6
AN 2 3 4 5 6
DS 2 3 4 5 6
IM 1 2 3 4 5 6
TE 1 2 3 4 5 6 7 8
TS 7 8
PS 9
Iterations 1 2 3 4 5 6 7 8 9
Milestones
IOC
time
LO LA Releases SP SO
Legend
RD - Business Requirements DS - Design TS - Transition
RA - Requirements Analysis IM - Implementation PS - Operations & Support
AN - Analysis TE - Test 1 - Iteration Number
48/159
OUM Approach
Concepts of Iterations & Increments
49/159
OUM Approach
50/159
OUM Approach
group by priority
Increment 1 Increment 2 Increment 3
+ +
CR-s Increment 1 CR-s Increment 2
51/159
OUM Approach
Risk-Focused
• A key focus of each iteration in OUM is to identify and
reduce the most significant project risks
• This ensures that the project team addresses the most
critical risks as early a possible
52/159
OUM Approach
Fit-for-Purpose
• OUM employs the concept of “Fitness-for-Business
Purpose” in two ways
• The focus is on first delivering necessary functionality to
meet the needs of the business.
• OUM also encourages scaling the method to be
fit-for-purpose for a given situation, that is, it is rarely
appropriate to execute every activity within OUM.
53/159
OUM Approach
What is UML ?
• “The Unified Modeling Language (UML) is a
standardized specification language for object
modeling.
• UML is a general-purpose modeling language that

includes a graphical notation used to create an
abstract model of a system…”
~Wikidepdia.com
54/159
OUM Approach
Application Approach
OUM’s application implementation approach is similar to current
methods in these areas:
• Business Process based
• Future business processes are fit to standard functionality to
identify gaps – Fit/Gap
• Key business architecture structures are defined
• Application Setups are defined
• Leading practices from Oracle’s legacy methods are included
• Supports two implementation approaches -
– Requirements-Driven (e.g., AIM Foundation, Compass Standard)
– Solution-Driven (e.g., AIM for Business Flows, Compass Accelerated)
55/159
OUM Approach
Oracle Unified Methode Approach
OUM’s implementation approach differs from current methods in
these areas:
• Standards Based – Unified Process
• More Comprehensive in Scope
• Supports both Enterprise-Level and Project-Level Activities
• Tighter Integration across Disciplines
• Tighter Integration to Oracle Sales
Methodology
• Increased emphasis on Architecture
56/159
Agenda of deep dive
• Iterative
• Incremental
 OUM Implement
 OUM Views
57/159
OUM Implement Components
OUM Focus Area
Envision – enterprise-level processes Implement
• • Supports software engineering
Envision Roadmap
and implementation of Oracle
• Enterprise Business Analysis application and technology
• Organizational Change
OUM products
Management • Business Process and
• Enterprise Architecture Use Case-driven
• IT Portfolio Management • Iterative and Incremental
• IT Governance Envision Implement • Architecture-centric
• Standards-based
• Balanced and Flexible
Manage
Manage
• Promotes disciplined management
of information technology
Projects and Programs
• Aligns with Project Management
Institute (PMI)
58/159
Manage Focus Area
59/159
Envision Focus Area
Slide 60
60/159
61/159
• The Good
– Contains a comprehensive set of method materials
– Supports development and implementation of a broad
range of business solutions.
• The Bad
– The volume of material can be overwhelming
– It can be difficult to isolate and comprehend
the “essentials”
• And the Ugly Elegant! Solution
• OUM Implement Core Workflow
• Two parallel and complementary sub-flows:
• Mapping and Configuration
• Custom Development
62/159
Why a “Core Workflow” ?
• Accelerate new practitioners’ understanding of OUM

• Identify the core tasks of the Implement Focus Area
• Provide a starting point for building up the work plan
• Keep project teams focused on the essentials
63/159
Scalable: Build Up - Don’t Tailor Down
1. Start from the core set of tasks.

2. Add tasks as you identify scope and risk.
3. Consider the depth to which you will execute
specific tasks during specific iterations.
4. Consider whether it is advisable to combine tasks
– Work at the activity level
– Combine work products, as appropriate
• NOTE: Be careful when doing this to avoid inflexibility
Balancing Agility and Discipline: A Guide for the Perplexed

1
by Barry Boehm and Richard Turner
64/159
Implement Core Workflow
• The OUM Implement Core Workflow helps
practitioners get started with OUM and keeps
teams focused on the essentials.
• By identifying core tasks, the workflow provides a starting point for
building up a work plan.
• The OUM Implement Core Workflow has two sub-flows
• Mapping and Configuration
• Custom Development
• The OUM Implement Core Workflow is executed in each
iteration of Inception, Elaboration and Construction, but the focus
shifts from phase to phase.
• More details for the OUM Implement Core Workflow are provided
in the OUM Level 3 – Requirements Gathering Course.
65/159
Core Workflow
66/159
Core Workflow – Focus thru project lifecycle
67/159
OUM Views
A View presents a predefined subset of the OUM materials.
<
<
<
68/159
Focus Area Views
Each Focus Area can be accessed in OUM through its applicable
Focus Area View.
69/159
Requirements - Driven Appl. Impl. View
The Requirements-Driven Application Implementation View reflects a
requirements-driven approach to implementing packaged
applications in that it is based on identifying requirements and
crafting a business solution based on those requirements during the
course of the project (access via view catalog screen).
70/159
Solution - Driven Appl. Impl. View
The Solution-Driven Application Implementation View reflects a
solution-driven approach to implementing packaged applications that
leverages a pre-defined business solution (e.g., Oracle Business
Accelerators, access via view catalog screen).
71/159
Technology Full Lifecycle View
The Technology Full Lifecycle View provides access to the material
required for full lifecycle technology projects, including:
• Support for custom development, middleware, service-oriented
architecture, and technology based implementations
• Support for several areas through Technical Guidelines
(access via view catalog screen).
72/159
Agenda of deep dive
• Iterative
• Incremental
 OUM Implement
 OUM Views
73/159
Inception Phase
Activities:
Inception Elaboration Construction Transition Production • Gather Business Requirements
• Establish Current Business Baseline
• Gather Solution Requirements
• Consolidate Solution Requirements
• Create Conceptual Prototype
• Gather Supporting Requirements
• Specify Key Structure Definition
• Create and Manage Ad Hoc
Communications
• Conduct Executive Alignment Workshop
• Train Project Team
• Conduct Alignment Workshops
• Conduct Organizational Readiness
Assessment
• Deploy Change Management Roadmap /
Key Outputs: Communication Campaign
• Requirements
• Conceptual Prototype
• Technical Architecture Requirements
• Performance Management Requirements
• Skilled Project Team
• Executive Execution Plan / Governance Rules
74/159
Inception Phase - Objectives
“Confirm Business Objectives and Project Goals”
“Gather Key Requirements”
“Prepare Project Team”
Objectives
1. Obtain clear understanding of business benefits to be
achieved
2. Identify and mitigate risks
3. Identify and educate project stakeholders
4. Define, document and prioritize business requirements
75/159
Lifecycle Objective Milestone - Objectives
• Inception
 Confirm:
– Lifecycle Objective Milestone
 Business objectives
• Elaboration
 Goals
– Lifecycle Architecture
 Requirements (Use
Milestone
Cases)
• Construction
 Risks
– Initial Operational Capability
Milestone  Update schedule and cost
• Transition estimates
– System in Production  Complete Conceptual
Milestone Prototype
• Production  Is it feasible to proceed?
– Sign-Off Milestone
76/159
Elaboration Phase
Activities:
• Gather Business Requirements
• Develop Use Cases
• Create Conceptual Prototype
• Consolidate Specification
• Define Project Strategy
• Develop Test Plans
• Prepare Environments
• Perform Fit Gap
• Specify Software Configuration
• Baseline Software Architecture
• Analyze and Design
• Develop and Validate Prototypes
• Perform Unit, Integration and System Tests
• Plan Performance Management
• Define Infrastructure
• Prepare to Acquire and Convert Data
• Monitor Sponsorship Program
Key Outputs: • Deploy Change Management Roadmap /
• Requirements Specifications Communication Campaign
• Functional & User Interface Standards Prototypes
• Architecture Description
• Performance Management Requirements
• Analysis and Design Models and Database Design
• Testing Strategy, Test Scripts and Programs Design
77/159
Elaboration Phase - Objectives
“The most Critical Phase”
“Understand the Requirements”
“Baseline the Architecture”
Objectives
1. Prioritize, refine and analyze requirements into use cases
2. Agree on the visual approach to the user interface
3. Agree on the user involvement
4. Establish a sound architectural foundation
5. Develop the initial technical model and partition the components
6. Verify whether the project can move to the next phase
7. Mitigate risks
78/159
Lifecycle Architecture Milestone
Objectives
 Stable architecture?
 Application
• Inception
 Technical
 Data
• Elaboration
– Lifecycle Architecture  Executable code showing that
Milestone architectural risks have been
• Construction mitigated?
– Initial Operational Capability  Construction Phase plan detailed
Milestone and accurate?
• Transition  Implementation team ready?
– System in Production
Milestone
 Can we commit resources to
• Production begin implementation?
79/159
Construction Phase
Activities:
Inception Elaboration Construction Transition Production • Finalize Requirements
• Analyze and Design
• Perform Test Planning
• Prepare Environments
• Implement System
• Perform Unit, Integration and System Tests
• Conduct Systems Integration Test
• Prepare for Performance Testing
• Prepare for Transition
• Prepare for Cutover
• Test Infrastructure
• Prepare to Acquire and Convert Data
• Acquire and Convert Data
• Produce Documentation
Communication Campaign
• Conduct Job Impact Analysis
• Conduct Managers’ Alignment Workshop
Key Outputs:
• Design and Build End-User Training
• Architecture Description • Train End Users
• System-Tested Applications
• Integration-Tested System
• Transition and Contingency Plan
80/159
Construction Phase - Objectives
“Cost-effectively implement high-quality software”
Objectives
1. Detail the remaining use cases and refine Analysis and
Design Models
2. Obtain refinements to requirements
3. Iteratively, produce a physical database, integrate developed
or reused components, and configure product components,
to produce an integrated system
81/159
Initial Operational Capability
Milestone Objectives
• Inception
• Elaboration
 Beta release stable?
Milestone
• Construction  Stakeholders ready for Transition?
– Initial Operational Capability  Ready for the User Acceptance
Milestone Test ?
• Transition
Milestone
• Production
82/159
Transition Phase
Production
Activities:
Inception Elaboration Construction Transition
• Support User Acceptance Test
• Conduct Performance Test
• Convert Data
• Go Production
• Deploy Change Management
Roadmap / Communication Campaign
• Conduct IT Alignment
• Train End Users
• Finalize Documentation
Key Outputs:
• Acceptance Test Results
• Converted and Verified data
• Skilled Users
• Production Support Infrastructure
• System in Production
83/159
Transition Phase Objectives
“Fine Tune functionality, performance & quality”

“Go Live”
Objectives
1. Gain acceptance of the project
2. Support the client during the Acceptance Test
3. Validate that the system meets the requirements for Production
4. Prepare the Production Environment
5. Convert data from existing systems
6. Establish the maintenance environment required for support
84/159
System in Production Milestone
Objectives
• Inception
• Elaboration
Milestone
• Construction  Go Live!
Milestone  Stakeholders satisfied with the
• Transition project?
– System in Production  Package reusable components
Milestone
 Report estimate versus actual
• Production to improve OUM estimates
85/159
Production Phase
Activities:
Inception Elaboration Construction Transition Production • Manage Production System Performance
• Evaluate Production System
• Resolve Production Problems
• Upgrade System
Communication Campaign
• Plan for Future
• Deploy IT Transition Plan
Key Outputs:
• System Evaluation
• Upgraded Application System
• Organizational Effectiveness Assessment
• Future Functional Enhancements
• Future MoSCoW List
86/159
Production Phase Objectives
“Obtain Sign-Off”
“Close Contract”
Objectives
1. Fulfill obligations during the warranty period
2. Monitor the system performance and solve any problems
3. Log problems and make corrections
4. Provide agreed on level of user support
5. Deliver a plan for continuing management and support
6. Assess the success of the solution
7. Develop and Enhancement Plan
87/159
Sign-Off Milestone Objectives
• Inception
• Elaboration
Milestone
• Construction
Milestone
• Transition
 Close out the contractual
agreements
Milestone
• Production  Release staff and physical
– Sign-Off Milestone resources
 Preserve intellectual property
88/159
Nominal Effort for Implement Phases (
5%
25~30 %
40~55 %
15 %
5~10 %
The above is an example, in case of solution driven approach with minor customizations,
there will be a % shift from construction to inception and elaboration
89/159
Agenda of deep dive
• Iterative
• Incremental
 OUM Implement
 OUM Views
90/159
Key Concepts and Principles
Key Terms - Workshops
• Workshops are used often in OUM.
• Old-fashioned' interview technique is de-emphasized.
• Main workshop in OUM is the Business Requirements
Workshop.
• Many different techniques are used in workshops –
brainstorming, feedback, walkthroughs, etc.
• Workshops ensure that all the necessary persons are
present and involved simultaneously.
91/159
Key Terms - Prototyping
• Prototyping is used to improve the communication
between the developers and the users.
• Instead of talking about something imaginary, a working
prototype of user access components is developed.
• Prototypes may be throwaway, but ideally they are
used as the starting point for development of the next
iteration.
92/159
Key Terms - Unified Modeling Language
UML (Unified Modeling Language)
A standard language for specifying, visualizing, constructing. and
documenting the components of a software system.
Can also be used for business modeling and for non-software
systems.
UML is a modeling convention which brings standard modeling
practices together in one set of conventions for syntax of
models.
93/159
Business Requirement Workshop
• OUM recommends using workshops as the primary
technique for validating and refining requirements:
– Detail Business and System Objectives
– Create System Context Diagram
– Develop Future Process Model (Business Process Models)
– Obtain High-Level Business Descriptions
– Develop Business Use Case Model
– Develop Domain Model
– Document Present and Future
Organizational Structures
94/159
Timeboxing & MoSCoW List
• When timeboxing is used a MoSCoW List must also be
employed. Timeboxing and MoSCoW list go always together.
• If duration is fixed, then there must be some ability to vary the
requirements.
• Where requirements are fixed, duration cannot be fixed and use
of timeboxes is not appropriate.
• Customers are often initially uncomfortable with “variable
requirements,” but normally grow to embrace this approach as
they experience its many benefits.
• OUM supports the use of either timeboxes or fixed
requirements.
95/159
To Timebox or Not To Timebox
The choice to use timeboxing can be difficult and foreign to organizations
used to managing fixed requirements.
Parkinson's Law - Work expands so as to fill the time available for its
completion.
However, business often requires “fit-for-business purpose” that is tested
and stabilized by a fixed date.
Timeboxing makes this possible by promoting prioritization and
decisiveness.
The focus is on what the business “must have.”
“Nice to have” items can be moved to the next release.
Timeboxing has additional benefits:
Typically, team satisfaction improves because of its focus on
prioritization and completion of incremental releases.
By releasing fit-for-purpose software, it promotes stakeholder
confidence.
96/159
How does OUM utilize MoSCoW List ?
• OUM supports the use of MoSCoW technique for
validating and refining requirements:
– During each iteration, the users validate and refine the
requirements
– Users need compare what has been developed with what was
agreed on at the end of the previous iteration.
– Users must review and refine the requirements so that the
business ultimately gets the solution it needs.
– These refined requirements are prioritized and placed on the
MoSCoW List.
– After validation, the new or changed requirements are evaluated,
and the final list will be the input for the next iteration.
97/159
Agenda of deep dive
• Iterative
• Incremental
 OUM Implement
 OUM Views
98/159
Applying OUM Implement Focus Area
Key to Success Concepts
• Understand the OUM Key to Success Concepts:
1. Understand OUM and the Unified Process (UP).
2. Do not serve the method; make it serve you.
3. OUM may be scaled in a number of dimensions.
4. The outputs of tasks are called “work products.”
5. Work products (or artifacts) need not be documents.
6. Focus on understanding the most significant risks
and requirements.
• Recognize that OUM supports both Agility and
Discipline
99/159
Key to Success Concept #1
– Understand OUM and the Unified Process (UP).
• Business Process and Use Case-Driven
• Risk-Focused
• Fit-for-Purpose
100/159
– Do not serve the method; make it serve you.
• If you are not going to need it, don’t do it.
101/159
– OUM may be scaled in a number of dimensions or better
stated, OUM employs the concept of “fit-for-purpose” by:
• Eliminating unnecessary tasks from the workplan
• Combining tasks or executing at the activity level
• Starting with a core set of tasks and adding tasks as
risks and scope are identified
• Reducing the depth to which specific tasks and activities
are executed
102/159
– The outputs of tasks are called “work products.”
103/159
– Work products (or artifacts) need not be documents.
• Tasks should be executed only to the level that is “fit for
purpose”.
104/159
– Focus on understanding the most significant risks and
requirements.
105/159
Key to Success Concepts - Review
1. Understand OUM and the Unified Process (UP)

2. Do not serve the method; make it serve you.
3. OUM may be scaled in a number of dimensions.
4. The outputs of tasks are called “work products.”
5. Work products (or artifacts) need not be documents.
6. Focus on understanding the most significant risks and
requirements
106/159
Balancing Agility and Discipline
– Discipline
• “Provides strength and comfort”
– Agility
• “Agility releases or invents”
– Projects need a balance of both Agility and Discipline to be
successful.
Balancing Agility and Discipline: A Guide for the Perplexed

by Barry Boehm and Richard Turner
107/159
– OUM is scalable and adaptable and supports both
Agility and Discipline.
• Plan-driven
• Agile
– OUM supports a continuum with “pure agility” and
“pure plan based” at its ends.
108/159
– The appropriate point of balance for a given project will vary
based on a number of project risk and scale factors.
• Project/organization size
• Culture
• Criticality
• Organization’s experience with Agile
• etc.
109/159
Agenda of deep dive
• Iterative
• Incremental
 OUM Implement
 OUM Views
110/159
OUM Method Pack
• OUM is distributed as a Method Pack

• Method Packs installable on
user’s desktop and may be hosted
• Simple HTML and MS Office Documents
• Browser Independent
• Packaged using commercial installer
111/159
MyDesktop
• Providing Access to:
– OUM
– Legacy Methods including: AIM, ABF, EMM, DWM FT, PJM
112/159
Working with Templates
OUM Home Page
113/159
Resources
114/159
Use MicroSoft
Working with Templates Internet
Template User’s Guide Explorer
115/159
Implement View
116/159
Business Requirements
117/159
MS Word Template
Enable
Macro’s to
see Add-Ins
section
Enable
•View Bookmarks
•View Hidden Text
118/159
OM – Toolbar Options
119/159
Demo
120/159
4. Gathering Requirements: use cases

intro
Use Case Basics
Use Case Definition
Industry :
Use Case ~ “A use case is the specification of a set of actions performed by
a system, which yields an observable result, that is, typically, of value for one
or more actors or other stakeholders of the system.”
(Source: UML: Superstructure v2.1, OMG Group)
OUM :
Use Case ~ “Captures and structures user requirements of a system. The
use case identifies all the major functions that users will be performing. The
Use Case Model helps the users and developers agree on how to use the
system. The use case specifies a sequence of actions, including variants and
extensions, that the system can perform. A use case answers a question and
must be related to an end user goal.”
122/159
Use Case Basics
Use Case
Practical definition:
A use case describes “What the business or system must do from an actor’s
point of view.”
Objectives:
• To help the business analyst to describe those business or system
functional requirements in an orderly and sequential manner.
• Organize functional requirements by packaging them together into coherent
“stories.”
Types:
• Business Use Case
• System Use Case
123/159
Use Case Basics
Use Case
Benefits:
• Focus attention on requirements, not design
• Help identify alternate and exception situations early in the lifecycle
• Useful for planning and managing a project
• Explain what the system will do
Improves the users view into what will be build before implementation
begins.
• Provide a strong foundation for test cases.
Since system use cases describe scenarios of actions between actors
and the system, they lead us directly into test cases.
124/159
Use Case Basics
Management’s Dilemma
“Analysts report that as many as 71% of
software projects that fail do so because of
poor requirements management, making it
the single biggest reason for project failure
—bigger than bad technology, missed
deadlines or change management
fiascoes.” Source: CIO Magazine, 11/15/2005
• Traditional textual requirements often leave out important

information.
• Use cases document the interactions between the user
and the business or system in a logical sequence.
126/159
Use Case Basics
Before Use Cases …
• A list of requirements or
features
– How did you know you had them all?
– How did you know you had them all
right?
– How did you know that you really
needed the ones you had?
– Which ones would you tackle first?
– How did you know if you had enough
time to deliver them all?
127/159
Use Case Basics
Provide a Context for Requirements
Business Stakeholders IT Stakeholders
Business Functional
Objectives
Use Cases
Requirements
128/159
Use Case Basics
A Use Case …
• Describes the behavior of a business or a system
• Describes how actors use the business or system to
accomplish goals
• Is expressed by sequences of exchanges between
the business or system and one or more actors
• Does not reveal the internal structure
of the business or system
• Bundles together a set of
related scenarios
UML icon for a use case
129/159
Use Case Basics
The Use Case Model Use Case Diagram
A Use Case Model includes

Order Skis
both a picture and text
• The picture is called the
Return Skis
Use Case Diagram
• The text is called the
Manage Profile
Use Case Details
Use Case Details: Order Skis

Actor Does System Does
1. The customer selects the skis 2. The system checks the
that he wishes to order. availability of…
130/159
Use Case Basics
More about Actors & Use Cases …
• Actors in a use case are something or someone which
exist outside the system
• Actors may be users, other systems, or hardware devices
• Use cases describe the behavior of the system from the
actor’s point of view.
• Use cases describe the interaction between actors and the
system as a sequence of steps.
Actor Behavior of the system
131/159
5. OUM on Application implementation

project
Business
Requirements
Develop
Use
Cases
Business
Processes Gaps
Install & Configure

Application
Key
Structure
Specify
Software Perform Approach supports
Definition Configuration
Fit/Gap
both:
• Installation &
Configuration
Integration Requirements • Development
of custom
Integrate components
Business Use Cases
Processes
133/159
Employing OUM on an Application Implementation Project
Key Concepts
– Role of Business Process Modeling
• Use for defining future process model and capturing functional
requirements
• Leverage Pre-Existing Business Process Models, if Available
– Role of Use Cases

• Use for Capturing Detailed Requirements for “GAPS”
• Can also be used for “Complex Configurations (e.g. Workflow,
DFFs, etc.)
– Functional Prototyping
• Used to prototype standard functionality as well as custom extension
functionality
• New terminology: CRP is now “Functional Prototype”
134/159
Employing OUM on an Application Implementation Project
Prototypes in OUM
• Three OUM prototypes
– Conceptual Prototype (IM.005 / RA.030) 1937 VW 30 “Functional Prototype”
• Mock-up prototype for user interactions or user interface
• Low fidelity – storyboards and wireframes
– Functional Prototype (IM.010 / RA.085)
• Higher fidelity, functional validation of user interface and associated
functionality
• May demonstrate elements defined in Conceptual Prototype
• Used for Conference Room Pilots (CRP’s)
• Not in Inception phase
– User Interface Standards Prototype (IM.085 / RA.095)
• Demonstrates “look and feel” of application being developed
• May contain example page layouts, generic screens, navigation
mechanisms, and data query styles
• Should include customer specific graphic elements and branding
135/159
Inception Phase Key Activities
OUM Application Implementation Top Level Flow
Gather Business Conduct Evaluate

Train Project Team Analyze and Design
Requirements Performance Test Production System
Gather Business Prepare Finalize Resolve Production

Develop Use Cases
Requirements Environments Documentation Problems
Gather Solution
Perform Fit/Gap Implement System Train Users Plan for Future
Requirements
Gather Supporting Specify Software Test Custom Support User

Requirements Configuration Components Acceptance Test
Specify Key Perform System

Develop Prototypes Convert Data
Structure Definition Test
Perform Systems
Validate Prototypes Go Production
Integration Test
LO LA IOC SP SO
136/159
Inception Phase Objectives
• Concurrence on Project’s Business Objectives

• Identify Stakeholders and Their Goals
• Confirm Project Scope
• Define & Prioritize High-Level Requirements
• Establish Project Team and Governance
• Identify and Mitigate Risks
• Validate Conceptual Prototype, if required
137/159
Inception Phase Templates: task outputs
• RD.011 - Future Business Model

• RD.130 - Architecture Description
• CV.010 - Data Acquisition and Conversion Requirements
• DO.010 - Documentation Requirements and Strategy
• RA.040 - Business Data Structure
• TR.020 - Project Team Learning Plan
138/159
Elaboration Phase Key Activities


Develop Use Cases
Gather Solution
Requirements


Perform Systems
Integration Test
LO LA IOC SP SO
139/159
Elaboration Phase Objectives
• Obtain a detailed understanding of the business processes

required to meet business objectives
• Prioritize, refine, and analyze requirements
• Formulate Use Cases for gaps
• Agree on the user involvement
• Establish a sound architectural foundation
• Develop the initial technical model and partition the
components to be developed
• Verify whether the project can move to the next phase
• Mitigate risks
140/159
Elaboration Phase Templates: task outputs
• RD.011 - Future Business Model

• RA.023 - Use Case Model
• RA.024 - Use Case Details
• CV.010 - Data Acquisition and Conversion Requirements
• TS.020 - Cutover Strategy
• TA.020 - Architecture Requirements and Strategy
• TA.070 - Initial Architecture and Application Mapping
• TA.080 - Backup and Recovery Strategy
• TE.018 - Test Data ??
• AN.010 - Business Requirement Mapping Form
141/159
Elaboration Phase Templates: task outputs
• DS.030 - Application Setup Document

• AN.100 - Analysis Specification
• DS.140 - Design Specification
• RA.085 - Validate Functional Prototype
• TE.020 - Unit Test Scenarios
• TE.020 - Unit Test Checklists
• TE.025 - System Test Scenarios
• TE.070 - System Test Result
• Part of the BT.070 - Project Management Plan
– DS.020 - Application Extension Strategy
– TE.010 - Testing Strategy
– DO.020 - Documentation Standards and Procedures
142/159
Construction Phase Key Activities


Develop Use Cases
Gather Solution
Requirements


Perform Systems
Integration Test
LO LA IOC SP SO
143/159
Construction Phase Objectives
• Detail the remaining use cases and refine Analysis and

Design Models
• Obtain refinements to requirements
• Iteratively, produce a physical database, integrate
developed or reused components, and configure product
components, to produce an integrated system
• Test custom components, the entire integrated application
system (i.e. COTS + extensions), and its integration with
3rd party and legacy systems.
144/159
Construction Phase Templates: task outputs
• RA.023 - Use Case Model

• RA.024 - Use Case Details
• AN.100 - Analysis Specification
• DS.140 - Design Specification
• DS.030 - Application Setup Document
• IM.090 - Installation Instructions
• TE.020 - Unit Test Scenarios
• TE.020 - Unit Test Checklists
• TE.025 - System Test Scenarios
• TE.070 - System Test Result
145/159
Construction Phase Templates: task outputs
• TE.090 - Integration Test Scenarios

• PT.070 - Performance Test Scripts and Programs
• TA.160 - System Capacity Plan
• TS.020 - Cutover Strategy
• TA.120 - Operational Test Results
• CV.027 - Data Mapping
• CV.040 - Conversion Component Design
146/159
Transition Phase Key Activities


Develop Use Cases
Gather Solution
Requirements


Perform Systems
Integration Test
LO LA IOC SP SO
147/159
Transition Phase Overview
– Transition Phase Objectives:

• Support the client during the Acceptance Test and handle
issues that appear during the Acceptance Test.
• Validate that the system meets the requirements for
Production, to the satisfaction of the stakeholders.
• Prepare the Production Environment.
• Convert data from existing systems.
• Establish the maintenance environment required for
supporting and managing the system.
• Gain acceptance
148/159
Transition Phase Key Activities


Develop Use Cases
Gather Solution
Requirements


Perform Systems
Integration Test
LO LA IOC SP SO
149/159
Production Phase Overview
– Production Phase Objectives:

• Fulfill obligations during the warranty period
• Monitor the system performance and solve any problems
• Log problems and make corrections
• Provide agreed upon level of user support
• Deliver a plan for continued management and support of
the system
• Assess the success of the solution
• Develop an Enhancement Plan
150/159
6. Material available to partners

Material Available to partners
• Partner network link:

• http://www.oracle.com/partners/secure/education/024
502.htm
152/159
OUM Training Program
Training and Accreditation Program
Goal: Gradual learning from simple to more complex
• Level 1 – Overview and Awareness
• Level 2 – Focus Area1 Specific Overview
• Level 2 – Use Case Overview
• Level 2 – Business Process Overview
• Level 2E – Estimating Overview
• Level 3 – Gathering Requirements using OUM
• Level 3 – Analysis and Design
• Level 4D
– Discipline2 or Service Offering3 Specific Delivery Readiness
• Level 4E
– Business Requirements Questionnaire Estimating Readiness
• Level 5 – Advanced Delivery Readiness
153/159
7. Key take aways

Key take aways
• Combines solution driven and requirements driven
• ABF is embedded in OUM
• Fit For Purpose
• Flexible
• Open standards based (UML): fast learning possible
• Includes Envision
• Enables expanding the Oracle implementation footprint: both
COTS as well as Technology products (e.g. AIA)
• Supports implementation of end to end Oracle Stack
• Fusion Ready
• Functional Prototyping is more flexible than conducting CRP
• Risk focused (risk mitigation thru iterative and incremental
approach)
155/159
8. Open Discussion
Q&
OUM Training for Partner Dubai
A
12 - May - 2011 157/159

OUM - Level 1 &amp; 2 Certification Content

Uploaded by

Copyright:

Available Formats

You might also like

OUM - Level 1 &amp; 2 Certification Content

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

OUM - Level 1 &amp; 2 Certification Content

Uploaded by

Copyright:

Available Formats

<Insert Picture Here>

OUM Level 1 & 2 Training for Partners

Compass Standard View CDM FT RBGU – Retek et al

Siebel Analytics CDM Classic

CGBU - Portal Xcellerate

Siebel Results Roadmap Data Warehouse Method FT

Oracle® Unified Method (OUM)

A single, integrated method, to support the

“The vision for the Oracle® Unified Method is to support

• Common language across

2. Key Concepts of OUM

OUM Training for Partner Dubai 12 - May - 2011

– Do not serve the method; make it serve you.

– OUM may be scaled in a number of dimensions or better

3. A Deep Dive into OUM

Envision – enterprise level processes Implement

checkpoint against project goals, and

Phases are temporal groupings

Inception Elaboration Construction Transition Production

• Inception – Lifecycle Objectives Milestone (LO)

subject matter, required

OUM Training for Partner Dubai 12 - May - 2011 29/159

may be from different OUM

forms the basis for a work

• The best-known and extensively

• The Baseline Architecture is a key work product of Elaboration

– Incremental is creating something one piece at a time

• Releases act as a forcing function that drives the

Business Requirements Analysis Design Implementation Test

Business Requirements Analysis Design Implementation Test

Business Requirements Analysis Design Implementation Test

• UML is a general-purpose modeling language that

• Accelerate new practitioners’ understanding of OUM

1. Start from the core set of tasks.

Balancing Agility and Discipline: A Guide for the Perplexed

by Barry Boehm and Richard Turner

“Fine Tune functionality, performance & quality”

1. Understand OUM and the Unified Process (UP)

Balancing Agility and Discipline: A Guide for the Perplexed

• OUM is distributed as a Method Pack

4. Gathering Requirements: use cases

• Traditional textual requirements often leave out important

Business Stakeholders IT Stakeholders

A Use Case Model includes

Use Case Details: Order Skis

Actor Behavior of the system

5. OUM on Application implementation

Install & Configure

– Role of Use Cases

Gather Business Conduct Evaluate

Gather Business Prepare Finalize Resolve Production

Gather Supporting Specify Software Test Custom Support User

Specify Key Perform System

• Concurrence on Project’s Business Objectives

• RD.011 - Future Business Model

Gather Business Conduct Evaluate

Gather Business Prepare Finalize Resolve Production

Gather Supporting Specify Software Test Custom Support User

Specify Key Perform System

OUM - Level 1 & 2 Certification Content

OUM - Level 1 & 2 Certification Content

OUM - Level 1 & 2 Certification Content