Oracles Project Management Method (PJM) contains the project planning and

management activities. PJM is fully integrated with AIM. Oracles EasiPath

Migration Method (EMM) Advantage
AIM Phases
Definition:
During Definition, you plan the project, review the organizations business
objectives, understand the business processes, and evaluate the feasibility of
meeting those objectives under time, resource, and budget constraints. The
emphasis is on building an achievable workplan and introducing guidelines on
how the organization will work to achieve common objectives. Establishing
scope early in the implementation gives the team a common reference point
and an effective way to communicate. Strategies, objectives, and approaches
are determined for each AIM process, providing the basis for the project plan.
The goal is to identify future business and system requirements, propose the
future business model, and determine the current application and information
technology architecture. The team reviews financial, operational, technical, and
administrative processes and leads workshops with representatives from the
organizations staff to verify that all stakeholders understand and agree on the
detailed business requirements. All business requirements are associated with
planned future business processes.

Gaps are identified, and corresponding solutions developed. The analysis

results in a high-level
design for future business processes. This high-level design is developed into
more detailed business process designs during the Operations Analysis phase.
During Definition, the executive management of the organization is engaged in
several interactive sessions. The project team is organized and oriented. A
learning plan is developed and project team members are skilled in their
appropriate areas. In addition, the Communication Campaign (AP.080) for the
project is begun.
Operation Analysis:
During Operations Analysis, the project team develops the Business
Requirements Scenarios (RD.050) based on deliverables from Definition that
are used to assess the level of fit between the detailed business
requirements and standard application functionality. Gaps are identified and
new proposed solutions are developed. Proposed solutions for gaps evolve into
detailed designs during the Solution Design phase.
Proposed solutions for gaps evolve into detailed designs during the Solution
Design phase. A model for the application architecture is created and the
technical architecture is designed. The technical architecture includes highlevel platform, software, and communications components to support the
future business system. The Application and Technical Architecture (TA)
process documents are used to develop detailed designs during Solution
Design.
The team should explore workarounds to application gaps before considering
custom modifications or new developments. If the new system requires custom
development, the team prepares high-level design documents. These
documents include general descriptions of the required features and a work
estimate for each customization. The Performance Testing team creates models
for testing the performance characteristics of the new system. Finally, a
Transition Strategy (PM.010) is developed for migrating the
organization from the current system to the new production system.
Solution Design:
The purpose of Solution Design is to develop the detailed designs for the new
system to meet the future business requirements. During this phase, project
team members create detailed Business Procedure
Documentation (BP.090). While new system designs are being finalized, the
application and

technical architecture begins to take form. The technical staff designs a

technical architecture that can support the standard application. configuration
and customizations, and considers the future system
architecture needs of the company. The technical staff also designs
performance testing programs and the environment for executing the
performance tests.
Business process design is iterative. Tasks that span both the Operations
Analysis and Solution Design phases may be performed as a unit by a design
team.
Build:
The coding and testing of all customizations and other custom software,
including application extensions, data conversions, and interfaces, is done
during the Build phase. Business system testing is performed to
validate that the functionality meets business requirements.
If customizations, extensions, or conversions are not required, the Build phase
is still important because it includes the business system test, which is
commonly conducted as a formal conference room pilot (CRP)
test. The business system test validates the configuration of the new system
and is performed in an environment that closely resembles production.
As the new system is being created, you begin to develop custom application
documentation and systems operating documentation. As the system is
refined, the documentation is reviewed and revised. Developers produce unittested and link-tested program modules. System and systems integration tests
are performed and a working, tested business system is delivered at the end of
the phase. During Build, the Performance Testing team creates Performance
Testing components and executes the performance tests. In addition,
user learningware is developed and a user learning environment is set up.
Finally, during Build the production support infrastructure is designed and a
Transition and Contingency Plan (PM.030) is developed.
Transition:
During Transition, the project team deploys the new system into the
organization. The project
team trains the users while the technical team configures the Production
Environment and converts data. During Transition, users perform an
acceptance test of the new system. Managing changes and
buffering your organization from negative impacts must be top priority.
Transition ends with the cut over to production, when users start performing
their job duties using the new system.

