Professional Documents
Culture Documents
Executive Overview.......................................................................................... 3
Introduction ....................................................................................................... 3
Standards Based ............................................................................................ 3
Supports Both Agility and Discipline ........................................................ 4
Benefits of OUM............................................................................................... 4
Key Features of OUM...................................................................................... 5
Flexible ........................................................................................................... 5
Scalable ........................................................................................................... 5
Pre-defined Views......................................................................................... 5
Implementing an OUM Project ...................................................................... 6
Project Phases for Control .......................................................................... 7
Inception.................................................................................................... 7
Elaboration................................................................................................ 7
Construction ............................................................................................. 7
Transition .................................................................................................. 7
Production................................................................................................. 7
Project Processes for Continuity ................................................................ 8
Business Requirements............................................................................ 8
Requirements Analysis............................................................................. 8
Analysis ...................................................................................................... 8
Design ........................................................................................................ 9
Implementation ........................................................................................ 9
Testing........................................................................................................ 9
Performance Management .................................................................... 10
Technical Architecture........................................................................... 10
Data Acquisition and Conversion........................................................ 11
Documentation....................................................................................... 11
Adoption and Learning ......................................................................... 11
Transition ................................................................................................ 12
Operations and Support........................................................................ 12
Project Activities Represent the Engagement Lifecycle........................ 13
Managing an OUM Project............................................................................ 13
Developing and Maintaining Enterprise Architecture Activities ............. 15
Components of OUM .................................................................................... 16
Hardware and Software Requirements......................................................... 16
Conclusion........................................................................................................ 16
Page 2
EXECUTIVE OVERVIEW
OUM supports the complete range of
Oracle technology projects including:
- Service-Oriented Architecture (SOA)
- Enterprise Integration
- Custom Software
- Identity Management (IdM)
- Database Security
- Governance, Risk, & Compliance (GRC)
- Performance Tuning
The Oracle Unified Method (OUM) can help you develop and implement
technology-based business solutions with precise development and rapid
deployment. You can tailor OUM to support your specific project situation. With
its ready-made templates, guidelines, and tailored work breakdown structure, OUM
provides the programmatic tools you need to manage the risks associated with your
information technology-based projects.
Oracle Consulting Services has packaged OUM to accelerate your development and
technology-based efforts. OUM presents an organized, yet flexible, approach. Its
defined, operational framework helps anticipate critical project needs and
dependencies throughout your software development and implementation project.
With OUM, you can move efficiently through the development lifecycle to quickly
achieve business results.
INTRODUCTION
Standards Based
OUM is standards based. OUM leverages one of the de facto industry standards,
Unified Software Development Process (UP). UP is an iterative and incremental
approach to developing and implementing software systems. Project managers use
UPs four-step approach (inception, elaboration, construction, and transition) to
make sure they and their stakeholders develop a shared understanding of what is
needed, choose an appropriate architecture, and transfer the ownership of the endproduct to the stakeholders. OUM tailors and extends the Unified Process by
incorporating field experience and intellectual capital contributed by Oracle
practitioners. OUM recognizes the advantages of an iterative and incremental
approach to development and deployment of information systems. Any of the
tasks within OUM may be iterated. Whether or not to iterate, as well as the
number of iterations, varies. Tasks may be iterated to increase the quality of the
work products to a desired level, to add sufficient level of detail, or to refine and
expand the work products on the basis of user feedback.
OUM also employs the Unified Modeling Language (UML) as the basis for
analyzing software requirements and modeling software architecture and design.
UML is a modeling language defined by the Object Management Group (OMG).
Page 3
http://www.agilemanifesto.org and
OUM supports both Agility and Discipline. OUM is designed to support a broad
range of project types. As such, it must be scalable and adaptable. At a high level,
there are two different camps in todays method landscape: plan-driven and agile.
Page 4
Flexible
Scalable
Pre-defined Views
Flexible
OUM was designed with scalability in mind. From the largest, multi-national,
multi-site, multi-entity projects, through to the smallest, limited size, constrained
scope projectsOUM provides the scalability required by each unique project.
Guidelines aid in determining which tasks to include in the project plan. This
greatly reduces the complexity for the project management team in planning the
work effort required.
Pre-defined Views of OUM can be seen by
Pre-defined Views
applying Filters.
The method material is organized into pre-defined Views. Views provide an initial
tailoring of the workplan specific to a focus area, discipline, or service offering.
Each view page provides access to guidance and a tailored work breakdown
structure.
OUM 4.4 provides the following pre-defined views:
Full Method
Page 5
Manage
Envision
Implement
Discipline Views
Strategy
Page 6
Inception
The goal of the Elaboration phase is to move development of the solution from the
scoping and high-level requirements done during the Inception phase to
development of detailed requirements models, the partitioning of the solution, the
user interface prototype, and the architectural prototype. The Elaboration phase is
used to verify the development team's understanding of the client's business
requirements and to reduce development risk.
Construction
The Construction phase takes the solution from detailed requirements models,
through development and testing of components, and integration to a system that
is ready for a first release that goes into production, often a limited release and
often called a beta release. An iterative process is used to refine the data and detail
the use cases, as well as develop the physical database and components, until they
meet the business requirements, within the constraints of the project timeboxes and
priorities.
When all of the planned iterations have been completed, the complete system is
tested. The tested system is the end deliverable of the phase.
Transition
The Transition phase takes the completed solution from installation onto the
production system through the acceptance test to launch of the live application,
open and ready for business. The goals of the Transition phase are to gain
acceptance of the new system within the user organization, and, if the new system
replaces and old one, to provide a smooth cut-over to the new application. Minor
upgrades may be developed and released after production starts. Also, planning is
performed for the development of any remaining functionality, in a new increment.
Production
The goal of the Production phase is to provide system support, monitor the system,
to determine, develop and implement required upgrades, as well as measure the
Page 7
system performance, assess the success of the system, and put a plan into place for
future enhancements to the application.
Process - A discipline or sub-project that
All OUM tasks are also organized into processes that group related tasks together.
Project team members are assigned to these groupings according to their
specialization and background. OUM includes the following processes.
Business Requirements
In the Business Requirements process, the business requirements for the proposed
system or new enhancements are identified, refined, and prioritized by a tightly
integrated team of empowered ambassador users and experienced analysts. The
process often begins from an existing high-level requirements document and a
scope document. However, it is possible to begin from an agreed on scope and
objectives before requirements have been defined.
The Business Requirements process delivers a set of requirements models and a
prioritized list of requirements as a basis for system development. Both the models
and requirements list are dynamic work products that change as the understanding
of the team develops with the system.
The main work products of this process are the business objectives and goals, the
list of functional requirements, and non-functional requirements.
Requirements Analysis
In the Analysis process, the captured requirements are analyzed by refining and
structuring them via a conceptual object model, called the Analysis Model. The
Analysis Model provides a more precise understanding of the requirements and
provides details on the internals of the system. The Analysis Model is described
using the language of the developers as opposed to the requirements obtained in
the Business Requirements and Requirements Analysis processes where the
emphasis is on the functionality of the system expressed in the language of the
client. Thus, it contributes to a sound and stable architecture and facilitates an in-
Page 8
In the Design process, the system is shaped and formed to meet all functional and
non-functional requirements. This form is based on the architecture created and
stabilized during the Analysis process. Thus, the work products produced during
Analysis are an important input into this process.
Design is the focus during the end of Elaboration phase and the beginning of
Construction iterations. Models are created that are used during the
Implementation process. The Design Model can be used to visualize the
implementation of the system.
The main work products of this process are the Design Model which includes an
object model that describes the design realization of the use cases, design classes
that detail the analysis classes outlined in the Analysis Model, the software
architecture description enriched with the new architecture views, and deployment,
and design models.
Implementation
Page 9
Method (PJM) and to the definition and refinement of requirements in the Business
Requirements process. It addresses mainly functional testing. The Performance
Management process addresses non-functional testing activities. Testing includes
systems integration testing that essentially extends the system testing to test
integration of the new system with the other enterprise systems with which it
communicates.
Testing activities are a shared responsibility of developers, quality assurance
engineers, and ambassador users, working together as an integrated project team.
The Testing process presupposes that there is a highly visible user interface from
which system events can be driven and results validated. The higher proportion of
artifacts that are visible to the ambassador users (for example, user interfaces and
reports) the more they are able to participate in the Testing process.
Performance Management
Page 10
In the Data Acquisition and Conversion process the data that is required to be
converted is explicitly defined, along with its sources. This data may be needed for
system testing, training, and acceptance testing as well as for production. In some
cases, it is beneficial to convert (some) data at earlier stages to provide as realistic as
possible reviews of the components during the development iterations. On the
other hand, this may be difficult, as the actual Database Design for the new system
is not yet stabilized.
The amount of effort involved with conversion greatly depends on the condition of
the data and the knowledge and complexity of the data structure in legacy systems
and existing applications. For large projects, where large existing systems are
replaced, and most all of the data needs to be converted, consider running this as a
separate project in parallel to the development project. In such situations,
thoroughly analyze the existing systems, map them to the new data model, and
build multiple conversion modules of various complexities. The project team
determines an overall Data Conversion Strategy to meet the Data Conversion
Requirements, including both automated and manual methods. The process
includes designing, coding, and testing any conversion modules that are necessary
as well as the conversion itself. The cleaning of legacy data is visibly identified as a
user and client project staff task so that it can be staffed and scheduled. If data
anomalies exist in the current system(s), or there is an unusual number of
exceptions, recommend data clean-up to the project sponsor.
Documentation
Adoption and Learning focuses on the use and acceptance of new applications by
all users and the optimization of organizational performance. Inherent in every
technology change is the opportunity to become a stronger, more cohesive
organization; a more efficient performer; a more agile competitor. The benefits are
Page 11
great, but the challenges are many. Organizations who implement new technology
cannot afford to neglect key areas that might ultimately compromise the value of
the technology investment. The goal is for full adoption of the new business
system. The human and organizational aspects of an implementation are often the
decisive factors in its success. Adoption and Learning provides a structured
approach that addresses the human and organizational acceptance and use of new
applications. Adoption and Learning increases the organizations return on
investment by reducing the risks of implementing applications, increasing the
productivity of all user groups, and assisting the organization to reach peak
performance with the new business system. The more quickly and effectively the
business can adopt new technology, the more productive and competitive is the
organization.
The nature of the OUM approach, often requiring a significant change in the
implementing organizations business processes, coupled with the rapid
implementation timelines, increases the importance of the change management
aspects of the Adoption and Learning process.
Transition
The goal of the Operations and Support process is to monitor and respond to
system problems, upgrade the application to fix errors and performance problems,
evaluate the system in production and plan enhancements for increased
functionality, improved performance, and tighter security.
The development project does not come to an abrupt end when the team installs
the application system into production. In fact, the months following that
milestone can determine the real success or failure of the project. Internal auditors
have not yet produced the system evaluation, and users most likely still have a few
problems to uncover. There are certain to be requirements with lower priorities
that have not been implemented. The Could have requirements and any
remaining Should have requirements can now be re-prioritized into an
enhancement plan, from which upgrades can be defined.
Page 12
An activity is the next level of organization below a phase. Tasks in OUM are
grouped into activities to better represent the engagement lifecycle. For example,
Gather Solution Requirements is one of the activities within the Inception phase.
This activity consists of five tasks related to collecting requirements for the
solution.
Activities allow the project manager to streamline creation and management of the
Work Breakdown Structure (WBS) for an engagement. Because all tasks fall within
an activity, project managers (and other practitioners) are able to manage to the
activity-level rather than the task-level.
MANAGING AN OUM PROJECT
The Manage Focus Area provides a framework in which all types of projects can be
planned, estimated, controlled, and completed in a consistent manner. Oracle's
Project Management Method (PJM) is part of the Manage Focus Area. Consistency
is required in today's business environment, where projects often implement
packages, develop application extensions, and create a data warehouse in order to
satisfy a business need.
Project Management enables the project manager to manage delivery of an agreed
upon level of solution quality while planning for and controlling the scope, cost,
and schedule.
PJM has three phases:
Page 13
The PJM Project Start Up phase precedes the Inception phase. Project startup is
where all of the project planning activities take place and where policies,
procedures, and strategies are defined for each of the PJM processes, which govern
the conduct of the engagement.
PJMs Project Closure phase occurs after the Production phase.
Project Execution and Control is the PJM Phase that runs concurrently with OUM.
The purpose of the Project Execution and Control Phase is to provide adequate
visibility into actual progress so that management can take effective actions when
the project's performance deviates significantly from the project plans. The Project
Execution and Control Phase includes tracking and reviewing the projects
accomplishments and results against documented WBS-dictionary, project
estimates, time schedule, resources plan, and cost budget, and adjusting these plans
based on the actual accomplishment and results.
PJM is organized into 13 processes:
Bid Transition
Scope Management
Financial Management
Work Management
Risk Management
Staff Management
Communication Management
Quality Management
Configuration Management
Infrastructure Management
Procurement Management
Page 14
The Envision Focus Area provides a framework for development and maintenance
of enterprise level IT strategy, architecture, and governance. Envision extends
OUM's capabilities beyond delivery and management of software implementation
projects into the realm of IT vision and strategy.
Envision consists of two phases:
Initiate
The Initiate phase is used to perform a set of foundational tasks. These tasks have
a broad range of objectives and applicability. At one end, the Initiate phase can
establish the vision for one or more projects intended to achieve a focused set of
business objectives. On the other end, the Initiate phase can result in establishment
of a broad set of enterprise level IT processes that are continued in the Maintain
and Evolve phase.
The Maintain and Evolve phase forms the foundation for governing and managing
enterprise level business processes and strategies. Envision is not intended to be a
broad treatise on corporate strategic planning. It is focused on information
technology related business architecture and practices.
Envision is organized into six processes:
Envision Roadmap
Enterprise Architecture
IT Portfolio Management
IT Governance
The Envision Focus Area provides an evolving set of best practices around
enterprise level IT strategy, architecture, and governance. It is not likely that all of
Envision's processes and tasks will be executed within any single enterprise, nor is it
likely that Envision will ever contain an exhaustive set of enterprise level processes.
Rather, Envision should serve as a framework that can be scaled to suit the needs
of a particular enterprise.
Page 15
COMPONENTS OF OUM
Templates Templates enable fast and easy creation of high quality work
products.
55 MB of disk space
CONCLUSION
With OUM, Oracles full lifecycle method for developing and implementing
technology-based business solutions, you can move efficiently through the
development and implementation lifecycle to quickly achieve business results.
For more information about OUM, contact ominfo_us@oracle.com.
Page 16