OUM For Partners Dubai

<Insert Picture Here>
OUM Training for Partners Francis Moeris Noman Khalid

May 12 2011
OUM Training for Partner Dubai 12 - May - 2011
Agenda
1. 2. 3. 4. 5. 6. 7. 8. Why OUM ? Key Concepts of OUM A Deep Dive into OUM Gathering Requirements: use cases intro OUM on Application implementation project Material Available to Partners Key Take Aways Open Discussion
OUM Training for Partner Dubai
12 - May - 2011
2/159
1. Why OUM ?
Why a method is necessary?
12 - May - 2011
4/159
EasiPath Migration Method

Compass Standard View
Compass Upgrade View

RBGU Retek et al
CDM FT
Siebel Analytics
CGBU - Portal
CDM Classic
Xcellerate
AIM Foundation
Siebel Results Roadmap AIM for Business Flows Stellent Revenue
OTM G-Log
Data Warehouse Method FT Compass Accelerated View Agile Hyperion
5/159
Tangosol
12 - May - 2011
Basics OUM*
Oracle Unified Method (OUM) A single, integrated method, to support the entire Oracle ecosystem, across the complete suite of Oracle products
12 - May - 2011
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.
12 - May - 2011
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
12 - May - 2011
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
12 - May - 2011
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.
12 - May - 2011
10/159
2. Key Concepts of OUM

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 - May - 2011
12/159
OUM is Flexible and Scalable*

Do not serve the method; make it serve you.
If you are not going to need it, dont do it.
12 - May - 2011
13/159
OUM is Flexible and Scalable*

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
12 - May - 2011
14/159
OUM is Flexible and Scalable 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
12 - May - 2011
15/159
Basics Comprehensive Toolkit*

Templates
Guidelines
Focus areas, views, phases, activities, processes, and tasks Create high quality work products
Tailored Workplans
Accelerated starting point
Overview Material
Approach and standards
Supplemental Guidance
Products, tools, techniques, and technologies
Easy Access
Hosted or installed locally
16/159
OUM Structure Views
12 - May - 2011
17/159
OUM Structure Supplemental Guidance

Supplemental Guides
White Papers
Review Checklists and Guidelines Viewlets
Cross References
Helpful Discipline/Industry/View Resources and Samples
12 - May - 2011
18/159
OUM Principles*
Business Process & Use Case-Driven
OUM
Flexible & Scalable
Envision Implement
Iterative & Incremental
Manage
Risk-Focused
Architecture-Centric
12 - May - 2011
19/159
3. A Deep Dive into OUM

OUM Focus Area Views:*

Envision enterprise level processes
Enterprise Business Analysis Enterprise Architecture IT Portfolio Management IT Governance Adoption and Learning
Implement
Supports software engineering and implementation of Oracle application and technology products Business Process and Use Case-driven Iterative and Incremental
OUM
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)
12 - May - 2011
21/159
Implement Focus Area*
12 - May - 2011
22/159
Implement Focus Area Structure* AIM Methodology
6 Phases 11 Processes
0 Iterations
12 - May - 2011
23/159
Implement Focus Area Structure ABF Methodology*
5 Phases 9 Processes
0 Iterations
12 - May - 2011
24/159
Key Terms & Concepts*

Phase Lifecycle Milestone Process Activity
Task
Dependency Work Product
12 - May - 2011
25/159
Key Terms & Concepts: Phase*

Phases are chronological grouping of tasks in an approach. Services are delivered by phase in order to reduce project risk. Each phase allows a checkpoint against project goals, and measurement against quality criteria to be made.

Phases
Inception Elaboration
Construction
Transition
Production
Phases are temporal groupings Phases cut vertically through project activities Are natural points to establish milestones for progress checkpoint
12 - May - 2011
26/159
Key Terms & Concepts: Lifecycle Milestones*

Unified Process Lifecycle Milestones are major synchronization points that occur at phase boundaries.
Phases
Construction
Transition
Production
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
12 - May - 2011
Major Milestones
LO
LA
IOC
SP
SO
27/159
Implement Lifecycle Major Milestones*

