You are on page 1of 26


024 Use Case Use Case Model Visio Template and Stencil Use Case Elaboration Elaboration .011 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.065 RA.005 RD.ID RD.030 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.

085 Elaboration DS.010 Functional Prototype Validated Functional Prototype Business Data Structure Setups Business Data Structures Application Setup Documents Data Analysis Elaboration RA. Refer to the Task Overview for guidance.050 . Application Setup Documents Analysis Model Map Requirements Elaboration AN.040 Elaboration DS. Validated Functional Prototype Business Data Structure Setups Refer to the Task Overview for guidance.010 Configure Inception RA.Details 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. Refer to the Task Overview for guidance.030 Elaboration Analyze and Desi AN.030 Elaboration IM.020 Elaboration AN.

Inception RD001 Business and System Objectives .

. and (3) predefined demo/test scripts based on the pre-defined setup values. 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. etc. the foundational elements of the business solution are already reflected in the components that comprise the pre-defined solution. customizations by promoting leading practice use of standard functionality to meet common business needs. which can be used to demonstrate the functionality included. or minimize.Solution-Driven Approach An approach that is based on the use of a pre-defined business solution (e. Oracle Business Accelerators) as the proposed client business solution and tailoring that solution to the client's requirements during the project. In a solution-driven approach. In general.g. and crafting a business solution based on those requirements during the project. process modeling workshops. In an Oracle COTS implementation this typically consists of (1) business process models (or business flows) depicting the functionality included... The solution-driven approach seeks to avoid.

Those are: • • • • • Iterative and Incremental Business Process and Use Case-Driven Architecture-Centric Flexible and Scalable Risk-Focused . OUM's Manage Focus Area provides a framework in which all types of projects can be planned. Envision. architecture. and completed in a consistent manner. The Implement Focus Area provides a framework to develop and implement Oracle-based business solutions with precise development and rapid deployment. estimated. controlled. and Implement. and Oracle's existing methods. Envision also assists in the transition from enterprise-level planning and strategy activities to the identification and initiation of specific projects. and governance. the Dynamic Systems Development Method. OUM Approach OUM is built on five main principles derived from the Unified Process.OUM Overview OUM includes three Focus Areas – Manage. OUM’s Envision Focus Area deals with development and maintenance of enterprise level IT strategy.

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. system size.Construction. Management processes are documented in Oracle’s Project Management Method (PJM).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.Elaboration.Transition.Inception. These features are embodied within a framework that supports the complete software development and implementation lifecycle. team size. The diagram below illustrates a typical OUM project. and business-focused. 2 .4 . The relative amount of effort performed in each process. The number of iterations can vary from as few as 3 (for example: 1 . etc. with a typical number of iterations. 3 . and therefore. .Transition) to as many as 12 or more (for example. approach to Implementation. 1 .Elaboration. 1 . 1 .Production). technical and programmatic risk. multiple iterations of the entire lifecycle to fulfill all of the business requirements. 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.OUM 5. during each iteration is represented by the height of the colored bars for each process. which is part of the OUM Manage focus area OUM Approach The OUM implementation architecture provides a rapid. 5 . Projects may also employ multiple production releases. OUM documents the execution processes.Construction. adaptive. 1 .

it is useful to set timeboxes for use case refinements. and for post-production support." OUM and UML . testing. for some prototypes. for some architectural discussions.Timeboxing is a powerful planning and controlling technique for some objectives. It is a technique that reduces the risk of "analysis paralysis. For example.

OUM recognizes the well-proven advantages of an iterative and incremental approach to development and deployment of information systems. The diagram below illustrates the how the UML models developed during a OUM project are related. UML enables OUM to support modeling of the application architecture. Process Models and UML Occur in these OUM Tasks . For further reading on Agile Software Development. and technical architectures. Some techniques from Extreme Programming (XP) and Agile Software Development are already included in OUM. see Extreme Programming Explained. software systems. see Agile Software Development. Oracle will continue to evaluate new techniques for inclusion in OUM. structure and behavior. Today. As the software industry continues to mature.OUM technology implementation employs the Unified Modeling Language (UML) as the basis for modeling business processes. For further reading on Extreme Programming.

