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.
*
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
*
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
Manage Logistics and Warehousing
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
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
UML icon for a use case
*
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
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
*
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.
*
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.
*
*
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
*
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.
*
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.
*
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
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
*
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.
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

2 - Module - OUM Principles

Documents

Transcript of 2 - Module - OUM Principles