Inception Elaboration Construction Transition Production
LO
LA
IOC
SP
SO
Inception
Elaboration Construction Transition Production
Lifecycle Objectives Milestone (LO)

Lifecycle Architecture Milestone (LA) Initial Operational Capability Milestone (IOC) System Production Milestone (SP) Sign-Off Milestone (SO)
12 - May - 2011
28/159
Key Terms & Concepts: Process*

A process is a discipline or sub-project that defines a set of tasks related by subject matter, required skills and common Processes dependencies. Examples: Business Requirements Data Acquisition & Conversion Operations & Support
Inception
Elaboration
Construction
Transition
Production
12 - May - 2011
29/159
Key Terms & Concepts: Activity*

An Activity is a set of tasks related either by topic, dependencies, data, common skills/roles, or work products. The tasks in an activity 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
Activities
Construction
Transition
Production
30/159
Key Terms & Concepts: Task*

A task is a unit of work that is done in delivering a service. A task is the smallest traceable item on a project workplan, and forms the basis for a work breakdown structure.
Tasks
Construction
Transition
Production
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.
12 - May - 2011
31/159
Key Terms & Concepts: Dependency

A Dependency is an indication that one task 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
Dependencies
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 document May or may not be a deliverable
Application Code Working Software Knowledg e Work Products Model
12 - May - 2011
34/159
Agenda of deep dive*

OUM Approach
Unified Process
Business Process Driven Use Case Driven Architecture Centric Iterative Incremental Releases Risk Focussed
Implement Focus Area Structure

Phases Milestones Processes
Key Concepts & Principles

Key Terms Key Concepts & Principles
OUM Implement Components

Focus Areas
Manage Focus Area Envision Focus Area Implement Focus Area
Applying OUM
OUM Key to Success Concepts Balancing Agility and Discipline
OUM Views
Focus Area Views Disciplinne Views Service Offering Views
Working with Templates

Demo Navigation Practice
12 - May - 2011
35/159
Agenda of deep dive

OUM Approach
Unified Process



Focus Areas
Applying OUM
OUM Views

12 - May - 2011
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 documented refinement of the Unified Process is the Rational Unified Process or RUP. ~ Wikipedia.org
Unified Process
37/159
OUM Approach* UP Characteristics

Use Case-Driven
Architecture-Centric Risk-Focused Iterative and Incremental
Unified Process
12 - May - 2011
38/159
OUM Approach OUM expands on UP Characteristics*

Use Case-Driven
Architecture-Centric Risk-Focused Iterative and Incremental Business Process and Use Case-Driven Fit-for-Purpose
12 - May - 2011
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
12 - May - 2011
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
12 - May - 2011
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
Architecture-Centric
The systems 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
12 - May - 2011
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.
12 - May - 2011
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.
12 - May - 2011
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.
12 - May - 2011
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 Requirements Analysis Analysis Design Implementation Test
Business Requirements
Requirements Analysis
Analysis
Design
Implementation
Test
Requirements Analysis
Analysis
Design
Implementation
Test
12 - May - 2011
47/159
Iterations Can Be Considered Mini-Waterfalls*

2 1 2 2 2 1 1 2 2 3 3 3 3 3 3 4 4 4 4 4 4
Construction
5 5 5 5 5 5 6 6 6 6 6 6
Transition
Production
RD
RA AN DS IM TE TS PS
7 7
8
8 9
Iterations Milestones
time
LO
LA
Releases
IOC
SP
SO
Legend RD - Business Requirements DS - Design - Requirements Analysis AN - Analysis

RA
TS - Transition
- Implementation PS - Operations & Support TE - Test 1 - Iteration Number

IM
12 - May - 2011
48/159
OUM Approach* Concepts of Iterations & Increments
12 - May - 2011
49/159
OUM Approach* Concepts of Iterations & Increments
12 - May - 2011
50/159
OUM Approach* Concepts of Iterations & Increments group by priority