OUM was created with Process Models and UML Models in these Tasks: .

OUM Implementation and Blended Delivery .

Each of these phases culminates in an anchor point milestone. Many of the Business Requirements (RD) and Requirement Analysis (RA) tasks are completed during workshops with client involvement. The Inception phase delivers the Lifecycle Objective Milestone. additional review tasks are added for the offshore resources in the Inception and Elaboration phases. or with Blended Delivery (staffing with Onsite resources and with Offshore Onsite and Offshore Remote resources). The creation of more detailed models and specifications also becomes more critical for the onsite team when blended delivery is used. and scope of the project are defined and the project's feasibility is established during requirements gathering activities. The business objectives. Where the Unified Process has four (4) phases: Inception. see "Anchoring the Software Process. 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. An Iteration Workplan is developed to define the details of the work to be performed in the first Iteration of the Elaboration phase.indicators of the progress of the project. these review tasks with the offshore team are critical. Elaboration. With Blended Delivery. which produce the high-level business models. These milestones. Therefore. For more information on applying Blended Delivery to a OUM project. For further reading on milestones. When Blended Delivery channels are used. and Transition. the highlevel requirements and the significant risks must be understood before the project can proceed. . Risks and mitigation strategies are identified.OUM was created with the option of Traditional delivery (staffing with Onsite resources). Construction. the Inception phase is critical for all projects because the scope of the effort. goals. As requirements are defined they are also prioritized in relation to their business benefits. Where applicable and possible. adopted as phase gates by the Unified Process and by Oracle Unified Method. Back to Top PHASES OUM organizes the delivery of software implementation projects along several phases ." 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. the functionality is partitioned to enable parallel development by separate teams of ambassador users and highly skilled Information Technology professionals. Production to better cover the software engineering lifecycle. OUM adds a 5th phase. see the Blended Delivery guidelines. 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.

through configuration of standard packaged software functionality. development and testing of custom components. Design Model. The Construction phase delivers the Initial Operational Capability Milestone. In short. At this point. partitioning the solution. The tested system is the end work product of the phase. The architecture evolves from the most significant requirements -. the complete application system is tested. and the result provides the input for the next iteration of the partition. the management mind-set changes from the development of intellectual property during Inception and Elaboration. and provide MoSCoW priorities for each changed or new requirement. 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. Back to Phases [C] Construction Phase The goal of the Construction phase is to take the solution from detailed requirements models. creating and necessary prototypes. All changed or new requirements are evaluated to make certain there has not been a scope change. 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 Inception phase is more brief but is still focused on ensuring that the project is both worth doing and achievable.and an assessment of risk. the development team's understanding of the client's business requirements is verified to reduce development risk. When the development timebox has reached its end. and particularly for the custom developed components of the overall business solution. as the requirements are progressively refined. and quality. . etc. followed by evaluation can be replaced with a more informal and continuous approach.those that have a great impact on the architecture of the system -. 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. the Construction Phase clarifies the remaining requirements and completes the development of the system based upon the baseline architecture. and baselining the architecture of the system to provide a stable basis for the design and implementation effort in the Construction phase.For projects focused on enhancements to an existing system. Once the team is comfortable with the approach. The users validate and refine the requirements. During the Elaboration phase. Updates are made to each of the models (Use Case Model. ensure that all components fit together. In one sense. to the development of deployable products during Construction and Transition. the Construction phase is a manufacturing process. The modified or new requirements are fed back to the requirement models in the business layer. Architectural Implementation. we complete the development of the application system.). the developer walks through the changes with the users. and prepare the system for the Acceptance Test and deployment. When all of the planned iterations have been completed for each partition. The Elaboration phase delivers the Lifecycle Architecture Milestone. The application system is completed within a pre-defined number of iterations. For each iteration. schedules. where emphasis is placed on managing resources and controlling operations to optimize costs. the formal and sequential nature of development followed by walk through. The stability of the architecture is evaluated through one or more architectural prototypes. In more detail.