If a phased deployment is being employed, Transition may consist of multiple

deployments where subsets of the applications may be deployed to various
geographical sites and/or business units at different times.
Production:
Production begins immediately with the production cutover. It marks the last
phase of the implementation and the beginning of the system support cycle.
During Production, you compare actual results to project objectives and
determine if improvements can
be made. Controlled system refinement begins to minimize the impact to
users. Finally, you start preliminary planning of the future business and
technical direction of the company. If multiple deployments exist, Production
will occur at different times for the various geographical sites and business
units.
AIM Processes:
Business Process Architecture (BP)
Business Requirements Definition (RD)
Business Requirements Mapping (BR)
Application and Technical Architecture (TA)
Module Design and Build (MD)
Data Conversion (CV)
Documentation (DO)
Business System Testing (TE)
Performance Testing (PT)
Adoption and Learning (AP)
Production Migration (PM)
Business Process Architecture (BP): Business Process Architecture
addresses understanding of the
organizations business processes and aligns them with the business
requirements and applications to be implemented. Your team then translates
that vision into High-Level Process Designs (BP.070).
Business Requirements Definition (RD) defines the business needs that
must be met by the implementation project. The project team conducts a
Current Business Baseline (RD.020) to document current business
requirements, then constructs future business processes and function models
to portray future business requirements.

Business Requirements Mapping (BR) compares the future business

requirements to standard application software functionality and identifies gaps
that must be addressed to fully meet business needs. Mapping teams are
assigned groups of future business processes, usually related by business
function. Business Requirements Scenarios (RD.050) are then mapped to
application functionality.
During Application and Technical Architecture (TA), you design an
information systems architecture that reflects your business vision. Design of
the technical infrastructure including databases, servers, networks etc.
Module Design and Build (MD) produces custom application extensions for
gaps in functionality identified during Business Requirements Mapping (BR).
Custom application extensions include program modules (forms, reports,
alerts, and database triggers) that must be designed, built, and tested before
they can be incorporated into the new system. Module Design and Build
addresses the design and development of the custom modules Business
System Testing (TE) supports testing of the custom modules.
Data Conversion (CV) defines the tasks and deliverables required to convert
legacy data to the Oracle Applications tables. The converted data may be
needed for system testing, training, and acceptance testing, as well as for
production cutover.
Documentation (DO): The amount and level of detail of documentation
varies by project. The
Documentation Requirements and Strategy (DO.010) defines the
documentation requirements for the project and establishes which of the
optional Documentation tasks are required.
Business System Testing (TE): Business System Testing focuses on linking
test requirements back to business requirements and securing project
resources needed for testing. It
Performance Testing (PT) enables you to define, build, and execute a
performance test. It does not assume a particular scope for the performance
test. It is closely related to Application and Technical Architecture (TA). The
Performance Testing team defines the scope of testing and relates it to pointin-time snapshots of the transactions expected in the real production system.
Adoption and Learning (AP): Learning establishes a measurement system
that provides
an evaluation of organizational performance to help make sure that
expectations are met during implementation and after production cutover.

Production Migration (PM): moves the company, system, and people to the
new enterprise system. Following production cutover, it monitors and refines
the production system and plans for the future. The Production Migration
process encompasses transition to production readiness, production cutover,
and post-production support.
The core tasks in AIM define the minimum set of steps necessary to
implement Oracle Applications.
Pre-Packaged Approach
A pre-packaged approach is a set of predefined activities using AIM tasks and
deliverables. Pre-packaged approaches offer a set of predefined tasks and
predefined templates. These predefined tasks are AIM foundation tasks that
have been specifically selected to be part of the pre-packaged approach. Keep
in mind many of the templates used by FastForward and other pre-packaged
approaches have been pre-seeded with data that must be used by the
implementation team
Tailored Approach
A tailored approach allows an organization to have maximum flexibility and
extensibility in implementing Oracle Applications. A tailored approach allows an
organization to build a project approach that maps
to their unique implementation requirements.