Increment 1 Increment 2 Increment 3
+ CR-s Increment 1
+ CR-s Increment 2
12 - May - 2011
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
12 - May - 2011
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.
12 - May - 2011
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
12 - May - 2011
54/159
OUM Approach * Application Approach

OUMs 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 Oracles 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)
12 - May - 2011
55/159
OUM Approach * Oracle Unified Method Approach

OUMs 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
12 - May - 2011
56/159
Agenda of deep dive

OUM Approach
Unified Process



Focus Areas
Applying OUM
OUM Views

12 - May - 2011
57/159
OUM Implement Components OUM Focus Area

Envision enterprise-level processes
Envision Roadmap Enterprise Business Analysis Organizational Change Management Enterprise Architecture IT Portfolio Management IT Governance
Implement
Supports software engineering and implementation of Oracle application and technology products Business Process and Use Case-driven Iterative and Incremental Architecture-centric Standards-based Balanced and Flexible
OUM
Envision
Implement
Manage Manage
Promotes disciplined management of information technology Projects and Programs Aligns with Project Management Institute (PMI)
12 - May - 2011
58/159
OUM Implement Components Manage Focus Area
12 - May - 2011
59/159
OUM Implement Components Envision Focus Area
Slide 60
60/159
OUM Implement Components Implement Focus Area
12 - May - 2011
61/159
OUM Implement Components Implement Focus Area

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

12 - May - 2011
62/159
OUM Implement Components* 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
12 - May - 2011
63/159
OUM Implement Components* Scalable: Build Up - Dont 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 by Barry Boehm and Richard Turner
12 - May - 2011
64/159
OUM Implement Components* 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.
12 - May - 2011
65/159
OUM Implement Components Core Workflow
12 - May - 2011
66/159
OUM Implement Components* Core Workflow Focus thru project lifecycle
12 - May - 2011
67/159
OUM Implement Components OUM Views

A View presents a predefined subset of the OUM materials.
<
<
<
12 - May - 2011
68/159
OUM Implement Components Focus Area Views

Each Focus Area can be accessed in OUM through its applicable Focus Area View.
12 - May - 2011
69/159
OUM Implement Components 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).
12 - May - 2011
70/159
OUM Implement Components* 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).
12 - May - 2011
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).
12 - May - 2011
72/159
Agenda of deep dive

OUM Approach
Unified Process



Focus Areas
Applying OUM
OUM Views

12 - May - 2011
73/159
Implement Focus Area Structure Inception Phase

Inception
Elaboration Construction Transition Production
Key Outputs: Requirements Conceptual Prototype Technical Architecture Requirements Performance Management Requirements Skilled Project Team Executive Execution Plan / Governance Rules
Activities: 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 / Communication Campaign
12 - May - 2011
74/159
Implement Focus Area Structure 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
12 - May - 2011
75/159

Lifecycle Objective Milestone - Objectives
Inception
Lifecycle Objective Milestone
Confirm:
Business objectives Goals Requirements (Use Cases) Risks
Elaboration
Lifecycle Architecture Milestone
Construction
Initial Operational Capability Milestone
Transition
System in Production Milestone
Update schedule and cost estimates Complete Conceptual Prototype Is it feasible to proceed?
Production
Sign-Off Milestone
12 - May - 2011
76/159
Implement Focus Area Structure Elaboration Phase

Inception
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 Deploy Change Management Roadmap / Key Outputs: Communication Campaign Requirements Specifications Functional & User Interface Standards Prototypes Architecture Description Performance Management Requirements Analysis and Design Models and Database Design Testing Strategy, Test Scripts and Programs Design
Elaboration Construction
Transition Production
12 - May - 2011
77/159
Implement Focus Area Structure 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
12 - May - 2011
78/159
Lifecycle Architecture Milestone Objectives

