3 - Module - OUM Implement Components

OUM Level 2 Overview CourseModule: OUM Implement Components
*
*
OUM Implement Components
By the end of this module, you should be able to:
Describe the Oracle® Unified Method (OUM) Implement Core Workflow and understand its purpose.
Recognize that there are many different views to access the OUM Implement focus area method material.
© 2008, 2010 Oracle and/or its affiliates. All rights reserved.
*
By the end of this module, you should be able to:
Describe the OUM Implement Core Workflow and understand its purpose.
*
*
*
In the OUM Level 1 Overview and Awareness training, you were introduced to some of the individual components that are the building blocks of the Oracle Unified Method. These included phases, milestones, processes, activities and tasks.
These components are further organized into three focus areas. These three focus areas provide frameworks for project and program management, enterprise level planning, and project implementation.
The Manage focus area provides a framework in which all types of projects can be planned, estimated, controlled, and completed in a consistent manner. For those who are familiar with the Oracle legacy methods, the Manage focus area contains the material from the Project Management and Program Management methods – PJM and PGM.
The Envision focus area comprises the areas of the Oracle Unified Method framework that deal with development and maintenance of enterprise-level IT strategy, architecture, and governance. Ideally, every enterprise should be executing these or similar processes. Every project that effects a corporation's IT landscape should have its origins here.
The Implement focus area provides a framework to develop and implement Oracle-based business solutions with precise development and rapid deployment.
*
*
As we previously mentioned, the OUM Manage focus area contains the material that supports the project and program manager.
The fundamental responsibility of the project manager is to manage a project to an agreed upon level of quality while planning for and controlling the "triple constraints" of scope, cost and schedule. OUM’s Manage Focus Area is designed to support the project manager in fulfilling these responsibilities. The Manage Focus Area works closely with the Envision and Implement focus areas by wrapping around the project.
*
*
The goals for the Envision focus area are:
To provide a set of processes that can be adopted by an enterprise in order to better align IT delivery with Business strategy,
To provide a framework for development of services that support enterprise or strategic level interactions, and
To provide the context for OUM based delivery services and connect those services to the larger IT lifecycle.
One of the goals of OUM is to provide the methodological basis for the delivery of any IT related service. Envision extends OUM's capabilities beyond delivery and management of software implementation projects into the realm of IT vision and strategy. Envision is focused on information technology related business architecture and practices.
Like many of the aspects of OUM, it is unlikely 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.
*
*
The OUM Implement Focus Area is to be applied to information technology projects and documents the essential project execution processes.
The OUM implementation architecture provides a rapid, adaptive, and business-focused, approach to Implementation. These features are embodied within a framework that supports the complete software development and implementation lifecycle.
The diagram illustrates a typical OUM project, with a typical number of iterations. The relative amount of effort performed in each process, during each iteration is represented by the height of the colored bars for each process. The number of iterations performed and the amount of effort required for a particular project will vary depending upon a number of a factors, such as scope, technical and programmatic risk, system size, team size, etc. The number of iterations can vary from as few as 3 to as many as 12 or more. Projects may also employ multiple production releases, and therefore, multiple iterations of the entire lifecycle to fulfill all of the business requirements.
*
1.unknown
The Bad
Can be difficult to isolate the “essentials”
The Solution
When people are first introduced to OUM, they see both good and bad news…
[click]
The good news is that OUM contains a comprehensive set of method materials that are able to support development and implementation of a broad range of business solutions. In fact, as you recall, OUM is intended to support the entire Enterprise IT lifecycle, including support for the implementation of all of Oracle’s products.
[click]
The bad news is that in order for OUM to be able to support such a broad range of work, the volume of material included in OUM can be overwhelming. For users of the method, especially newcomers, it can be difficult to isolate and comprehend the essential pieces that are required for a particular project or situation. It can seem like OUM is a “heavy” method. Of course, this is not OUM’s intent.
[click]
*
So, why a “core workflow”?
[click]
The first, and most important reason is to accelerate practitioners understanding of the Oracle Unified Method.
[click]
The core workflow also helps us to identify and highlight the tasks that are at the heart of the Implement focus area. These are the tasks that are essential to many of the projects that are supported by the method.
[click]
For now, it is important to know that the core workflow is intended to provide a good starting point for building up a project workplan. We’ll talk more about this in a few minutes.
[click]
*
Start from a core set of tasks.
Consider the OUM Implement Core Workflow.
1Balancing Agility and Discipline: A Guide for the Perplexed by Barry Boehm and Richard Turner
As I have already mentioned, OUM is intended to be highly scalable. In our industry today we hear a lot about agile or agility. We see many methods in today’s marketplace that have adopted an agile approach to software development. The Global Methods team is in strong agreement with the tenets put forth in the “Manifesto for Agile Software Development.” We also see a debate in our industry about agility versus discipline which has been well framed in the book “Balancing Agility and Discipline: A Guide for the Perplexed” by Barry Boehm and Richard Turner.
To help OUM’s users determine just how much of OUM they should employ on a given project, we have adopted many of the philosophies and conclusions put forth in this book. It has helped to guide us in developing OUM and also in developing the guidance related to using OUM.
By Boehm and Turner’s definition, at its highest level, OUM is a plan-driven method, which could be tailored down by an expert, to fit a particular situation. However, as the book points out, non experts tend to play it safe under these circumstances, and often tend to use too much or all of a method “at considerable unnecessary expense” and for little or no additional value.
Therefore, we’ve taken the advice of Boehm and Turner and adopted the philosophy of “Build it Up – Don’t Tailor it Down.” OUM’s Implement Core Workflow, along with OUM’s diverse set of views, are intended to support this philosophy.
In addition to the workflow and views, we advise you to follow 4 steps when considering the tasks to include in your OUM based workplan.
*
Add tasks as you identify scope and risk.
Tasks related to:
etc.
Once you have established the core of what you need to do, you will add tasks as you identify scope and risk on your project.
First consider additional tasks based on risk.
Boehm and Turner again offer excellent guidance. They define 5 risk areas to be considered and a sliding scale for each of the areas that also helps to determine the agility v. discipline required for your project.
The first area is Personnel – Which refers to the experience of the specific personnel that will be assigned to your project with respect to their ability to follow a method – at the discipline end – or adapt and actively tailor the method – at the agile end.
The next area is Criticality – This refers to the consequences of failure of the software – if many deaths will occur if the software fails, obviously much methodological discipline will be required, whereas if only discretionary funds will be lost the approach can be more agile.
Next consider team Size – Where at one end you have a 300 or larger project team that requires a heavily disciplined approach and on the agile end of the spectrum where the team may only have 1-3 members.
The next area is called Dynamism – This describes the percentage of the requirements that you anticipate will change each month based on factors, such as, market conditions or the competitive landscape – from 1% at the discipline end to over 50% at the agile end. For example, bridges can be built using a very disciplined, plan-based method while software that support a rapidly evolving social networking environment in today’s competitive marketplace will require a very agile approach.
The final area is Culture - This refers simply to the corporate culture of the project team and of the customer. Does the culture thrive on order (that is, discipline) or chaos (that is, agility)
In OUM, once you have determined the core tasks based on the project objectives and an analysis of these factors, consider adding tasks for other aspects of your project.
Ask yourself, does the project require a stable and lasting architecture, or will that not be used to maintain and expand the system under development?
Does the project involve a large number of business rules?
Will it employ a service oriented architectural style?
Is there a large amount of reporting requirements?
If you answer yes to any of these questions, you probably need to add additional tasks to your workplan.
*
Consider the depth to which you will execute specific tasks.
Tasks are placeholders for work.
They are highly scalable.
Can vary from “a bit of thinking”
to “development of a comprehensive work product.”
The next step is, perhaps, the most important
Placing a task into an OUM iteration plan or onto an OUM workplan is not a binary event. Tasks are not all or nothing. You must consider the depth to which you should execute tasks on an OUM project. In fact, the depth to which you execute a task will change from iteration to iteration. Too much or too little discipline or work are both risky.
Under the proper circumstances, spending the time to simply consider a task can constitute executing the task. This is a perfectly acceptable practice and is often preferable to eliminating the task altogether. Tasks are there to remind you of the process and order of the work. You should think of them as “placeholders for work.” OUM backs up each task with extensive task guidance and work product support – but these should be applied only to the appropriate level.
For example, assume that you are at the beginning of an iteration of the Construction phase of an OUM project. You might think that it is long past the time to execute the task “Develop Business and System Objectives” – and, of course, you’d be correct. However, while you should not go back and redo the task, if someone on the project doesn’t spend a few minutes to consider whether the objectives have changed, then you run the risk of not remaining aligned with the objectives.
In the same way, requirements related tasks must also be “considered” during later phases. If requirements have changed, then the project must consider the changes. Of course, that does not mean that the changing requirements will be incorporated into the scope of the project free of charge. But to deliver the project without considering new or changing requirements may mean low user satisfaction or a system that does not meet the needs of the business. A good software implementation project must “adapt to change.”
*
Consider the depth to which you will execute specific tasks during specific iterations.
Combine tasks and work products.
Define an appropriate set of work products or deliverables.
Define “just enough” documentation and ceremony.
If you’re not going to need it, don’t produce it.
Finally, you should consider whether it is advisable or appropriate to combine tasks or to execute your project using OUM’s activities – which are groupings of tasks.
*
OUM Implement Core Workflow
Once again, here is the OUM “whale diagram” that depicts the 5 phases and 14 processes of the OUM Implement Focus Area.
The Implement Core Workflow is primarily focused in the first three phases – Inception, Elaboration, and Construction. The workflow covers tasks in 6 processes – Business Requirements, Requirements Analysis, Analysis, Design, Implementation, and Testing.
If you think about it for a moment, this is the heart of any software implementation method – the span from Requirements to Testing.
These processes contain the core elements that are required to establish the project’s scope and to elicit and document the requirements. While the purpose of a software implementation project is to “implement software,” the success or failure of such a project is nearly always determined in these important processes.
*
Objectives
Diverge in important areas
Here is a high-level view of the Implement Core Workflow.
It is important to note that the workflow is executed during each iteration in the Inception, Elaboration, and Construction phases of OUM – though the emphasis will be different for each iteration.
There are a number of approaches that we could have taken for depicting this workflow. These boxes do not represent any specific construct within OUM. It’s not important to analyze this high level workflow in detail. The intent is to present a high level conceptual view. Therefore the diagram is a conceptual look at the core workflow.
Let’s begin to deepen our understanding of OUM, by walking through these conceptual building blocks.
[click]
Each workflow begins with determining or reviewing the Objectives for the project.
[click]
Next we gather requirements in the form of a System Context Diagram, Future Process Model, and Use Case Diagram – These define the scope for the project – In later iterations, we will add Detailed future process models and Use Case Specifications, as required
[click]
The next step is to “Map” the requirements onto the products or applications that have been chosen. This is often referred to as “Fit/Gap” or “Map and Gap.” Essentially, an analysis of the requirements is done to determine which requirements can be met by configuring the Oracle product set and which requirements will drive the development of custom application software or “custom extensions.”
This is the point where the core workflow splits into two parallel sub flows.
[click]
For those requirements that are satisfied by products, the configurations are determined and recorded.
[click]
For the “Gaps” that have been identified, further analysis of the functional requirements and corresponding design of the custom components is completed to develop the models and specifications necessary to develop the custom extensions or custom application software. Those components are then implemented into software.
[click]
Ultimately, the sub flows converge as the custom components are integrated with the configured product software. The resulting integrated system is tested.
[end of script]
It is important that you not read too much into the absolute order of events depicted in a single pass through the workflow. While we say that the workflow is executed in each iteration, tasks or steps may be skipped in any given iteration. For example, it is not necessary to develop a complete set of use cases for the eBusiness Suite, only for the custom extensions or custom application software being developed to satisfy the unique project requirements. On the other hand, other Oracle products involve complex “configurations” that would benefit from development of detailed use cases and analysis and design artifacts that are part of the custom development sub flow.
Also, some projects begin with a predefined solution. In that case, the proposed future process models or use cases may already be defined. The “Map Requirements” block is then used to map the proposed solution against the client requirements. This approach often uses some sort of functional prototype – often referred to as a conference room pilot – to accomplish the mapping activities.
This slide is simply intended to reinforce the idea that there is this single workflow, but that there are also two paths that can be followed.
The sub-flows share some tasks, while they diverge in some areas – as we have already seen.
Most projects, in fact, will use both of these sub-flows.
Take, for example, a project that is implementing a set of business processes using PeopleSoft Enterprise. It is very likely that there would be a large portion of the functional requirements that can be satisfied by using standard Enterprise functionality. Those requirements will follow the Configuration sub-flow.
However, there may also be a few customer-unique requirements that are not fully satisfied by the product. These “gaps” might require some custom developed application software and would follow the custom development sub-flow.
*
2.unknown
A view presents a predefined subset of the OUM materials.
*
*
As we pointed out in the Level 1 OUM training, the OUM materials are presented in formats called views.
All views can be accessed from the OUM Home page, using the Select a View pull-down.
As you can see the views are organized by the focus area, Manage, Implement and Envision.
The Other views category provides access to the Service-Oriented Architecture views in OUM and the Full Method and Focus Area views.
*
Full Method and Focus Areas
First, let’s talk about the Full Method and Focus Areas views.
From the OUM Home page, Select a View, in the Other views category, you can access the Full Method and Focus Areas page. This page describes and provides links to the full method views and the focus area views in OUM. These views would not be used to deliver a project but are provided as a reference tool.
There are two full method views; The Full Method view and the Full Method Activities and Tasks view. Both of these views provide access to all the method content for Manage, Envision and Implement. The Full Method view is organized by focus area and process. The Full Method Activities and Task view is organized in work breakdown structure order.
*
*
*
Now, let’s talk about the Implement views.
Under the IMPLEMENT VIEWS heading you can see any discipline or service offering views for the Implement focus area.
*
The last view in the Implements views section is the Implement Models view. This view provides access to the core modeling tasks in the Implement focus area. It provides links to the OUM Materials as well as to example models.
*
*
*
*
*
3.unknown
Now that you have completed this module, you should be able to:
Recognize that there are many different views to access the OUM Implement focus area method material.
Now that you have completed this module, you should be able to:
*
*
This concludes the OUM Implements Component module of the Implement Focus Area Overview Course.
Thank you for your attention and participation.
PROPERTIES

3 - Module - OUM Implement Components

Documents