OUM

. 011 RD.005 RD.024 Use Case Use Case Model Visio Template and Stencil Use Case Elaboration Elaboration .065 RA.ID RD.045 Create System Context Diagram Develop Future Process Model Develop Current Business Process Model Prioritize Requirements (MoSCoW) System Context Diagram Future Process Model Current Process Model MoSCoW List System Context Diagram Future Process Model Current Process Model MoSCoW ListExcel MoSCoW List-Word Generic Workshop Notes Generic Workshop Schedule and Workshop Preparation Notes Domain Model Document Requirements Inception Inception Inception RD.001 Task Detail Business and System Objectives Work Product Business and System Objectives Template Business and System Objectives Objectives Inception RD.023 Develop Domain Model (Business Entities) Develop Use Case Model Develop Use Case Domain Model Inception Use Case Model RA.030 RD. 010 Functional Prototype Validated Functional Prototype Business Data Structure Setups Business Data Structures Application Setup Documents Data Analysis Elaboration RA.085 Elaboration DS.030 Elaboration Analyze and Desi AN.030 Elaboration IM.020 Elaboration AN.010 Map Business Requirements Define and Estimate Application Extensions Define Gap Resolutions Develop Functional Prototype Validate Functional Prototype Define Business Data Structure Setups Define Business Data Structures Define Application Setups Analyze Data Specification Mapped Business Requirements Application Extension Definition and Estimates Gap Resolutions Specification Validated Functional Prototype Refer to the Task Overview for guidance.040 Elaboration DS. Validated Functional Prototype Business Data Structure Setups Refer to the Task Overview for guidance.Details AN. Application Setup Documents Analysis Model Map Requirements Elaboration AN. Refer to the Task Overview for guidance.010 Configure Inception RA.050 . Refer to the Task Overview for guidance. Inception RD001 Business and System Objectives . g. . In an Oracle COTS implementation this typically consists of (1) business process models (or business flows) depicting the functionality included. In general. and crafting a business solution based on those requirements during the project. process modeling workshops.. Requirements-Driven Approach An approach that is based on identifying requirements at the outset of the project through interviews. (2) pre-determined setup values that enable a working application instance to be established quickly for familiarization/mapping purposes.. which can be used to demonstrate the functionality included.Solution-Driven Approach An approach that is based on the use of a pre-defined business solution (e. customizations by promoting leading practice use of standard functionality to meet common business needs. The solution-driven approach seeks to avoid. and (3) predefined demo/test scripts based on the pre-defined setup values. etc. or minimize. In a solution-driven approach. Oracle Business Accelerators) as the proposed client business solution and tailoring that solution to the client's requirements during the project. the foundational elements of the business solution are already reflected in the components that comprise the pre-defined solution. and completed in a consistent manner. Envision. OUM's Manage Focus Area provides a framework in which all types of projects can be planned. and governance. and Oracle's existing methods. estimated. controlled.OUM Overview OUM includes three Focus Areas – Manage. Envision also assists in the transition from enterprise-level planning and strategy activities to the identification and initiation of specific projects. architecture. OUM Approach OUM is built on five main principles derived from the Unified Process. The Implement Focus Area provides a framework to develop and implement Oracle-based business solutions with precise development and rapid deployment. and Implement. the Dynamic Systems Development Method. OUM’s Envision Focus Area deals with development and maintenance of enterprise level IT strategy. Those are: • • • • • Iterative and Incremental Business Process and Use Case-Driven Architecture-Centric Flexible and Scalable Risk-Focused . . The number of iterations performed and the amount of effort required for a particular project will vary depending upon a number of a factors including scope. Scope The core framework of the OUM Implement focus area is to be applied to information technology projects based on Oracle Fusion technology and the Oracle product stack.Elaboration. 3 .Construction.Inception.Transition.Production). 5 . The relative amount of effort performed in each process. 1 . 2 .Elaboration. 1 . team size.Construction. 1 . The diagram below illustrates a typical OUM project. adaptive. technical and programmatic risk. system size. The number of iterations can vary from as few as 3 (for example: 1 . multiple iterations of the entire lifecycle to fulfill all of the business requirements. and therefore. and business-focused.Transition) to as many as 12 or more (for example. approach to Implementation. OUM documents the execution processes.Focus Area Overview Method Navigation IMPLEMENT FOCUS AREA OVERVIEW INTRODUCTION The Implement focus area provides a framework to develop and implement Oracle-based business solutions with precise development and rapid deployment. during each iteration is represented by the height of the colored bars for each process. Management processes are documented in Oracle’s Project Management Method (PJM). which is part of the OUM Manage focus area OUM Approach The OUM implementation architecture provides a rapid. These features are embodied within a framework that supports the complete software development and implementation lifecycle. etc.4 . with a typical number of iterations. 1 .OUM 5. Projects may also employ multiple production releases. Timeboxing is a powerful planning and controlling technique for some objectives. For example. testing. for some prototypes. for some architectural discussions." OUM and UML . it is useful to set timeboxes for use case refinements. It is a technique that reduces the risk of "analysis paralysis. and for post-production support. structure and behavior. The diagram below illustrates the how the UML models developed during a OUM project are related. As the software industry continues to mature. For further reading on Agile Software Development. Some techniques from Extreme Programming (XP) and Agile Software Development are already included in OUM. UML enables OUM to support modeling of the application architecture.OUM technology implementation employs the Unified Modeling Language (UML) as the basis for modeling business processes. For further reading on Extreme Programming. Oracle will continue to evaluate new techniques for inclusion in OUM. software systems. Process Models and UML Occur in these OUM Tasks . and technical architectures. Today. see Extreme Programming Explained. OUM recognizes the well-proven advantages of an iterative and incremental approach to development and deployment of information systems. see Agile Software Development. OUM was created with Process Models and UML Models in these Tasks: . OUM Implementation and Blended Delivery . adopted as phase gates by the Unified Process and by Oracle Unified Method. the highlevel requirements and the significant risks must be understood before the project can proceed. For more information on applying Blended Delivery to a OUM project. Where the Unified Process has four (4) phases: Inception. and scope of the project are defined and the project's feasibility is established during requirements gathering activities. . Where applicable and possible. With Blended Delivery. As requirements are defined they are also prioritized in relation to their business benefits. These milestones. and Transition. This section provides a brief overview of the five Oracle Unified Method phases: • • • • • [A] Inception Phase [B] Elaboration Phase [C] Construction Phase [D] Transition Phase [E] Production Phase [A] Inception Phase The overriding goal of the Inception Phase is to achieve concurrence among all stakeholders on the lifecycle objectives for the project. Many of the Business Requirements (RD) and Requirement Analysis (RA) tasks are completed during workshops with client involvement. which produce the high-level business models. the Inception phase is critical for all projects because the scope of the effort. see the Blended Delivery guidelines. Risks and mitigation strategies are identified. The business objectives.indicators of the progress of the project.OUM was created with the option of Traditional delivery (staffing with Onsite resources). Each of these phases culminates in an anchor point milestone. the functionality is partitioned to enable parallel development by separate teams of ambassador users and highly skilled Information Technology professionals. were taken directly from the Spiral Model Anchor Point Milestones that were initially developed in a series of workshops by the USC Center for Software Engineering and its government and industrial affiliates. OUM adds a 5th phase. The Inception phase delivers the Lifecycle Objective Milestone. Therefore. When Blended Delivery channels are used. additional review tasks are added for the offshore resources in the Inception and Elaboration phases. Construction. For further reading on milestones. goals. see "Anchoring the Software Process. Production to better cover the software engineering lifecycle. or with Blended Delivery (staffing with Onsite resources and with Offshore Onsite and Offshore Remote resources)." The milestones serve to establish exit criteria for each phase and provide an opportunity to evaluate the project's progress and the readiness of the project to commit resources to begin the subsequent phase. Back to Top PHASES OUM organizes the delivery of software implementation projects along several phases . An Iteration Workplan is developed to define the details of the work to be performed in the first Iteration of the Elaboration phase. The creation of more detailed models and specifications also becomes more critical for the onsite team when blended delivery is used. Elaboration. these review tasks with the offshore team are critical. Back to Phases [B] Elaboration Phase 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 developing the detailed requirements. The modified or new requirements are fed back to the requirement models in the business layer. the developer walks through the changes with the users. . The Construction phase delivers the Initial Operational Capability Milestone. At this point. When all of the planned iterations have been completed for each partition. The architecture evolves from the most significant requirements -. Design Model. etc. ensure that all components fit together. The stability of the architecture is evaluated through one or more architectural prototypes. as the requirements are progressively refined. the Construction phase is a manufacturing process. For each iteration. In more detail. and baselining the architecture of the system to provide a stable basis for the design and implementation effort in the Construction phase. and quality. The application system is completed within a pre-defined number of iterations. every developer works with a given set of prioritized use cases and based on this develop and unit-test the components following the order of the priorities. and particularly for the custom developed components of the overall business solution. The tested system is the end work product of the phase. the Construction Phase clarifies the remaining requirements and completes the development of the system based upon the baseline architecture. followed by evaluation can be replaced with a more informal and continuous approach. In one sense. the management mind-set changes from the development of intellectual property during Inception and Elaboration. and the result provides the input for the next iteration of the partition. through configuration of standard packaged software functionality. the complete application system is tested.and an assessment of risk. Once the team is comfortable with the approach. Architectural Implementation.those that have a great impact on the architecture of the system -. development and testing of custom components.For projects focused on enhancements to an existing system. During the Elaboration phase. we complete the development of the application system. Back to Phases [C] Construction Phase The goal of the Construction phase is to take the solution from detailed requirements models. All changed or new requirements are evaluated to make certain there has not been a scope change. creating and necessary prototypes. the development team's understanding of the client's business requirements is verified to reduce development risk. often a limited release and often called a beta release. where emphasis is placed on managing resources and controlling operations to optimize costs. the Inception phase is more brief but is still focused on ensuring that the project is both worth doing and achievable. schedules. and integration to a system that is ready for a first release that goes into production.). partitioning the solution. Updates are made to each of the models (Use Case Model. When the development timebox has reached its end. The Elaboration phase delivers the Lifecycle Architecture Milestone. to the development of deployable products during Construction and Transition. and provide MoSCoW priorities for each changed or new requirement. The users validate and refine the requirements. the formal and sequential nature of development followed by walk through. and prepare the system for the Acceptance Test and deployment. In short. Each phase has an anchor point milestone that is explained below: Lifecycle Objective Milestone . and making minor adjustments based on user feedback. user feedback should focus mainly on fine-tuning the product. open and ready for business.Back to Phases [D] Transition Phase The goal of the Transition phase is to take the completed solution from installation onto the production system through the Acceptance Test to launch of the live application. Back to Phases [E] Production Phase The goal of the Production phase is to operate the newly developed system. responding to help requests. installation. if the new system replaces an old one. The Transition phase can span several iterations. error reports and feature requests by users. Ensure that the system is tested systematically and is available for end users. as well as determining. and usability issues. and includes testing the new system in preparation for release. During this phase. This includes monitoring the system and acting appropriately to ensure continued operation. It is important to communicate the milestone to all the stakeholders since it is a point in time where critical decisions should be made and goals evaluated. Back to Phases Back to Top KEY CONCEPTS Milestones Each phase should finish with a well-defined milestone. measuring system performance. a smooth cutover to the new application is provided. operating and maintaining supporting systems. the new system is accepted by the client organization. configuration. The Transition phase delivers the System Production Milestone. the organization is made ready for the new system. developing and implementing required updates. The Production phase delivers the Sign-Off Milestone. assess the success of the system and support the users. At this point in the lifecycle. and managing the applicable change control process so that defects and new features may be prioritized and assigned to future releases and put into a plan for future enhancements to the application system. and the system is put into production and. All the major structural issues should have been resolved earlier in the project lifecycle. the architecture should be stabilized. via the MoSCoW List for re-prioritizing agreed upon requirements and via change requests for additional requirements or for requirements outside the original scope of the project. It is typically expected at the end of the Elaboration phase. infrastructure and users are ready to move to operation. a decision is made on whether the application. most of the requirements should be analyzed and designed. At this point. In either case. the following criteria can be used: • • • • • Is the beta release stable and mature enough to be deployed? Have the users been properly involved to verify the implementation of the functional requirements? Are the non-functional requirements. At this point. At this time. etc. The Initial Operation Capability Milestone is also considered a "beta" release. The following criteria can be used to evaluate this milestone: • • • Is there agreement on the business objectives and are the goals of the project confirmed by all the stakeholders? Are schedule and cost estimates for the remaining phases prepared and communicated? Is there agreement on the requirements of the project? Although. technical architecture. Has the Conceptual Prototype (IM. The following criteria can be used to evaluate this milestone: • • • • • • Is the application architecture.The first key milestone is the Lifecycle Objective Milestone and it is produced at the end of the Inception phase. the requirements are subject to change during the software development. and data architecture stable? Have all the most architecturally significant use cases been analyzed to reveal possible effects on the architecture? Have the architectural risks been mitigated? Is a well-defined plan for the Construction phase in place? Is the offshore team prepared to initiate the construction? Has the estimation been recalculated to take into account information acquired during the first two phases? Initial Operational Capability Milestone The Initial Operational Capability Milestone is the third key project milestone produced at the end of the Construction phase. such as security. the set of functional and non-functional requirements must be confirmed with the stakeholders and well understood by Oracle. reliability.005) been developed and validated with the stakeholders to clarify requirements? • Lifecycle Architecture Milestone The Lifecycle Architecture Milestone is the second key milestone of the project. In order to evaluate this milestone. being adequately addressed? Are all stakeholders ready for the Transition phase? Have appropriate capacity and workload calculations been performed to determine the Production Environment figures? System in Production Milestone . the users. A process is a cohesive set or thread of related tasks that meet a specific project objective. This is the last key project milestone. and are interrelated through common work products. This section describes the key OUM processes. the IS staff. A process results in one or more key work products. At this point all the contractual agreements are closed and staff and physical resources are released or a new project is begun to satisfy additional business requirements within the software system.The System in Production Milestone is produced at the end of the Transition phase. a third party. Every full lifecycle involves most if not all of the following processes. Most processes overlap in time with others. or some combination thereof. You might think of a process as a simultaneous sub-project or workflow within a larger development project. whether they are the responsibility of the development team. • • • • [RD] Business Requirements Process [RA] Requirements Analysis Process [AN] Analysis Process [DS] Design Process . the following criteria can be used: • • • • • • • Are the stakeholders satisfied with the project? Have any arrangements been made for application and database administration and have the staff members been properly trained for this task? Have any arrangements been made for application support and have staff members been properly trained for this task? Does the application system meet the performance requirements? Are the ambassador users able to deliver the application properly to the rest of the organization for internal acceptance? Has Oracle packaged the intellectual capital of the project into reusable components? Have the estimates versus the actual expenditures been correctly reported so the OUM estimation process can be improved? Sign-Off Milestone The Sign-Off Milestone is produced at the end of the Production phase (as far as the engagement goes). In order to evaluate this milestone. Back to Key Concepts Back to Top PROCESSES The overall organization of OUM is expressed by a process-based system engineering methodology. Each process is a discipline that usually involves similar skills to perform the tasks within the process. the stakeholders decide if the goals and objectives set for the project have been met and if a new increment should begin. In addition. At this point. all the intellectual property is preserved. such as the Project Management Plan. it is possible to begin from an agreed on scope and objectives before requirements have been defined. the captured requirements are analyzed and mapped onto the chosen commercial-off-the-shelf (COTS) product set. However. and a high-level description of the software architecture. if any. The Use Case Model is used to document in detail the requirements of the system in a format that both the client and the developers of the system can easily understand. refined and prioritized by a tightly integrated team of empowered ambassador users and experienced analysts.• • • • • • • • • • [IM] Implementation Process [TA] Technical Architecture Process [TE] Testing Process [PT] Performance Management Process [CV] Data Acquisition and Conversion Process [DO] Documentation Process [OCM] Organizational Change Management [TR] Training [TS] Transition Process [PS] Operations and Support Process [RD] Business Requirements Process In the Business Requirements process. The main work products of this process are: the business objectives and goals. the list of functional requirements and the supplemental requirements.010). The main work products of this process are the Use Case Model. Back to Processes [RA] Requirements Analysis Process In the Requirements Analysis process. The business requirements for the proposed system or new enhancements are identified. The Use Case Model is used as the basis for the solution development. a prototype of the user interface. This process helps provide structure and shape to the entire solution. The Business Requirements process delivers a set of requirements models and a prioritized list of requirements as a basis for system development. Back to Processes [AN] Analysis Process During the Analysis process. to ascertain which requirements can be met directly by configuring the product’s capabilities and which requirements will require extending the . Both the models and requirements list are dynamic work products that change as the understanding of the team develops with the system. you define the business needs of the application system. The process often begins from an existing high-level requirements document and a scope document. Validated Scope (PJM SM. the functional and supplemental requirements identified and prioritized during the Business Requirements process are analyzed further into a Use Case Model that is further refined by adding use case details in order to establish a more precise understanding of the requirements. developers also implement and perform testing on software components. The major work products created in this process ultimately combine to form the Design Model that is used during the Implementation process. The main work products of this process is the Reviewed Design Model that includes an object model that describes the design realization of the use cases and design classes that detail the analysis classes outlined in the Analysis Model. the Analysis Model is the collection of all of the analysis related artifacts. Thus. .product capabilities through the development of custom application software or custom extensions. Implementation is the main focus of the Construction phase. Back to Processes [DS] Design Process In the Design process. Most simply put. The Analysis Model is also considered the first cut of the Design Model. it occurs in order to handle any defects or bugs discovered while testing and releasing the system. but it starts early in the Inception phase in order to implement the architecture baseline (trial architecture and prototype). scripts. the final application is developed within the Implementation process. the Architecture Description. Many of the work products produced during the Analysis process describe the dynamics of the system as opposed to the static structure. etc. Beyond product mapping. 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. This form is based on the architecture created and stabilized during the Analysis process. Thus. executables. mostly iterative. In addition. just as the Use Case Model documents the system’s functional requirements. the work products produced during Analysis are an important input into this process. The Analysis Model provides a more precise understanding of the requirements and provides details on the internals of the system. since it contains the analysis classes that will be further detailed during the Design process. it contributes to a sound and stable architecture and facilitates an in-depth understanding of the requirements. In addition. the purpose of Analysis is to refine and structure the requirements via a conceptual object model. During this process. the system is shaped and formed to meet all functional and supplemental requirements. The Design Model can be used to visualize the implementation of the system. During Transition. is enriched with the new Module and Execution Views. called the Analysis Model. The results from the Design process are used to implement the system in terms of source code for components. initially developed in the Business Requirements process and enhanced in both the Requirements Analysis and Analysis processes. Back to Processes [IM] Implementation Process Through a number of steps. Design is the focus during the end of Elaboration phase and the beginning of Construction iterations. new software architecture views are added to the Architecture Description initially developed in the Business Requirements process and further enhanced in the Requirements Analysis process. The main work product of the Analysis process is the Reviewed Analysis Model that includes a set of analysis classes (class diagrams) that realize the use cases. user interfaces and reports) the more they will be able to participate in the Testing process. Performance Management is not limited to conducting a performance test or an isolated tuning exercise. although both those activities may be part of the overall Performance Management strategy. Back to Processes [TA] Technical Architecture Process The goal of the Technical Architecture process is to design an information systems architecture to support and realize the business vision. In addition. the project team executes the test and the final results are documented. working together as an integrated project team. The higher proportion of artifacts that are visible to the ambassador users (for example. Technical analysts create or set up transaction programs to simulate system processing within the scope of the test and populate a volume test database against which to execute the transactions. construct. Back to Processes [PT] Performance Management Process The objective of the Performance Management process is to proactively define. The Testing process presupposes that there is a highly visible user interface from which system events can be driven and results validated. It also includes systems integration testing for projects with requirements for interfaces to external systems. Back to Processes [TE] Testing Process The Testing process is an integrated approach to testing the quality and conformance of all elements of the new system. Testing activities are a shared responsibility of developers. Once the system and database administrators have created the test environment. and execute an effective approach to managing performance throughout the project implementation lifecycle in order to ensure that the performance of the system or system components meet the user's requirements and expectations when the system is implemented. quality assurance engineers. The Performance Management team defines the scope of testing and relates it to point-in-time snapshots of the transactions expected in the real production system. Therefore.The main work product of this process is the final iteration build that is ready to be tested. The tasks in the Technical Architecture process identify and document the requirements related to the establishment and maintenance of the application . it is closely related to the review tasks in the Quality Management (QM) process of PJM and to the definition and refinement of requirements in the Business Requirements process. the High-Level Software Architecture Description initially developed in the Requirements Analysis process is also enriched with the Implementation View to create the Architectural Implementation. It addresses mainly functional testing. The requirements that drive Performance Management also impact Technical Architecture (TA) and the two processes are closely related. and ambassador users. For projects that include Oracle Application products. transform. By exposing its business systems to the Web. monitor and maintain the various environments are established and tested. Processes and procedures required to implement. technology. In such situations. a business is exposing itself to unpredictable load levels and. Back to Processes [DO] Documentation Process Quality documentation is a key factor in supporting the transition to production. and testing any conversion modules that are necessary as well as the conversion itself. The Technical Architecture process specifies elements of the technical infrastructure of the development project. If data anomalies exist in the current system(s). achieving user acceptance. Back to Processes . the importance of the technical infrastructure cannot be overstated. This data may be needed for system testing. and acceptance testing as well as for production. transport and load the legacy source data to support the information needs of the new system. In some cases. The requirements and strategy for this process vary based upon project scope. sometimes. coding. It assumes that the business already has an information system strategy and that these elements fit within that strategy. or there are an unusual number of exceptions. There must be a sharp focus on the technical infrastructure in a OUM-based solution deployment project. it is beneficial to convert (some) data at earlier stages to provide as realistic as possible reviews of the components during the development iterations. Back to Processes [CV] Data Acquisition and Conversion Process The objective of the Data Acquisition and Conversion process is to create the components necessary to extract. and requirements. you need to thoroughly analyze the existing systems. The cleaning of legacy data is visibly identified as a user and client project staff task so that it can be staffed and scheduled. along with its sources. the Oracle Application manuals are the foundation of implementation documentation. map them to the new data model. a hostile security environment. 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. and maintaining the ongoing business process. you should recommend data clean-up to the project sponsor.and technical infrastructure environment for the project. you should consider running this as a separate project in parallel to the development project. training. and build multiple conversion modules of various complexities. and most all of the data needs to be converted. The process includes designing. Therefore. For large projects. The Documentation process will develop documentation to augment the standard Oracle Application products manuals with specific information about the organization's custom software extensions and specific business procedures. The data that is required to be converted is explicitly defined. where large existing systems will be replaced. In fact. There are certain to be requirements with lower priorities that have not been implemented. Back to Processes [PS] Operations and Support Process The goal of the Operations and Support process is to monitor and respond to system problems. The Could Have requirements and any remaining Should Haves can now be re-prioritized into an Enhancement Plan. carefully planning for and managing change in this way allows organization’s to maintain productivity through often-difficult technological transitions. Internal auditors have not yet produced the System Evaluation. and users most likely still have a few problems to uncover. Back to Processes [TR] Training Process The objective of the Training process is to make sure that the project team is adequately trained to begin the tasks necessary to start the project and the users are adequately trained to take on the tasks of running the new application system. In addition to increasing user adoption rates. and maximize return on investment. from which upgrades can be defined. It then includes tasks to carry out the elements of that strategy such as developing an Installation Plan. This in turn enables the organization to more easily meet deadlines. time-sensitive. the months following that milestone can determine the real success or failure of the project. Back to Processes [TS] Transition Process The goal of the Transition process is to install the solution (which includes providing installation procedures) and then take it into production. and cost-effective approach to lowering risk that is tailored to each organization’s specific needs. The development project does not come to an abrupt end when the team installs the application system into production. and decommissioning any legacy systems. preparing the Production Environment. performing the cutover. evaluate the system in production and plan enhancements for increased functionality. realize business objectives. It begins early in the project by defining the specific requirements for cutover to the new application system. improved performance.[OCM] Organizational Change Management Process The Organizational Change Management process starts at the strategic level with executives and then identifies the particular human and organizational challenges of the technology implementation in order to design a systematic. Back to Processes . and tighter security. upgrade the application to fix errors and performance problems. as well as the number of iterations (times the activity is repeated) within an increment.Elaboration Develop Use Cases Create Conceptual Prototype . the following major activities have been identified: Inception Phase Activities • • • • • • • • • • • • • • Gather Business Requirements Requirements . are variable. Within the OUM phases. or to refine and expand them on the basis of user feedback.Back to Top ACTIVITIES OUM tasks are further refined into activities to better represent the OUM Project lifecycle.Elaboration Design .Elaboration Perform Fit Gap Specify Software Configuration Baseline Software Architecture Analyze .Elaboration Consolidate Specification Define Project Strategy Define Infrastructure Develop Test Plans Prepare Environments .Inception Conduct Organizational Readiness Assessment Deploy Change Management Roadmap / Communication Campaign . to add sufficient level of detail. Therefore.Inception Gather Supporting Requirements Specify Key Structure Definition Create and Manage Ad Hoc Communication Conduct Executive Alignment Workshop Train Project Team Conduct Alignment Workshops .Inception Establish Current Business Baseline Gather Solution Requirements Perform Software Upgrade Impact Analysis Consolidate Solution Requirements Create Conceptual Prototype . Activities may be iterated to either increase the quality of the work products to a desired level. any activity (and its tasks) may be iterated. Whether or not to iterate. OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems.Elaboration Develop Prototypes Validate Prototypes .Inception Elaboration Phase Activities • • • • • • • • • • • • • • • Gather Business Requirements . Construction Transition Phase Activities • • • • • • • • Support User Acceptance Test Conduct Performance Test Convert Data -Transition Deploy Change Management Roadmap / Communication Campaign .Elaboration Monitor Sponsorship Program Deploy Change Management Roadmap / Communication Campaign .Transition Finalize Documentation Go Production Production Phase Activities • • Manage Production System Performance Evaluate Production System .Construction Validate Upgrade Process .Construction Acquire and Convert Data .Construction Conduct Job Impact Analysis Conduct Managers' Alignment Workshop .Elaboration Perform System Test .Elaboration Plan Performance Management Prepare to Acquire and Convert Data .Construction Design End-User Training Build End-User Training Train End Users .Construction Produce Documentation Deploy Change Management Roadmap / Communication Campaign .Construction Design .• • • • • • • • Perform Unit Test .Elaboration Construction Phase Activities • • • • • • • • • • • • • • • • • • • • • • • • Finalize Requirements Analyze .Construction Perform System Test .Elaboration Validate Upgrade Process .Construction Perform Test Planning Prepare Environments .Transition Conduct IT Alignment Train End Users .Construction Perform Integration Test .Elaboration Perform Integration Test .Construction Conduct Systems Integration Test Prepare for Performance Testing Prepare for Transition Prepare for Cutover Test Infrastructure Prepare to Acquire and Convert Data .Construction Implement System Perform Unit Test . • • • • • Resolve Production Problems Upgrade System Deploy Change Management Roadmap / Communication Campaign . Back to Top . You should read the Manage focus area overview to gain a better understanding of this focus area.Production Plan for Future Deploy IT Transition Plan Back to Top MANAGING OUM uses the Manage focus area.