Stable architecture? Application Inception Technical Lifecycle Objective Milestone Data Elaboration Executable code showing that Lifecycle Architecture architectural risks have been Milestone mitigated? Construction Initial Operational Capability Construction Phase plan detailed Milestone and accurate? Transition Implementation team ready?
System in Production Milestone Sign-Off Milestone
Production
Can we commit resources to begin implementation?
12 - May - 2011
79/159
Implement Focus Area Structure Construction Phase

Construction Transition
Production
Key Outputs: Architecture Description System-Tested Applications Integration-Tested System Transition and Contingency Plan
Activities: 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 Deploy Change Management Roadmap / Communication Campaign Conduct Job Impact Analysis Conduct Managers Alignment Workshop Design and Build End-User Training Train End Users
12 - May - 2011
80/159
Implement Focus Area Structure 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, product a physical database, integrate developed or reused components, and configure product components, to produce an integrated system
12 - May - 2011
81/159
Initial Operational Capability Milestone Objectives

Inception
Elaboration
Beta release stable? Stakeholders ready for Transition? Ready for the User Acceptance Test ?
Construction
Transition
Production
Sign-Off Milestone
12 - May - 2011
82/159
Implement Focus Area Structure Transition Phase

Inception Elaboration Construction
Transition
Production
Activities: 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
12 - May - 2011
83/159
Transition Phase Objectives

Fine Tune functionality, performance & quality Go Live
Objectives
1. 2. 3. 4. 5. 6. Gain acceptance of the project Support the client during the Acceptance Test Validate that the system meets the requirements for Production Prepare the Production Environment Convert data from existing systems Establish the maintenance environment required for support
12 - May - 2011
84/159
System in Production Milestone Objectives

Inception
Elaboration
Construction
Go Live!
Transition
Stakeholders satisfied with the project?

Package reusable components Report estimate versus actual to improve OUM estimates
Production
Sign-Off Milestone
12 - May - 2011
85/159
Implement Focus Area Structure Production Phase

Inception Elaboration Construction Transition
Production
Activities: Manage Production System Performance Evaluate Production System Resolve Production Problems Upgrade System Deploy Change Management Roadmap / 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
12 - May - 2011
86/159
Production Phase Objectives

Obtain Sign-Off Close Contract
Objectives
1. 2. 3. 4. 5. 6. 7. Fulfill obligations during the warranty period Monitor the system performance and solve any problems Log problems and make corrections Provide agreed on level of user support Deliver a plan for continuing management and support Assess the success of the solution Develop and Enhancement Plan
12 - May - 2011
87/159
Sign-Off Milestone Objectives

Inception
Elaboration
Construction
Transition
Close out the contractual agreements Release staff and physical resources
Production
Sign-Off Milestone
Preserve intellectual property

12 - May - 2011
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
12 - May - 2011
89/159
Agenda of deep dive

OUM Approach
Unified Process



Focus Areas
Applying OUM
OUM Views

12 - May - 2011
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.
12 - May - 2011
91/159
Key Concepts and Principles 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.
12 - May - 2011
92/159
Key Concepts and Principles 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.
12 - May - 2011
93/159
Key Concepts and Principles 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
12 - May - 2011
94/159
Key Concepts and Principles 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.
12 - May - 2011
95/159
Key Concepts and Principles 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
Key Concepts and Principles 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.
12 - May - 2011
97/159
Agenda of deep dive

OUM Approach
Unified Process



Focus Areas
Applying OUM
OUM Views

12 - May - 2011
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
12 - May - 2011
99/159
Applying OUM Implement Focus Area Key to Success Concept #1

Understand OUM and the Unified Process (UP). Business Process and Use Case-Driven Architecture-Centric Iterative and Incremental Risk-Focused Fit-for-Purpose
12 - May - 2011
100/159

Do not serve the method; make it serve you.
If you are not going to need it, dont do it.
12 - May - 2011
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
12 - May - 2011
102/159

The outputs of tasks are called work products.
12 - May - 2011
103/159