Document Numbers
Communication Campaign (AP.080)
Business Requirements Scenarios (RD.050)
Transition Strategy (PM.010)
detailed Business Procedure Documentation (BP.090).
Transition and Contingency Plan (PM.030)
High-Level Process Designs (BP.070).
Current Business Baseline (RD.020)
Business Requirements Scenarios (RD.050
Documentation Requirements and Strategy (DO.010)

Definition:
Tasks and Deliverables
The table below lists the tasks executed and the deliverables produced
during Definition.
Typ
ID
Task
Deliverable
e*
Business Process Architecture
BP.010 Define Business and
Business and Process
SI
Process Strategy
Strategy
BP.020 Catalog and Analyze
Change Catalog
SI
Potential Changes
BP.030 Determine Data Gathering Data Gathering
SI
Requirements
Requirements
BP.040 Develop Current Process
Current Process Model
MI
Model
BP.050 Review Leading Practices
Leading Practices Review
MI
BP.060 Develop High-Level
High-Level Process Vision
SI
Process Vision
BP.070 Develop High-Level
High-Level Process Designs MI
Process Designs
Business Requirements Definition
RD.01 Identify Current Financial
Current Financial and
SI
0
and
Operating
Operating Structure
Structure
RD.02 Conduct Current Business
Current Business Baseline
MI
0
Baseline
Application and Technical Architecture
TA.01 Define Architecture
Architecture Requirements SI
0
Requirements and
and
Strategy
Strategy
TA.02 Identify Current Technical
Current Technical
SI
0
Architecture
Architecture
Baseline
TA.03 Develop Preliminary
Preliminary Conceptual
IT
0
Conceptual
Architecture
Architecture
Module Design and Build
MD.01 Define Application
Application Extension
SI
0
Extension Strategy
Strategy
Data Conversion

CV.01
0

Define Data Conversion

Requirements
and Strategy

Data Conversion
Requirements and
Strategy

ID

Task

Deliverable

SI

Typ
e*

Documentation
DO.01 Define Documentation
Documentation
SI
0
Requirements and
Requirements and
Strategy
Strategy
DO.02 Define Documentation
Documentation Standards
SI
0
Standards and
and
Procedures
Procedures
DO.03
Prepare Glossary
Glossary
SI
0
Business System Testing
TE.01 Define Testing
Testing Requirements and
SI
0
Requirements and
Strategy
Strategy
Performance Testing
Define Performance
Performance Testing
PT.010
SI
Testing Strategy
Strategy
Adoption and Learning
Define Executive Project
AP.010
Executive Project Strategy SI
Strategy
AP.020 Conduct Initial Project
Oriented Project Team
SI
Team Orientation
Develop Project Team
AP.030
Project Team Learning Plan SI
Learning Plan
AP.040 Prepare Project Team
Project Team Learning
SI
Learning Environment
Environment
Conduct Project Team
AP.050
Skilled Project Team
MI
Learning Events
AP.060 Develop Business Unit
Business Unit Managers
SI
Managers Readiness Plan
Readiness Plan
Develop Project Readiness Project Readiness
AP.070
SI
Roadmap
Roadmap
AP.080 Develop and Execute
Communication Campaign SI
Communication Campaign
*Type: SI=singly instantiated, MI=multiply instantiated, MO=multiply
occurring, IT=iterated, O=ongoing. See Glossary.

Operations Analysis
Tasks and Deliverables
The table below lists the tasks executed and the deliverables produced
during Operations Analysis.
Typ
ID
Task
Deliverable
e*
Business Process Architecture
Develop Future Process
BP.080
Future Process Model
MI
Model
Business Requirements Definition
RD.03 Establish Process and
Process and Mapping
SI
0
Mapping
Summary
Summary
RD.04 Gather Business Volumes
Business Volumes and
SI
0
and Metrics
Metrics
RD.05 Gather Business
Business Requirements
MI
0
Requirements
Scenarios
RD.06 Determine Audit and
Audit and Control
SI
0
Control
Requirements
Requirements
RD.07 Identify Business
Business Availability
SI
0
Availability
Requirements
Requirements
RD.08 Identify Reporting and
Master Report Tracking List MI
0
Information
Access Requirements
Business Requirements Mapping
BR.01
Analyze High-Level Gaps
High-Level Gap Analysis
SI
0
BR.02 Prepare Mapping
Configuration Mapping
SI
0
Environment
Environment
BR.03 Map Business
Mapped Business
MI
0
Requirements
Requirements
BR.04
Map Business Data
Mapped Business Data
MI
0
BR.05 Conduct Integration Fit
Integration Fit Analysis
SI
0
Analysis
BR.06
Create Information Model
Information Model
SI
0
BR.07 Conduct Reporting Fit
Master Report Tracking List MI

0
BR.08
0
BR.09
0

Analysis

Confirm Integrated
Business Solutions

Business Mapping Test

Results
Confirmed Business
Solutions

ID

Task

Deliverable

Test Business Solutions

Application and Technical Architecture

TA.04 Define Application
Application Architecture
0
Architecture
TA.05 Define System Availability
System Availability
0
Strategy
Strategy
TA.06 Define Reporting and
Reporting and Information
0
Information
Access
Access Strategy
Strategy
TA.07 Revise Conceptual
Conceptual Architecture
0
Architecture
Module Design and Build
MD.02 Define and Estimate
Application Extension
0
Application
Definition and
Extensions
Estimates
Documentation
DO.04 Prepare Documentation
Documentation
0
Environment
Environment
DO.05 Produce Documentation
Documentation Prototypes
0
Prototypes
and
and Templates
Templates
Performance Testing
Identify Performance Test
Performance Test
PT.020
Scenarios
Scenarios
Identify Performance Test
Performance Test
PT.030
Transaction
Transaction Models
Models
Adoption and Learning
Develop Managers
AP.090
Managers Readiness Plan
Readiness Plan
Production Migration
PM.01
Define Transition Strategy
Transition Strategy
0

MI
SI

Typ
e*
SI
SI
SI

SI
MI,
IT

SI
MI

MI
MI

SI

SI

Solution Design
Tasks and Deliverables
The table below lists the tasks executed and the deliverables produced
during Solution Design.
Typ
ID
Task
Deliverable
e*
Business Process Architecture
Document Business
Business Procedure
BP.090
MI
Procedures
Documentation
Business Requirements Mapping
BR.10
Application Setup
Define Application Setups
MI
0
Documents
BR.11
Design Security Profiles
Security Profiles
SI
0
Application and Technical Architecture
TA.08
Application Security
Define Application Security
SI
0
Architecture
Architecture
Module Design and Build
MD.03
Define Design Standards
Design Standards
SI
0
MD.04
Define Build Standards
Build Standards
SI
0
MD.05 Create Application
Application Extensions
MI,
0
Extensions
Functional
IT
Functional Design
Design
MD.06 Design Database
Database Extensions
SI
0
Extensions
Design
MD.07 Create Application
Application Extensions
MI,
0
Extensions
Technical
IT
Technical Design
Design
MD.08 Review Functional and
Approved Designs
SI
0
Technical
Designs
Data Conversion
CV.02 Define Conversion
Conversion Standards
SI
0
Standards
CV.03 Prepare Conversion
Conversion Environment
SI
0
Environment
CV.04 Perform Conversion Data
Conversion Data Mapping
MI
0
Mapping

CV.05
0
CV.06
0
CV.07
0

Define Manual Conversion

Procedures
Design Conversion
Programs
Prepare Conversion Test
Plans

Manual Conversion
Procedures
Conversion Program
Design
Conversion Test Plans

MI

ID

Task

Deliverable

Typ
e*

Unit Test Script

MI

Link Test Script

MI

System Test Script

MI

Systems Integration Test

Script

MI

Performance Test Scripts

MI

Business System Testing

TE.02
Develop Unit Test Script
0
TE.03
Develop Link Test Script
0
TE.04 Develop System Test
0
Script
TE.05 Develop Systems
0
Integration Test
Script
Performance Testing
Create Performance Test
PT.040
Scripts
Design Performance Test
PT.050
Transaction
Programs
Design Performance Test
PT.060
Data
Design Test Database Load
PT.070
Programs
Adoption and Learning
Identify Business Process
AP.100
Impact on
Organization
Align Human Performance
AP.110
Support
Systems
Align Information
AP.120
Technology Groups
AP.130

Conduct User Learning

Needs

MI
MI

Performance Test
MI
Transaction Program
Designs
Performance Test Data
SI
Design
Performance Test Database
MI
Load
Program Designs
Business Process
Organizational
Impact
Human Performance
Support Systems
Aligned Information
Technology
Groups
User Learning Needs
Analysis

SI
MI,
IT
MI

SI

Analysis
Develop User Learning
AP.140
Plan

User Learning Plan

SI

Build
Tasks and Deliverables
The table below lists the tasks executed and the deliverables produced
during Build.
Typ
ID
Task
Deliverable
e*
Application and Technical Architecture
TA.09 Define Application and
Application and Database
SI
0
Database
Server
Server Architecture
Architecture
TA.10 Define and Propose
Architecture Subsystems
MI
0
Architecture
Proposal
Subsystems
TA.11 Define System Capacity
System Capacity Plan
SI
0
Plan
TA.12 Define Platform and
Platform and Network
SI
0
Network
Architect
Architecture
TA.13 Define Application
Application Deployment
IT
0
Deployment Plan
Plan
TA.14
Performance Risk
Assess Performance Risks
SI
0
Assessment
TA.15 Define System
System Management
SI
0
Management
Procedures
Procedures
Module Design and Build
MD.09 Prepare Development
Development Environment SI
0
Environment
MD.10 Create Database
Custom Database Objects
SI
0
Extensions
MD.11 Create Application
Module Source Code
MI
0
Extension Modules
MD.12 Create Installation
Installation Routines
MI
0
Routines
Data Conversion
CV.08 Develop Conversion
Conversion Programs
MI
0
Programs

CV.09
0
CV.10
0
CV.11
0

Perform Conversion Unit

Tests
Perform Conversion
Business Object
Tests
Perform Conversion
Validation Tests

Unit-Tested Conversion
Programs
Business Object-Tested
Conversion
Programs
Validation-Tested
Conversion
Programs

ID

Task

Deliverable

Typ
e*

User Reference Manual

IT

User Guide

IT

Tech Reference Manual

IT

System Management
Guide

IT

Testing Environments

MI

Documentation
DO.06 Publish User Reference
0
Manual
DO.07
Publish User Guide
0
DO.08 Publish Technical
0
Reference Manual
DO.09 Publish System
0
Management Guide
Business System Testing
TE.06 Prepare Testing
0
Environments
TE.07
Perform Unit Test
0
TE.08
Perform Link Test
0
TE.09
Perform Installation Test
0
TE.10 Prepare Key Users for
0
Testing
TE.11
Perform System Test
0
TE.12 Perform Systems
0
Integration Test
Performance Testing
Create Performance Test
PT.080
Transaction
Programs
Create Test Database Load
PT.090
Programs

Unit-Tested Modules
Link-Tested Modules

MI
MI

MI

MI,
IT
MI,
IT

Tested Installation
Routines

IT

Prepared Key Users

SI

System-Tested
Applications

IT

Integration-Tested System

IT

Performance Test
Transaction
Programs
Performance Test
Database Load

MI

MI

PT.100
PT.110
PT.120

Construct Performance
Test Database
Prepare Performance Test
Environment

Programs
Performance Test
Database
Performance Test
Environment

Execute Performance Test

Performance Test Results

Create Performance Test

Report
Adoption and Learning
Develop User
AP.150
Learningware
Prepare User Learning
AP.160
Environment
Production Migration
PM.02
Design Production Support
0
Infrastructure
PM.03 Develop Transition and
0
Contingency
Plan
PT.130

SI
MI,
IT
MI,
IT

Performance Test Report

SI

User Learningware

MI,
IT

User Learning Environment SI

Product Support
Infrastructure Design

SI

Transition and Contingency

Plan

SI

Transition:
Tasks and Deliverables
The table below lists the tasks executed and the deliverables produced
during Transition.
Typ
ID
Task
Deliverable
e*
Data Conversion
CV.12 Install Conversion
Installed Conversion
SI
0
Programs
Programs
CV.13
Converted and Verified
Convert and Verify Data
SI
0
Data
Business System Testing
TE.13
Perform Acceptance Test
Acceptance Test Results
SI
0
Adoption and Learning
Conduct User Learning
MI,
AP.170
Skilled Users
Events
IT
Production Migration
PM.04 Prepare Production
Production Environment
SI

0
PM.05
0
PM.06
0

Environment
Set Up Applications

Configured Applications

MI

Implement Production
Support
Infrastructure
Verify Production
Readiness

Production Support
Infrastructure

SI

PM.07
Production-Ready System
SI
0
PM.08
Begin Production
Production System
SI
0
*Type: SI=singly instantiated, MI=multiply instantiated, MO=multiply
occurring, IT=iterated, O=ongoing. See Glossary.
Production:
Tasks and Deliverables
The table below lists the tasks executed and the deliverables produced
during Production.
Typ
ID
Task
Deliverable
e*
Adoption and Learning
Conduct Effectiveness
AP.180
Effectiveness Assessment
SI
Assessment
Production Migration
PM.09 Measure System
System Performance
SI
0
Performance
Assessment
PM.10
Maintained Production
Maintain System
SI
0
Environment
PM.11
Refined Production
Refine Production System
SI
0
Environment
PM.12 Decommission Former
Decommissioned Systems
MI
0
Systems
PM.13 Propose Future Business
Business Direction
SI
0
Direction
Recommendations
PM.14 Propose Future Technical
Technical Direction
SI
0
Direction
Recommendations
*Type: SI=singly instantiated, MI=multiply instantiated, MO=multiply
occurring, IT=iterated, O=ongoing. See Glossary.
Table 7-3 Production Phase Tasks and Deliverables

Unit Testing
http://www.codeproject.com/gen/design/autp5.asp
http://www.codeproject.com/csharp/autp1.asp
A unit test verifies that a function or set of functions "honors its contract" - in
other words, that the function(s) under test meet the requirements. Unit tests
inspect both black boxes or white boxes. A black box test (also known as a
"functional test") is one in which you feed it inputs and verify the outputs
without being able to inspect the internal workings. Furthermore, one doesn't
usually have information regarding:

how the box handles errors

whether your inputs are executing all code pathways
how to modify your inputs so that all code pathways are executed
dependencies on other resources

A white box provides the information necessary to test all the possible
pathways. This includes not only correct inputs, but incorrect inputs, so that
error handlers can be verified as well. This provides several advantages:

you know how the box handles errors

you can usually write tests that verify all code pathways
the unit test, being more complete, is a kind of documentation guideline
that the implementer can use when actually writing the code in the box
resource dependencies are known
internal workings can be inspected

In the "write the test first" scenario, the ability to write complete tests is vital
information to the person that ultimately implements the code, therefore a
good white box unit test must ensure that, at least conceptually, all the
different pathways are exercised.