ID RD.

001

Task Detail Business and System Objectives

Work Product Business and System Objectives

Template Business and System Objectives Objectives Inception

RD.005 RD.011 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.065

RA.023

Develop Domain Model (Business Entities) Develop Use Case Model Develop Use Case

Domain Model

Inception

Use Case Model

RA.024

Use Case

Use Case Model Visio Template and Stencil Use Case

Elaboration

Elaboration

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. Refer to the Task Overview for guidance. Validated Functional Prototype Business Data Structure Setups Refer to the Task Overview for guidance. Application Setup Documents Analysis Model Map Requirements Elaboration

AN.020

Elaboration

AN.030

Elaboration

IM.010

Functional Prototype Validated Functional Prototype Business Data Structure Setups Business Data Structures Application Setup Documents Data Analysis

Elaboration

RA.085

Elaboration

DS.010

Configure Inception

RA.040

Elaboration

DS.030

Elaboration

Analyze and Desi AN.050

Inception RD001 Business and System Objectives

Solution-Driven Approach
An approach that is based on the use of a pre-defined business solution (e.g., 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, the foundational elements of the business solution are already reflected in the components that comprise the pre-defined solution. In an Oracle COTS implementation this typically consists of (1) business process models (or business flows) depicting the functionality included, (2) pre-determined setup values that enable a working application instance to be established quickly for familiarization/mapping purposes, and (3) predefined demo/test scripts based on the pre-defined setup values, which can be used to demonstrate the functionality included. In general, The solution-driven approach seeks to avoid, or minimize, customizations by promoting leading practice use of standard functionality to meet common business needs.

Requirements-Driven Approach
An approach that is based on identifying requirements at the outset of the project through interviews, process modeling workshops, etc., and crafting a business solution based on those requirements during the project.

OUM Overview OUM includes three Focus Areas Manage, Envision, and Implement. OUM's Manage Focus Area provides a framework in which all types of projects can be planned, estimated, controlled, and completed in a consistent manner. OUMs Envision Focus Area deals with development and maintenance of enterprise level IT strategy, architecture, and governance. Envision also assists in the transition from enterprise-level planning and strategy activities to the identification and initiation of specific projects. The Implement Focus Area provides a framework to develop and implement Oracle-based business solutions with precise development and rapid deployment.

OUM Approach
OUM is built on five main principles derived from the Unified Process, the Dynamic Systems Development Method, and Oracle's existing methods. Those are: Iterative and Incremental Business Process and Use Case-Driven Architecture-Centric Flexible and Scalable Risk-Focused

OUM 5.4 - 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.

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. OUM documents the execution processes. Management processes are documented in Oracles Project Management Method (PJM), which is part of the OUM Manage focus area

OUM Approach
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 below 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 including scope, technical and programmatic risk, system size, team size, etc. The number of iterations can vary from as few as 3 (for example: 1 - Elaboration, 1 - Construction, 1 - Transition) to as many as 12 or more (for example; 1 - Inception, 3 - Elaboration, 5 - Construction, 2 - Transition, 1 - Production). Projects may also employ multiple production releases, and therefore, multiple iterations of the entire lifecycle to fulfill all of the business requirements.

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

OUM and UML

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

Process Models and UML Occur in these OUM Tasks

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

OUM Implementation and Blended Delivery

OUM was created with the option of Traditional delivery (staffing with Onsite resources), or with Blended Delivery (staffing with Onsite resources and with Offshore Onsite and Offshore Remote resources). Many of the Business Requirements (RD) and Requirement Analysis (RA) tasks are completed during workshops with client involvement. When Blended Delivery channels are used, additional review tasks are added for the offshore resources in the Inception and Elaboration phases. With Blended Delivery, these review tasks with the offshore team are critical. The creation of more detailed models and specifications also becomes more critical for the onsite team when blended delivery is used. For more information on applying Blended Delivery to a OUM project, see the Blended Delivery guidelines.

Back to Top

PHASES
OUM organizes the delivery of software implementation projects along several phases - indicators of the progress of the project. Each of these phases culminates in an anchor point milestone. These milestones, adopted as phase gates by the Unified Process and by Oracle Unified Method, 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. For further reading on milestones, see "Anchoring the Software Process." 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. Where the Unified Process has four (4) phases: Inception, Elaboration, Construction, and Transition, OUM adds a 5th phase, Production to better cover the software engineering lifecycle. 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. The Inception phase delivers the Lifecycle Objective Milestone. Therefore, the Inception phase is critical for all projects because the scope of the effort, the highlevel requirements and the significant risks must be understood before the project can proceed. The business objectives, goals, and scope of the project are defined and the project's feasibility is established during requirements gathering activities, which produce the high-level business models. As requirements are defined they are also prioritized in relation to their business benefits. Where applicable and possible, the functionality is partitioned to enable parallel development by separate teams of ambassador users and highly skilled Information Technology professionals. Risks and mitigation strategies are identified. An Iteration Workplan is developed to define the details of the work to be performed in the first Iteration of the Elaboration phase.

For projects focused on enhancements to an existing system, the Inception phase is more brief but is still focused on ensuring that the project is both worth doing and achievable.

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, partitioning the solution, creating and necessary prototypes, and baselining the architecture of the system to provide a stable basis for the design and implementation effort in the Construction phase. The Elaboration phase delivers the Lifecycle Architecture Milestone. The architecture evolves from the most significant requirements -- those that have a great impact on the architecture of the system -- and an assessment of risk. The stability of the architecture is evaluated through one or more architectural prototypes. During the Elaboration phase, the development team's understanding of the client's business requirements is verified to reduce development risk.

Back to Phases

[C] Construction Phase

The goal of the Construction phase is to take the solution from detailed requirements models, through configuration of standard packaged software functionality, development and testing of custom components, and integration to a system that is ready for a first release that goes into production, often a limited release and often called a beta release. In short, we complete the development of the application system, ensure that all components fit together, and prepare the system for the Acceptance Test and deployment. The Construction phase delivers the Initial Operational Capability Milestone. In more detail, the Construction Phase clarifies the remaining requirements and completes the development of the system based upon the baseline architecture. In one sense, and particularly for the custom developed components of the overall business solution, the Construction phase is a manufacturing process, where emphasis is placed on managing resources and controlling operations to optimize costs, schedules, and quality. At this point, the management mind-set changes from the development of intellectual property during Inception and Elaboration, to the development of deployable products during Construction and Transition. The application system is completed within a pre-defined number of iterations. Updates are made to each of the models (Use Case Model, Design Model, Architectural Implementation, etc.), as the requirements are progressively refined. For each iteration, 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. When the development timebox has reached its end, the developer walks through the changes with the users. The users validate and refine the requirements, and provide MoSCoW priorities for each changed or new requirement. The modified or new requirements are fed back to the requirement models in the business layer. All changed or new requirements are evaluated to make certain there has not been a scope change, and the result provides the input for the next iteration of the partition. Once the team is comfortable with the approach, the formal and sequential nature of development followed by walk through, followed by evaluation can be replaced with a more informal and continuous approach. When all of the planned iterations have been completed for each partition, the complete application system is tested. The tested system is the end work product of the phase.

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, open and ready for business. Ensure that the system is tested systematically and is available for end users. During this phase, the new system is accepted by the client organization, the organization is made ready for the new system, and the system is put into production and, if the new system replaces an old one, a smooth cutover to the new application is provided. The Transition phase delivers the System Production Milestone. The Transition phase can span several iterations, and includes testing the new system in preparation for release, and making minor adjustments based on user feedback. At this point in the lifecycle, user feedback should focus mainly on fine-tuning the product, configuration, installation, and usability issues. All the major structural issues should have been resolved earlier in the project lifecycle.

Back to Phases

[E] Production Phase

The goal of the Production phase is to operate the newly developed system, assess the success of the system and support the users. This includes monitoring the system and acting appropriately to ensure continued operation, measuring system performance, operating and maintaining supporting systems, responding to help requests, error reports and feature requests by users, 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, as well as determining, developing and implementing required updates. The Production phase delivers the Sign-Off Milestone.

Back to Phases

Back to Top

KEY CONCEPTS Milestones

Each phase should finish with a well-defined milestone. 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. Each phase has an anchor point milestone that is explained below: Lifecycle Objective Milestone

The first key milestone is the Lifecycle Objective Milestone and it is produced at the end of the Inception phase. 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, the requirements are subject to change during the software development, 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 either case, the set of functional and non-functional requirements must be confirmed with the stakeholders and well understood by Oracle. Has the Conceptual Prototype (IM.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. It is typically expected at the end of the Elaboration phase. At this point, most of the requirements should be analyzed and designed. At this time, the architecture should be stabilized. The following criteria can be used to evaluate this milestone: Is the application architecture, technical architecture, 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. At this point, a decision is made on whether the application, infrastructure and users are ready to move to operation. The Initial Operation Capability Milestone is also considered a "beta" release. In order to evaluate this milestone, 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, such as security, reliability, etc. 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 System in Production Milestone is produced at the end of the Transition phase. At this point, the stakeholders decide if the goals and objectives set for the project have been met and if a new increment should begin. In order to evaluate this milestone, 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). This is the last key project milestone. 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. In addition, all the intellectual property is preserved.

Back to Key Concepts

Back to Top

PROCESSES
The overall organization of OUM is expressed by a process-based system engineering methodology. A process is a cohesive set or thread of related tasks that meet a specific project objective. A process results in one or more key work products. Each process is a discipline that usually involves similar skills to perform the tasks within the process. You might think of a process as a simultaneous sub-project or workflow within a larger development project. Every full lifecycle involves most if not all of the following processes, whether they are the responsibility of the development team, the users, the IS staff, a third party, or some combination thereof. Most processes overlap in time with others, and are interrelated through common work products. This section describes the key OUM processes. [RD] Business Requirements Process [RA] Requirements Analysis Process [AN] Analysis Process [DS] Design Process

[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, you define the business needs of the application system. The business requirements for the proposed system or new enhancements are identified, refined and prioritized by a tightly integrated team of empowered ambassador users and experienced analysts. The process often begins from an existing high-level requirements document and a scope document, such as the Project Management Plan, Validated Scope (PJM SM.010). However, it is possible to begin from an agreed on scope and objectives before requirements have been defined. The Business Requirements process delivers a set of requirements models and a prioritized list of requirements as a basis for system development. Both the models and requirements list are dynamic work products that change as the understanding of the team develops with the system. The main work products of this process are: the business objectives and goals, the list of functional requirements and the supplemental requirements.

Back to Processes

[RA] Requirements Analysis Process

In the Requirements Analysis process, 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 Use Case Model is used as the basis for the solution development. This process helps provide structure and shape to the entire solution. 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 main work products of this process are the Use Case Model, a prototype of the user interface, and a high-level description of the software architecture.

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, if any, to ascertain which requirements can be met directly by configuring the products capabilities and which requirements will require extending the

product capabilities through the development of custom application software or custom extensions. Beyond product mapping, the purpose of Analysis is to refine and structure the requirements via a conceptual object model, called the Analysis Model. Most simply put, the Analysis Model is the collection of all of the analysis related artifacts, just as the Use Case Model documents the systems functional requirements. The Analysis Model provides a more precise understanding of the requirements and provides details on the internals of the system. The Analysis Model is described using the language of the developers as opposed to the requirements obtained in the Business Requirements and Requirements Analysis processes where the emphasis is on the functionality of the system expressed in the language of the client. Thus, it contributes to a sound and stable architecture and facilitates an in-depth understanding of the requirements. Many of the work products produced during the Analysis process describe the dynamics of the system as opposed to the static structure. The Analysis Model is also considered the first cut of the Design Model, since it contains the analysis classes that will be further detailed during the Design 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. 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.

Back to Processes

[DS] Design Process

In the Design process, the system is shaped and formed to meet all functional and supplemental requirements. This form is based on the architecture created and stabilized during the Analysis process. Thus, the work products produced during Analysis are an important input into this process. Design is the focus during the end of Elaboration phase and the beginning of Construction iterations. The major work products created in this process ultimately combine to form the Design Model that is used during the Implementation process. The Design Model can be used to visualize the implementation of the system. The main work products of this process 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. In addition, the Architecture Description, initially developed in the Business Requirements process and enhanced in both the Requirements Analysis and Analysis processes, is enriched with the new Module and Execution Views.

Back to Processes

[IM] Implementation Process

Through a number of steps, mostly iterative, the final application is developed within the Implementation process. The results from the Design process are used to implement the system in terms of source code for components, scripts, executables, etc. During this process, developers also implement and perform testing on software components. Implementation is the main focus of the Construction phase, but it starts early in the Inception phase in order to implement the architecture baseline (trial architecture and prototype). During Transition, it occurs in order to handle any defects or bugs discovered while testing and releasing the system.

The main work product of this process is the final iteration build that is ready to be tested. In addition, 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.

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, 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. It addresses mainly functional testing. It also includes systems integration testing for projects with requirements for interfaces to external systems. Testing activities are a shared responsibility of developers, quality assurance engineers, and ambassador users, working together as an integrated project team. The Testing process presupposes that there is a highly visible user interface from which system events can be driven and results validated. The higher proportion of artifacts that are visible to the ambassador users (for example, user interfaces and reports) the more they will be able to participate in the Testing process.

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. 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. The requirements that drive Performance Management also impact Technical Architecture (TA) and the two processes are closely related. 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. 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. Once the system and database administrators have created the test environment, the project team executes the test and the final results are documented.

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. The tasks in the Technical Architecture process identify and document the requirements related to the establishment and maintenance of the application

and technical infrastructure environment for the project. Processes and procedures required to implement, monitor and maintain the various environments are established and tested. The Technical Architecture process specifies elements of the technical infrastructure of the development project. It assumes that the business already has an information system strategy and that these elements fit within that strategy. There must be a sharp focus on the technical infrastructure in a OUM-based solution deployment project. By exposing its business systems to the Web, a business is exposing itself to unpredictable load levels and, sometimes, a hostile security environment. Therefore, the importance of the technical infrastructure cannot be overstated.

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, transform, transport and load the legacy source data to support the information needs of the new system. The data that is required to be converted is explicitly defined, along with its sources. This data may be needed for system testing, training, and acceptance testing as well as for production. In some cases, it is beneficial to convert (some) data at earlier stages to provide as realistic as possible reviews of the components during the development iterations. The amount of effort involved with conversion greatly depends on the condition of the data and the knowledge and complexity of the data structure in legacy systems and existing applications. For large projects, where large existing systems will be replaced, and most all of the data needs to be converted, you should consider running this as a separate project in parallel to the development project. In such situations, you need to thoroughly analyze the existing systems, map them to the new data model, and build multiple conversion modules of various complexities. The process includes designing, coding, and testing any conversion modules that are necessary as well as the conversion itself. The cleaning of legacy data is visibly identified as a user and client project staff task so that it can be staffed and scheduled. If data anomalies exist in the current system(s), or there are an unusual number of exceptions, you should recommend data clean-up to the project sponsor.

Back to Processes

[DO] Documentation Process

Quality documentation is a key factor in supporting the transition to production, achieving user acceptance, and maintaining the ongoing business process. The requirements and strategy for this process vary based upon project scope, technology, and requirements. For projects that include Oracle Application products, the Oracle Application manuals are the foundation of implementation documentation. 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

[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, time-sensitive, and cost-effective approach to lowering risk that is tailored to each organizations specific needs. In addition to increasing user adoption rates, carefully planning for and managing change in this way allows organizations to maintain productivity through often-difficult technological transitions. This in turn enables the organization to more easily meet deadlines, realize business objectives, and maximize return on investment. 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. 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. It begins early in the project by defining the specific requirements for cutover to the new application system. It then includes tasks to carry out the elements of that strategy such as developing an Installation Plan, preparing the Production Environment, performing the cutover, and decommissioning any legacy systems.

Back to Processes

[PS] Operations and Support Process

The goal of the Operations and Support process is to monitor and respond to system problems, upgrade the application to fix errors and performance problems, evaluate the system in production and plan enhancements for increased functionality, improved performance, and tighter security. The development project does not come to an abrupt end when the team installs the application system into production. In fact, the months following that milestone can determine the real success or failure of the project. Internal auditors have not yet produced the System Evaluation, and users most likely still have a few problems to uncover. There are certain to be requirements with lower priorities that have not been implemented. The Could Have requirements and any remaining Should Haves can now be re-prioritized into an Enhancement Plan, from which upgrades can be defined.

Back to Processes

Back to Top

ACTIVITIES
OUM tasks are further refined into activities to better represent the OUM Project lifecycle. OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity (and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user feedback. Within the OUM phases, the following major activities have been identified: Inception Phase Activities Gather Business Requirements Requirements - Inception Establish Current Business Baseline Gather Solution Requirements Perform Software Upgrade Impact Analysis Consolidate Solution Requirements Create Conceptual Prototype - 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 Conduct Organizational Readiness Assessment Deploy Change Management Roadmap / Communication Campaign - Inception

Elaboration Phase Activities Gather Business Requirements - Elaboration Develop Use Cases Create Conceptual Prototype - Elaboration Consolidate Specification Define Project Strategy Define Infrastructure Develop Test Plans Prepare Environments - Elaboration Perform Fit Gap Specify Software Configuration Baseline Software Architecture Analyze - Elaboration Design - Elaboration Develop Prototypes Validate Prototypes

Perform Unit Test - Elaboration Perform Integration Test - Elaboration Perform System Test - Elaboration Validate Upgrade Process - Elaboration Plan Performance Management Prepare to Acquire and Convert Data - Elaboration Monitor Sponsorship Program Deploy Change Management Roadmap / Communication Campaign - Elaboration

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

Transition Phase Activities Support User Acceptance Test Conduct Performance Test Convert Data -Transition Deploy Change Management Roadmap / Communication Campaign - Transition Conduct IT Alignment Train End Users - Transition Finalize Documentation Go Production

Production Phase Activities Manage Production System Performance Evaluate Production System

Resolve Production Problems Upgrade System Deploy Change Management Roadmap / Communication Campaign - Production Plan for Future Deploy IT Transition Plan

Back to Top

MANAGING
OUM uses the Manage focus area. You should read the Manage focus area overview to gain a better understanding of this focus area.

Back to Top