Transcript of 2 - Module - OUM Principles
OUM Level 2 Overview CourseModule: OUM Principles
*
Welcome to the OUM Principles module of the Oracle Unified Method
Implement Focus Area Overview Course.
*
Learning Objectives
OUM Principles
By the end of this module, you should be able to:
Describe the 5 main principles of the Oracle® Unified Method
(OUM).
Understand how these principles have influenced OUM
development.
© 2008, 2010 Oracle and/or its affiliates. All rights
reserved.
© 2008, 2010 Oracle and/or its affiliates. All rights
reserved.
*
By the end of this module, you should be able to:
Describe the 5 main principles of OUM.
*
Business Process
& Use Case-Driven
*
You will remember from the OUM Level 1 training, that the Oracle
Unified Method (OUM) is built on five main principles. We have
derived these principles from several sources including the Unified
Process, the Dynamic Systems Development Method, and Oracle's
legacy methods:
The first principles is Business Process and Use Case-Driven – This
means that business process models and use cases are used as the
primary artifacts for establishing the desired behavior of a system
and for communicating this behavior among the stakeholders.
The next principle is Iterative and Incremental – This means that
the development or implementation of a software system is done
incrementally through repetition of a series of tasks. The intent
is to first define the system broadly, at a high-level, and then
refine the definition of the system by adding detail in subsequent
iterations.
Next is Architecture-Centric – This means that a well-defined
architecture is used as a primary artifact for conceptualizing,
constructing, managing and evolving the system that is being
implemented.
The next principle is Risk-Focused – A key focus of each iteration
in OUM is to attack and reduce the most significant project risks.
This helps ensure that the project team addresses the most critical
risks as early as possible in the project lifecycle.
The final principle is Flexible & Scalable – OUM is designed to
support a broad range of project types. As such, it must be
scalable and adaptable. The appropriate point of balance for a
given project will vary based on a number of project risk and scale
factors. The method has been developed with the intent that the
plan for a given project be “built up” from a core set of
activities to arrive at an appropriate level of discipline.
Building up a plan is preferred over tailoring down, as it tends to
produce a more appropriate level of discipline. Furthermore, OUM
can be tailored or made specific to the project and customers
needs, and therefore is fit-for-purpose.
*
Business Process and Use Case-Driven
Business processes and use cases are the primary mechanisms for
gathering functional requirements
Requirements are documented through
© 2008, 2010 Oracle and/or its affiliates. All rights
reserved.
© 2008, 2010 Oracle and/or its affiliates. All rights
reserved.
*
As we have already said, being business process and use-case driven
means that business processes and use cases are used as the primary
artifacts for establishing the desired behavior of the system and
for communicating this behavior among the stakeholders.
[click]
*
Business Process
A series of linked tasks designed to produce a product, service or
major business deliverable
A collection of inter-related tasks which solve a particular
issue
© 2008, 2010 Oracle and/or its affiliates. All rights
reserved.
Manage Logistics and Warehousing
© 2008, 2010 Oracle and/or its affiliates. All rights
reserved.
Let’s focus on the term “Business Process Driven.”
While I suspect that many of us have already had experience with
business processes, it’s probably useful to define the term
“business process” so that everyone is on the same page.
A business process is series of linked tasks that are designed to
produce a product, service or major business deliverable. You can
also think of a business process as a collection of inter-related
tasks that solve a particular issue
*
*
Also used to understand how software supports a business
process
Software solutions are frequently documented using process
models
© 2008, 2010 Oracle and/or its affiliates. All rights
reserved.
© 2008, 2010 Oracle and/or its affiliates. All rights
reserved.
Business process modeling is a graphical modeling technique used to
document and understand the business processes within an
organization. A large number of pre-defined business process models
exist that describe best practice horizontal or industry-specific
business processes.
[click]
Business process models may also be used to understand how a given
software product or information technology platform supports a
required business process.
[click]
Finally, pre-defined software solutions are frequently documented
through a set of business process models. The are not purely
“business process models,” but are really a process model that has
been annotated to show how technology will be used to automate a
business process. These solutions typically describe how the user –
or actor – interacts with a system or how a system interacts with
another system to support the business process.
*
*
Links requirements to Design and Test
Bridges gap between business modeling, business processes, and
software system functionality
Identify implicit or unstated requirements
Enable traceability of requirements through testing
© 2008, 2010 Oracle and/or its affiliates. All rights
reserved.
UML icon for a use case
© 2008, 2010 Oracle and/or its affiliates. All rights
reserved.
*
Now let’s focus on the term, “Use Case Driven.”
Use cases have traditionally been used as a way to define
functional requirements for software systems. More recently, they
have also been used as a tool on which to model user tasks and
interactions to improve system usability. In the hands of system
and application designers, use cases can serve as a powerful tool
for brainstorming workflows and bridging the gaps between design
and development.
[click]
For example, Use Cases may be used to provide a consistent
mechanism to link system requirements to the design of the system
and to testing and validation
[click]
Use cases are an effective means for bridging the gap between
business modeling, business processes, and software system
functionality. Use cases also provide a consistent thread through
OUM and help to amplify and consolidate many of OUM’s other
benefits
[click]
Use case are also effective tools for identifying implicit or
unstated requirements – that is items that are not typically shown
on a process model or as part of a list of textual
requirements.
[click]
As a project progresses, where the need to develop use cases
arises, use cases are analyzed and the system is designed and
implemented to meet the requirements captured in the use cases. The
implemented components are tested to verify that they provide the
business benefit described by the use cases. All of the models -
the Use Case Model - Architecture – Analysis Model – Design Model
–Implementation Model – and Testing Models are related to each
other through trace dependencies.
Also, as part of OUM’s iterative approach, use cases are
prioritized to support the definition of an architecture before
committing too much resource and to first deliver the components
that are of the highest value to the enterprise
*
Describes how actors use business or system to accomplish
goals
Is expressed by sequences of exchanges
Does not reveal internal structure
Bundles together a set of related scenarios
Use Case Details
Actor Does
System Does
The customer selects the skis that he wishes to order.
The system checks the availability of…
Use Case Diagram
Customer
Here are some of the most important characteristics of a use
case.
[click]
A use case describes the behavior of a business or a system
[click]
A use case describes how users or “actors” use the business or
system to accomplish goals.
[click]
A use case is expressed by sequences of exchanges between the
business or system and one or more actors.
[click]
A use case does not reveal the internal structure of the business
or system
[click]
And a use case bundles together a set of related scenarios
[click]
One of the primary motivations for driving a project with use cases
is that a use case can be used as the starting point for many of
the other important work products that are part of a system
development project. Some examples are –
User Guides
System Management Guides
Narratives for Prototypes
Add learning check point
*
*
Break down phases into iterations.
Allow for more frequent checkpoints and tollgates.
Overall Project
© 2008, 2010 Oracle and/or its affiliates. All rights
reserved.
Now let’s talk about Iterative and Incremental. OUM, like the
Unified Process, employs an iterative and incremental approach to
implementing software systems.
*
*
*
*
The result of an iteration is an increment.
A release does not necessarily include a software build
© 2008, 2010 Oracle and/or its affiliates. All rights
reserved.
© 2008, 2010 Oracle and/or its affiliates. All rights
reserved.
*
Now that we have defined the terms: Iteration, Increment and
Release, let’s discuss the use and practice of these concepts
within OUM.
[click]
OUM, like the Unified Process (UP) from which it has been derived,
employs an iterative and incremental approach to implementing
software systems. In the Unified Process, and therefore in
OUM,
[click]
the result of an iteration is an increment. I’ll say that again,
the result of an iteration is an increment.
It is important to note that the OUM definition of an increment,
while consistent with the Unified Process, differs from the
definition used in Oracle’s Custom Development Method Fast Track
(CDM FT), Oracle’s Data Warehouse Method Fast Track (DWM FT), or
any Dynamic Systems Development Method (DSDM) based approach.
In OUM, the terms iteration and increment are defined in a way
that is consistent with these concepts. That is, an increment is
the difference between the release of one iteration and the release
of the next 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.
[click]
At the end of each iteration, the active set of work products or
artifacts are released to form the current baseline. A release is
therefore defined as a relatively complete and consistent set of
artifacts – possibly, but not necessarily including a
software build – delivered to an internal or external user. An
internal release is used only by the development organization, as
part of a milestone, or for a demonstration to users or customers.
An external release is delivered to the end users.
*
Learning Checkpoint
OUM Principles
*
*
*
Now that you understand the terms, Lets walkthrough the concept of
Iterative and what it means in OUM.
Here are 3 iterations through the various OUM processes. As
indicated by the amount and depth of shading of each box, you can
see how the focus and the volume of the work changes for each
process as we progress through each of the iterations.
Often in traditional “waterfall” project, there is an integration
'pile-up' late in Implementation when, for the first time, the
product is built and testing begins. Problems which have remained
hidden throughout Analysis, Design, and Implementation come boiling
to the surface. Frequently, the project grinds to a halt as a
lengthy bug-fix cycle begins.
A more flexible (and less risky) way to proceed is to go several
times through the various development processes. In this way you
iteratively build a deepening understanding of the requirements,
engineer a robust architecture, ramp up the development
organization (where required), and eventually delivering a series
of implementations that are gradually more complete. This is called
an iterative lifecycle. Each pass through the sequence of processes
is called an iteration.
Therefore, from a configuration and development perspective the
software lifecycle is a succession of iterations, through which the
software develops incrementally. Each iteration concludes with the
release.
Early iterations in the project are likely to emphasize
requirements, analysis, and design. These early iterations may also
include implementation and test activities – of a prototype,
for example. Therefore, in the Inception and Elaboration
phases, an iteration is most likely to result in an
incremental release of improvements to models, documentation, and
prototypes.
*
*
Let’s continue with Iterative and Incremental.
Rather than breaking the software implementation process into
discrete steps such as requirements, analysis, design,
implement, and test; OUM breaks the process into major
milestones called the Lifecycle milestones - originally
defined by Barry Boehm (bame) and initially published in the
article "Anchoring the Software Process.“
The milestones occur at the phase boundaries and serve to anchor
the software implementation process. They are represented in
this diagram by the milestones at the end of each phase. We will
discuss these milestones in a later module of this training.
An iteration can be thought of as a mini-project that runs
through a group of tasks and activities. These activities perform a
complete requirements-analysis-design-implementation-test cycle to
produce an incremental improvement to the project's
active work products – i.e., an increment. Each iteration also
includes planning, at the front, and preparation for release, at
the end.
The rules for the iterations are as follows
An iteration can result in a release of software, but it does not
necessarily produce software.
Early iterations will address high-risk technical or architectural
issues, and will clarify the scope of the project.
*
time
*
Let’s spend a few moments discussing the release and how it is
applied in OUM.
At the end of each iteration, the active set of artifacts or work
products are released to form the current baseline. Therefore, as
stated earlier, 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.
An internal release is used only by the development organization,
as part of a milestone, or for a demonstration to users or
customers. An external release is delivered to the customer
organization and may go into production.
Iterations and releases allow a better usage over time of the
various specialties in the team: analysts, designers, implementers,
testers, and so forth. Regular releases let you break down the
integration and test issues and spread them across the development
cycle. These issues have often been the downfall of large projects
because all problems were discovered at once during the single
massive integration step, which occurred very late in the cycle,
and where a single problem can bring the entire team to a
halt.
*
© 2008, 2010 Oracle and/or its affiliates. All rights
reserved.
Assess Service Requests
Automatic Sign-Off Service Requests
*
Imagine for a moment that these elipses represent a set of
functional gaps – or use cases – that need to be developed into
software to support the business requirements of an
enterprise.
*
© 2008, 2010 Oracle and/or its affiliates. All rights
reserved.
© 2008, 2010 Oracle and/or its affiliates. All rights
reserved.
*
In terms of sub-systems, the application architecture could look as
in this picture. As you can see separate sub-systems have been
defined for
Planning – Logistics – Human Resources – and so on.
However sub-systems, as defined, may not always provide the correct
grouping to define increments, as the use cases in the same
subsystem may not necessarily be strongly related.
For example from a business process perspective, the use cases Log
Service Request by Customer and Sign-off Service Request are
relatively loosely coupled, although both might be in the same
sub-system. On the other hand is there a strong relationship (or
cohesion) between the use cases Log Service Request by Helpdesk and
Assess Service Requests which are in two different
sub-systems.
*
Iteration Group 1
Iteration Group 2
Iteration Group 3
The grouping here defines three increments.
In increment 1 the use cases are grouped based on one or more the
following considerations:
Architectural significance
Complexity
Dependency
In short, we prioritize the Use Cases in this way so that we are
able to focus on the most difficult, risky, or significant business
requirements as early as possible with the project lifecycle
Increment 2 builds upon the work completed in Increment 1, along
with any Change Requests, by dealing with requirements that are
deemed to have a lower level of difficulty, risk, significance
etc.
In our example, Increment 3 includes requirements that may be
deemed “optional” and have the lowest level difficulty, risk or
significance
*
More than just “technical architecture”
Set of significant decisions about the organization of a software
system
Collection of models that describe the system
Includes structural elements and interfaces, and their
behavior
© 2008, 2010 Oracle and/or its affiliates. All rights
reserved.
© 2008, 2010 Oracle and/or its affiliates. All rights
reserved.
*
Architecture can be an overloaded concept, but it is a very
important concept in OUM. Architecture refers to the set of
significant decisions about the organization of a software
system.
[click]
This includes the selection of the structural elements and their
interfaces by which the system is composed, together with their
behavior as specified in the collaboration among those elements. It
also refers to the composition of these structural and behavioral
elements into progressively larger subsystems, and the
architectural style that guides this organization.
[click]
Just like the blueprints for a house or building, the architecture
is the collection of models that describe the system………..I say that
again…… The architecture is the collection of models that describe
the system.
[click]
*
Architecture-Centric
The system’s architecture is used as a primary artifact for
conceptualizing, constructing, managing, and evolving the
system
The Architecture Description is a key work product of
Elaboration.
© 2008, 2010 Oracle and/or its affiliates. All rights
reserved.
© 2008, 2010 Oracle and/or its affiliates. All rights
reserved.
*
OUM is architecture-centric from the beginning of the project. An
Architecture Description is defined in the initial phases and
expanded in the subsequent phases to produce high quality software
systems in a cost effective way. The Architecture Description
provides an infrastructure, often a framework, that supports
continuously adding or replacing components through the iterations
to minimize the effect on the rest of the application. It should be
noted that the technical architecture is only a small piece of the
overall architecture.
*
Learning Checkpoint
OUM Principles
*
*
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.
© 2008, 2010 Oracle and/or its affiliates. All rights
reserved.
© 2008, 2010 Oracle and/or its affiliates. All rights
reserved.
*
Now let talk about the OUM principle of Risk-Focused
A key focus of each iteration in OUM is to indentify and reduce the
most significant project risks.
This helps ensure that the project team addresses the most
critical risks as early a possible in the project
lifecycle.
*
Tailor to Appropriate Level of Ceremony
Guidance provided for
© 2008, 2010 Oracle and/or its affiliates. All rights
reserved.
OUM has been developed to be flexible and scalable so that it can
be applied to any size information technology project.
The method is intended to be tailored to support the appropriate
level of ceremony required for each project. In fact, OUM is built
with the idea that too much ceremony can be as risky as too
little.
[click]
*
*
Adapted from Dynamic Systems Development Method (DSDM)
Focused on delivering necessary functionality
within the required timebox
and ceremony appropriate to project
© 2008, 2010 Oracle and/or its affiliates. All rights
reserved.
*
In support of the Flexible and Scalable principle, OUM is said to
be “Fit-for-Purpose”.
[click]
The concept of fitness for business purpose or “Fit-for-Purpose” is
derived from the Dynamic Systems Development Method (or DSDM)
framework. Fitness-for-Business Purpose refers to the focus on
delivering necessary functionality within a required timebox.
[click]
Traditionally, projects have been focused on satisfying the
contents of a requirements document or rigorously conforming to an
existing set of work products. Often, especially where iterative
and incremental techniques have not been employed, requirements may
be inaccurate, the previous deliverables may be flawed, or the
business needs may have changed since the start of the project. Our
collective experience shows that applying fit-for-purpose criteria,
rather than tight adherence to requirements specifications, results
in an information system that more closely meets the needs of the
business.
[click]
In OUM, this principle is extended to refer to the execution of the
method processes themselves. Practitioners are encouraged to scale
OUM to be fit-for-purpose for a given situation.
It is rarely appropriate to execute every activity or task within
OUM. OUM provides guidance for determining the core set of
activities to be executed, the level of detail targeted in those
activities and their associated tasks, and the frequency and type
of end user deliverables. The project workplan should be developed
from this core. The plan should built up, rather than tailored
down, to the level of discipline appropriate to the identified
risks and requirements.
*
Learning Checkpoint
OUM Principles
*
*
Similar to legacy methods in these areas:
Business Processes
Supports:
Solution-Driven (AIM for Business Flows, Compass Accelerated)
Software Upgrade
*
In comparing OUM to Oracle current quiver of application
implementation methods, it’s helpful to consider both the
similarities and differences between OUM and methods like AIM
Foundation, AIM for Business Flows, Compass, and Siebel Results
Roadmap.
OUM several essential characteristics that it shares with these
legacy methods:
[click]
OUM emphasizes business processes as a primary determinant of
business requirements the new system must satisfy
[click]
OUM includes tasks aimed at the mapping of the business
requirements to the standard application functionality and
identification of gaps, also known as fit-gap or “map and
gap”
[click]
OUM includes tasks specifically aimed at defining key business
architecture structures such as Chart of Accounts, Multi-Org, and
Trading Community Architecture, and
[click]
OUM also includes tasks that support defining application setups
values or configuration options
[click]
Moreover, OUM has adopted a number of leading practices from our
legacy methods
[click]
*
Oracle Unified Method Approach
OUM’s implementation approach differs from legacy methods in these
areas:
Standards-based – Unified Process
Tighter integration across disciplines
Increased emphasis on Architecture
*
[click]
First OUM is based on the Unified Process, a de facto industry
standard that is an iterative and incremental approach to
developing and implementing software systems.
[click]
OUM is also more comprehensive in scope than any of our legacy
application methods. With the common backbone WBS as a basis, OUM
supports a variety of engagements from development of an enterprise
level IT strategy to the implementation of a packaged application,
which may help to realize that IT strategy, and everything in
between.
Remember, however, that even though OUM is more comprehensive, it
is designed to be scalable and adaptable, so that a practitioner
need do only what is required to address the project scope and
risks associated with the project at hand. OUM provides guidance on
determining the minimum set of tasks to be executed, the level of
detail targeted in those tasks, and the frequency and type of end
user deliverables. The method has been developed with the intent
that the approach for a given project be “built up” from a core set
of activities to achieve an appropriate level of discipline, rather
than tailored down.
We want to emphasize at the outset that you should not serve the
method; instead you must make it serve you. The purpose of methods
are to identify and manage risks, improve repeatability and
quality, and encourage knowledge capture and reuse. If you’re not
going to need it, don’t do it.
[click]
[click]
OUM has much tighter integration with other disciplines, which will
more readily enable the merging of two or more disciplines into a
single project plan – for example, on a project that involves the
implementation of both a packaged application and a data
warehouse.
[click]
[click]
*
Now that you have completed this module, you should be able
to:
Describe the 5 main principles of the Oracle Unified Method
(OUM).
Understand how these principles have influenced OUM
development.
© 2008, 2010 Oracle and/or its affiliates. All rights
reserved.
Conclusion
*
*
*
This concludes the OUM Principles module of the Implement Focus
Area Overview Course.
Thank you for your attention and participation.
Order Skis
Return Skis
Manage Profile
Order Skis
Return Skis
Manage Profile
Order Skis
Return Skis
Manage Profile
Order Skis
Return Skis
Manage Profile