operating and maintaining supporting systems. The Transition phase delivers the System Production Milestone. developing and implementing required updates. This includes monitoring the system and acting appropriately to ensure continued operation. user feedback should focus mainly on fine-tuning the product. 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. the new system is accepted by the client organization. Each phase has an anchor point milestone that is explained below: Lifecycle Objective Milestone . The Production phase delivers the Sign-Off Milestone. open and ready for business. responding to help requests. measuring system performance. Back to Phases [E] Production Phase The goal of the Production phase is to operate the newly developed system. All the major structural issues should have been resolved earlier in the project lifecycle. if the new system replaces an old one. and includes testing the new system in preparation for release. and making minor adjustments based on user feedback. the organization is made ready for the new system. a smooth cutover to the new application is provided. installation. configuration. 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. During this phase. error reports and feature requests by users. as well as determining. At this point in the lifecycle. Back to Phases Back to Top KEY CONCEPTS Milestones Each phase should finish with a well-defined milestone. The Transition phase can span several iterations. assess the success of the system and support the users.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. and usability issues. Ensure that the system is tested systematically and is available for end users. and the system is put into production and.

such as security. In either case. 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. Has the Conceptual Prototype (IM. most of the requirements should be analyzed and designed.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. a decision is made on whether the application. 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. 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. 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. the architecture should be stabilized. the requirements are subject to change during the software development. technical architecture. reliability. The Initial Operation Capability Milestone is also considered a "beta" release. the set of functional and non-functional requirements must be confirmed with the stakeholders and well understood by Oracle. infrastructure and users are ready to move to operation. 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 . At this time. It is typically expected at the end of the Elaboration phase. 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. In order to evaluate this milestone. etc. At this point.

and are interrelated through common work products. This section describes the key OUM processes. A process results in one or more key work products. Most processes overlap in time with others. In order to evaluate this milestone. In addition. A process is a cohesive set or thread of related tasks that meet a specific project objective. Each process is a discipline that usually involves similar skills to perform the tasks within the process. Every full lifecycle involves most if not all of the following processes. or some combination thereof. 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). the stakeholders decide if the goals and objectives set for the project have been met and if a new increment should begin. Back to Key Concepts Back to Top PROCESSES The overall organization of OUM is expressed by a process-based system engineering methodology. This is the last key project milestone. At this point. 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. a third party. all the intellectual property is preserved. • • • • [RD] Business Requirements Process [RA] Requirements Analysis Process [AN] Analysis Process [DS] Design Process . You might think of a process as a simultaneous sub-project or workflow within a larger development project. the IS staff. the users. whether they are the responsibility of the development team.The System in Production Milestone is produced at the end of the Transition phase.