Work products (or artifacts) need not be documents.
Tasks should be executed only to the level that is fit for purpose.
12 - May - 2011
104/159

Focus on understanding the most significant risks and requirements.
12 - May - 2011
105/159
Applying OUM Implement Focus Area 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
12 - May - 2011
106/159
Applying OUM Implement Focus Area 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
12 - May - 2011
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.
12 - May - 2011
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 Organizations experience with Agile
etc.
12 - May - 2011
109/159
Agenda of deep dive

OUM Approach
Unified Process



Focus Areas
Applying OUM
OUM Views

12 - May - 2011
110/159
OUM Method Pack

OUM is distributed as a Method Pack
Method Packs installable on users desktop and may be hosted

Simple HTML and MS Office Documents Browser Independent Packaged using commercial installer
12 - May - 2011
111/159
MyDesktop
Providing Access to:
OUM Legacy Methods including: AIM, ABF, EMM, DWM FT, PJM
12 - May - 2011
112/159

OUM Home Page
12 - May - 2011
113/159

Resources
12 - May - 2011
114/159

Template Users Guide
Use MicroSoft Internet Explorer
12 - May - 2011
115/159

Implement View
12 - May - 2011
116/159

12 - May - 2011
117/159

MS Word Template
Enable Macros to see Add-Ins section
Enable View Bookmarks View Hidden Text
12 - May - 2011
118/159

OM Toolbar Options
12 - May - 2011
119/159

Demo
12 - May - 2011
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.
12 - May - 2011
122/159
Use Case Basics Use Case

Practical definition:
A use case describes What the business or system must do from an actors 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
12 - May - 2011
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.
12 - May - 2011
124/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?
12 - May - 2011
127/159
Use Case Basics Provide a Context for Requirements

Business Stakeholders IT Stakeholders
Business Objectives
Use Cases
Functional Requirements
12 - May - 2011
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
12 - May - 2011
129/159
Use Case Basics The Use Case Model

A Use Case Model includes both a picture and text The picture is called the Use Case Diagram The text is called the Use Case Details
Use Case Diagram
Order Skis Return Skis Manage Profile
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
12 - May - 2011
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 actors point of view.
Use cases describe the interaction between actors and the system as a sequence of steps.
Actor
Behavior of the system
12 - May - 2011
131/159
5. OUM on Application implementation project

Develop
Use Cases
Business Processes
Gaps
Install & Configure

Key Structure Definition Specify Software Configuration
Perform Fit/Gap
Application Approach supports both: Installation & Configuration
Integration Requirements
Integrate
Business Processes
Development of custom components
Use Cases
12 - May - 2011
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 (CRPs) 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
12 - May - 2011
135/159
Inception Phase Key Activities

OUM Application Implementation Top Level Flow
Gather Business Requirements
Construction
Transition
Conduct Performance Test
Production
Evaluate Production System
Train Project Team
Analyze and Design
Develop Use Cases
Prepare Environments
Finalize Documentation
Resolve Production Problems
Gather Solution Requirements
Perform Fit/Gap
Implement System
Train Users
Plan for Future
Gather Supporting Requirements
Specify Software Configuration
Test Custom Components
Support User Acceptance Test
Specify Key Structure Definition
Develop Prototypes
Perform System Test
Convert Data
Validate Prototypes
Perform Systems Integration Test
Go Production
LO
LA
IOC
SP
SO
12 - May - 2011
136/159

Inception Phase Objectives
Concurrence on Projects 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
12 - May - 2011
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
12 - May - 2011
138/159
Elaboration Phase Key Activities

Construction
Transition
Production
Train Project Team
Analyze and Design
Develop Use Cases
Perform Fit/Gap
Implement System
Train Users
Plan for Future
Develop Prototypes
Perform System Test
Convert Data
Validate Prototypes
Go Production
LO
LA
IOC
SP
SO
12 - May - 2011
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
12 - May - 2011
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
12 - May - 2011
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
12 - May - 2011
142/159
Construction Phase Key Activities

Construction
Transition
Production
Train Project Team
Analyze and Design
Develop Use Cases
Perform Fit/Gap
Implement System
Train Users
Plan for Future
Develop Prototypes
Perform System Test
Convert Data
Validate Prototypes
Go Production
LO
LA
IOC
SP
SO
12 - May - 2011
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.
12 - May - 2011
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
12 - May - 2011
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
12 - May - 2011
146/159
Transition Phase Key Activities

Construction
Transition
Production
Train Project Team
Analyze and Design
Develop Use Cases
Perform Fit/Gap
Implement System
Train Users
Plan for Future
Develop Prototypes
Perform System Test
Convert Data
Validate Prototypes
Go Production
LO
LA
IOC
SP
SO
12 - May - 2011
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
12 - May - 2011
148/159
Transition Phase Key Activities

Construction
Transition
Production
Train Project Team
Analyze and Design
Develop Use Cases
Perform Fit/Gap
Implement System
Train Users
Plan for Future
Develop Prototypes
Perform System Test
Convert Data
Validate Prototypes
Go Production
LO
LA
IOC
SP
SO
12 - May - 2011
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
12 - May - 2011
150/159
6. Material available to partners

Material Available to partners

Partner network link: http://www.oracle.com/partners/secure/education/024 502.htm
12 - May - 2011
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)
12 - May - 2012
155/159
8. Open Discussion
12 - May - 2011
157/159
12 - May - 2011
158/159
12 - May - 2011
159/159

OUM For Partners Dubai

Uploaded by

Document Information

Original Title

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 For Partners Dubai

Uploaded by

Copyright:

Available Formats

<Insert Picture Here>

OUM Training for Partners Francis Moeris Noman Khalid

OUM Training for Partner Dubai

<Insert Picture Here>

Why a method is necessary?

OUM Training for Partner Dubai

EasiPath Migration Method

Compass Upgrade View

OUM Training for Partner Dubai

Oracle Unified Method Vision*

OUM Training for Partner Dubai

Basics* Oracle Unified Method Goals

Fusion Technology Foundation

OUM Training for Partner Dubai

OUM Training for Partner Dubai

OUM Training for Partner Dubai

<Insert Picture Here>

2. Key Concepts of OUM

OUM Training for Partner Dubai

OUM is Flexible and Scalable*

If you are not going to need it, dont do it.

OUM Training for Partner Dubai

OUM is Flexible and Scalable*

Eliminating unnecessary tasks from the workplan

OUM Training for Partner Dubai

OUM is Flexible and Scalable Flexible and Scalable: Fit-for-Purpose

OUM Training for Partner Dubai

Basics Comprehensive Toolkit*

OUM Structure Views

OUM Training for Partner Dubai

OUM Structure Supplemental Guidance

Helpful Discipline/Industry/View Resources and Samples

OUM Training for Partner Dubai

Flexible & Scalable

Iterative & Incremental

OUM Training for Partner Dubai

<Insert Picture Here>

3. A Deep Dive into OUM

OUM Focus Area Views:*

OUM Training for Partner Dubai

Implement Focus Area*

OUM Training for Partner Dubai

Implement Focus Area Structure* AIM Methodology

OUM Training for Partner Dubai

Implement Focus Area Structure ABF Methodology*

OUM Training for Partner Dubai

Key Terms & Concepts*

OUM Training for Partner Dubai

Key Terms & Concepts: Phase*

OUM Training for Partner Dubai

Key Terms & Concepts: Lifecycle Milestones*

OUM Training for Partner Dubai

Implement Lifecycle Major Milestones*

Lifecycle Objectives Milestone (LO)

OUM Training for Partner Dubai

Key Terms & Concepts: Process*

OUM Training for Partner Dubai

Key Terms & Concepts: Activity*

Key Terms & Concepts: Task*

Tasks may have one or more outcomes/outputs:

Creation or update of a document

OUM Training for Partner Dubai

Key Terms & Concepts: Dependency