it is possible to begin from an agreed on scope and objectives before requirements have been defined. The main work products of this process are: the business objectives and goals. and a high-level description of the software architecture. Both the models and requirements list are dynamic work products that change as the understanding of the team develops with the system. The business requirements for the proposed system or new enhancements are identified.010). However. such as the Project Management Plan. Back to Processes [RA] Requirements Analysis Process In the Requirements Analysis process. 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. 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. the captured requirements are analyzed and mapped onto the chosen commercial-off-the-shelf (COTS) product set. the list of functional requirements and the supplemental requirements. The main work products of this process are the Use Case Model. to ascertain which requirements can be met directly by configuring the product’s capabilities and which requirements will require extending the . The Use Case Model is used as the basis for the solution development. a prototype of the user interface.• • • • • • • • • • [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. This process helps provide structure and shape to the entire solution. The process often begins from an existing high-level requirements document and a scope document. if any. Validated Scope (PJM SM. you define the business needs of the application system. refined and prioritized by a tightly integrated team of empowered ambassador users and experienced analysts. 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.

The major work products created in this process ultimately combine to form the Design Model that is used during the Implementation process. it occurs in order to handle any defects or bugs discovered while testing and releasing the system. the Architecture Description. is enriched with the new Module and Execution Views. During Transition. The Analysis Model provides a more precise understanding of the requirements and provides details on the internals of the system. Design is the focus during the end of Elaboration phase and the beginning of Construction iterations. the work products produced during Analysis are an important input into this process. In addition. 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.product capabilities through the development of custom application software or custom extensions. etc. since it contains the analysis classes that will be further detailed during the Design process. . This form is based on the architecture created and stabilized during the 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. Many of the work products produced during the Analysis process describe the dynamics of the system as opposed to the static structure. The Design Model can be used to visualize the implementation of the system. Thus. but it starts early in the Inception phase in order to implement the architecture baseline (trial architecture and prototype). In addition. 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. scripts. Back to Processes [DS] Design Process In the Design process. The results from the Design process are used to implement the system in terms of source code for components. 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. developers also implement and perform testing on software components. Implementation is the main focus of the Construction phase. the Analysis Model is the collection of all of the analysis related artifacts. the system is shaped and formed to meet all functional and supplemental requirements. Most simply put. the final application is developed within the Implementation process. Beyond product mapping. During this process. called the Analysis Model. it contributes to a sound and stable architecture and facilitates an in-depth understanding of the requirements. initially developed in the Business Requirements process and enhanced in both the Requirements Analysis and Analysis processes. Thus. The Analysis Model is also considered the first cut of the Design Model. just as the Use Case Model documents the system’s functional requirements. the purpose of Analysis is to refine and structure the requirements via a conceptual object model. executables. Back to Processes [IM] Implementation Process Through a number of steps. mostly iterative.

The main work product of this process is the final iteration build that is ready to be tested. user interfaces and reports) the more they will be able to participate in the Testing process. 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. In addition. 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. Therefore. The tasks in the Technical Architecture process identify and document the requirements related to the establishment and maintenance of the application . Back to Processes [PT] Performance Management Process The objective of the Performance Management process is to proactively define. construct. 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. 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. although both those activities may be part of the overall Performance Management strategy. 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. The requirements that drive Performance Management also impact Technical Architecture (TA) and the two processes are closely related. 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. Testing activities are a shared responsibility of developers. The higher proportion of artifacts that are visible to the ambassador users (for example. Once the system and database administrators have created the test environment. and ambassador users. the project team executes the test and the final results are documented. working together as an integrated project team. 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. It addresses mainly functional testing. It also includes systems integration testing for projects with requirements for interfaces to external systems. Performance Management is not limited to conducting a performance test or an isolated tuning exercise. The Testing process presupposes that there is a highly visible user interface from which system events can be driven and results validated. quality assurance engineers.

and requirements. along with its sources. it is beneficial to convert (some) data at earlier stages to provide as realistic as possible reviews of the components during the development iterations. coding. The Technical Architecture process specifies elements of the technical infrastructure of the development project. map them to the new data model. you should consider running this as a separate project in parallel to the development project. Back to Processes . 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. 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. By exposing its business systems to the Web. The data that is required to be converted is explicitly defined. It assumes that the business already has an information system strategy and that these elements fit within that strategy. technology.and technical infrastructure environment for the project. In such situations. monitor and maintain the various environments are established and tested. you should recommend data clean-up to the project sponsor. transform. the importance of the technical infrastructure cannot be overstated. The requirements and strategy for this process vary based upon project scope. the Oracle Application manuals are the foundation of implementation documentation. There must be a sharp focus on the technical infrastructure in a OUM-based solution deployment project. achieving user acceptance. For large projects. and build multiple conversion modules of various complexities. or there are an unusual number of exceptions. For projects that include Oracle Application products. 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. where large existing systems will be replaced. If data anomalies exist in the current system(s). In some cases. Back to Processes [DO] Documentation Process Quality documentation is a key factor in supporting the transition to production. sometimes. transport and load the legacy source data to support the information needs of the new system. The cleaning of legacy data is visibly identified as a user and client project staff task so that it can be staffed and scheduled. Processes and procedures required to implement. and acceptance testing as well as for production. training. a business is exposing itself to unpredictable load levels and. and testing any conversion modules that are necessary as well as the conversion itself. This data may be needed for system testing. you need to thoroughly analyze the existing systems. Therefore. and maintaining the ongoing business process. The process includes designing. and most all of the data needs to be converted. a hostile security environment.

It then includes tasks to carry out the elements of that strategy such as developing an Installation Plan. and maximize return on investment. realize business objectives. Back to Processes . Internal auditors have not yet produced the System Evaluation. In fact. upgrade the application to fix errors and performance problems. and tighter security. evaluate the system in production and plan enhancements for increased functionality. 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. It begins early in the project by defining the specific requirements for cutover to the new application system. The Could Have requirements and any remaining Should Haves can now be re-prioritized into an Enhancement Plan. and cost-effective approach to lowering risk that is tailored to each organization’s specific needs. and users most likely still have a few problems to uncover. time-sensitive. Back to Processes [PS] Operations and Support Process The goal of the Operations and Support process is to monitor and respond to system problems. This in turn enables the organization to more easily meet deadlines.[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. The development project does not come to an abrupt end when the team installs the application system into production. performing the cutover. preparing the Production Environment. and decommissioning any legacy systems. carefully planning for and managing change in this way allows organization’s to maintain productivity through often-difficult technological transitions. 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. improved performance. from which upgrades can be defined. There are certain to be requirements with lower priorities that have not been implemented. the months following that milestone can determine the real success or failure of the project.

Inception Conduct Organizational Readiness Assessment Deploy Change Management Roadmap / Communication Campaign .Elaboration Consolidate Specification Define Project Strategy Define Infrastructure Develop Test Plans Prepare Environments .Elaboration Perform Fit Gap Specify Software Configuration Baseline Software Architecture Analyze . any activity (and its tasks) may be iterated. the following major activities have been identified: Inception Phase Activities • • • • • • • • • • • • • • Gather Business Requirements Requirements . OUM is Oracle's approach to Unified Process. or to refine and expand them on the basis of user feedback.Inception Establish Current Business Baseline Gather Solution Requirements Perform Software Upgrade Impact Analysis Consolidate Solution Requirements Create Conceptual Prototype .Back to Top ACTIVITIES OUM tasks are further refined into activities to better represent the OUM Project lifecycle. Therefore. are variable.Inception Elaboration Phase Activities • • • • • • • • • • • • • • • Gather Business Requirements . Activities may be iterated to either increase the quality of the work products to a desired level. UP is an iterative and incremental approach to developing and implementing software systems. Whether or not to iterate. to add sufficient level of detail.Elaboration Develop Use Cases Create Conceptual Prototype .Elaboration Design . as well as the number of iterations (times the activity is repeated) within an increment. Within the OUM phases.Elaboration Develop Prototypes Validate Prototypes .Inception Gather Supporting Requirements Specify Key Structure Definition Create and Manage Ad Hoc Communication Conduct Executive Alignment Workshop Train Project Team Conduct Alignment Workshops .

• • • • • • • • Perform Unit Test .Elaboration Plan Performance Management Prepare to Acquire and Convert Data .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 .Construction Validate Upgrade Process .Construction Produce Documentation Deploy Change Management Roadmap / Communication Campaign .Elaboration Perform System Test .Construction Acquire and Convert Data .Construction Design End-User Training Build End-User Training Train End Users .Elaboration Construction Phase Activities • • • • • • • • • • • • • • • • • • • • • • • • Finalize Requirements Analyze .Construction Implement System Perform Unit Test .Elaboration Validate Upgrade Process .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 Design .Construction Perform Test Planning Prepare Environments .Construction Conduct Job Impact Analysis Conduct Managers' Alignment Workshop .Transition Finalize Documentation Go Production Production Phase Activities • • Manage Production System Performance Evaluate Production System .Construction Perform Integration Test .Transition Conduct IT Alignment Train End Users .Construction Perform System Test .

Production Plan for Future Deploy IT Transition Plan Back to Top MANAGING OUM uses the Manage focus area. Back to Top .• • • • • Resolve Production Problems Upgrade System Deploy Change Management Roadmap / Communication Campaign . You should read the Manage focus area overview to gain a better understanding of this focus area.