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 high-level 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 unit-tested 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 point-in-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

ID

The table below lists the tasks executed and the deliverables produced
during Definition.
Type
Task
Deliverable
*

Business Process Architecture

BP.010
Define Business and Process
Strategy
BP.020
Catalog and Analyze Potential
Changes
BP.030
Determine Data Gathering
Requirements
BP.040
Develop Current Process
Model
BP.050
Review Leading Practices
BP.060
Develop High-Level Process

Business and Process Strategy

SI

Change Catalog

SI

Data Gathering Requirements

SI

Current Process Model

MI

Leading Practices Review

High-Level Process Vision

MI
SI

Vision
BP.070
Develop High-Level Process
Designs
Business Requirements Definition
RD.010 Identify Current Financial and
Operating Structure
RD.020 Conduct Current Business
Baseline
Application and Technical Architecture
TA.010 Define Architecture
Requirements and
Strategy
TA.020 Identify Current Technical
Architecture
TA.030

Develop Preliminary
Conceptual
Architecture
Module Design and Build
MD.01 Define Application Extension
0
Strategy
Data Conversion
CV.010 Define Data Conversion
Requirements
and Strategy

ID

Task

Documentation
DO.010 Define Documentation
Requirements and Strategy
Define Documentation
DO.020
Standards and
Procedures
DO.030 Prepare Glossary

High-Level Process Designs

MI

Current Financial and

Operating
Structure
Current Business Baseline

SI

Architecture Requirements
and
Strategy
Current Technical Architecture

SI

MI

SI

Baseline
Preliminary Conceptual
Architecture

IT

Application Extension Strategy

SI

Data Conversion Requirements SI

and
Strategy

Deliverable

Type
*

Documentation Requirements
and Strategy

SI

Documentation Standards and

SI

Procedures
Glossary

SI

Business System Testing

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

SI

SI

SI
SI
SI
SI
MI
SI
SI
SI

Operations Analysis
Tasks and Deliverables
The table below lists the tasks executed and the deliverables produced
during Operations Analysis.
Type
ID
Task
Deliverable
*
Business Process Architecture
BP.080
Develop Future Process Model Future Process Model
MI
Business Requirements Definition
Process and Mapping
RD.030 Establish Process and Mapping
SI
Summary

RD.040

Summary
Gather Business Volumes and
Metrics

RD.050

Gather Business Requirements

RD.060

Determine Audit and Control

Business Volumes and Metrics

Business Requirements
Scenarios
Audit and Control
Requirements

SI
MI
SI

Requirements
RD.070

Identify Business Availability

Requirements
Identify Reporting and
RD.080
Information
Access Requirements
Business Requirements Mapping
BR.010 Analyze High-Level Gaps
BR.020
BR.030
BR.040
BR.050
BR.060
BR.070
BR.080
BR.090

ID

Business Availability
Requirements

SI

Master Report Tracking List

MI

High-Level Gap Analysis

Configuration Mapping
Prepare Mapping Environment
Environment
Mapped Business
Map Business Requirements
Requirements
Map Business Data
Mapped Business Data
Conduct Integration Fit
Integration Fit Analysis
Analysis
Create Information Model
Information Model
Conduct Reporting Fit
Master Report Tracking List
Analysis
Test Business Solutions
Business Mapping Test Results
Confirm Integrated Business
Confirmed Business Solutions
Solutions

Task

Application and Technical Architecture

Define Application
TA.040
Architecture
TA.050 Define System Availability

SI
SI
MI
MI
SI
SI
MI
MI
SI

Deliverable

Type
*

Application Architecture

SI

System Availability Strategy

SI

Strategy
Define Reporting and
TA.060
Information
Access Strategy
Revise Conceptual
TA.070
Architecture
Module Design and Build
MD.02 Define and Estimate
0
Application
Extensions
Documentation
Prepare Documentation
DO.040
Environment
Produce Documentation
DO.050
Prototypes
and Templates
Performance Testing
Identify Performance Test
PT.020
Scenarios
Identify Performance Test
PT.030
Transaction
Models
Adoption and Learning
Develop Managers Readiness
AP.090
Plan
Production Migration
PM.010 Define Transition Strategy

Reporting and Information

Access
Strategy

SI

Conceptual Architecture

SI

Application Extension
Definition and
Estimates

MI,
IT

Documentation Environment

SI

Documentation Prototypes
and
Templates

MI

Performance Test Scenarios

MI

Performance Test Transaction

Models

MI

Managers Readiness Plan

SI

Transition Strategy

SI

Solution Design
Tasks and Deliverables
The table below lists the tasks executed and the deliverables produced
during Solution Design.
Type
ID
Task
Deliverable
*
Business Process Architecture
BP.090
Document Business
Business Procedure
MI

Procedures
Business Requirements Mapping
BR.100 Define Application Setups
BR.110 Design Security Profiles
Application and Technical Architecture
TA.080

Define Application Security

Architecture
Module Design and Build
MD.03
Define Design Standards
0
MD.04
Define Build Standards
0
MD.05
Create Application Extensions
0
Functional Design
MD.06
Design Database Extensions
0
MD.07
Create Application Extensions
0
Technical Design
MD.08 Review Functional and
0
Technical
Designs
Data Conversion
CV.020 Define Conversion Standards
Prepare Conversion
CV.030
Environment
Perform Conversion Data
CV.040
Mapping
Define Manual Conversion
CV.050
Procedures
CV.060 Design Conversion Programs
CV.070 Prepare Conversion Test Plans

ID

Task

Documentation
Application Setup Documents
Security Profiles

MI
SI

Application Security
Architecture

SI

Design Standards

SI

Build Standards

SI

Application Extensions
Functional
Design

MI,
IT

Database Extensions Design

SI

Application Extensions
Technical
Design

MI,
IT

Approved Designs

SI

Conversion Standards

SI

Conversion Environment

SI

Conversion Data Mapping

MI

Manual Conversion
Procedures
Conversion Program Design
Conversion Test Plans

Deliverable

MI
MI
MI

Type

*
Business System Testing
TE.020 Develop Unit Test Script
TE.030 Develop Link Test Script
TE.040 Develop System Test Script
Develop Systems Integration
TE.050
Test
Script
Performance Testing
Create Performance Test
PT.040
Scripts
Design Performance Test
PT.050
Transaction
Programs
PT.060 Design Performance Test 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 Technology
AP.120
Groups
AP.130
AP.140

Conduct User Learning Needs

Analysis
Develop User Learning Plan

Unit Test Script

Link Test Script
System Test Script

MI
MI
MI

Systems Integration Test Script

MI

Performance Test Scripts

MI

Performance Test Transaction

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

MI
SI
MI

SI
MI,
IT
MI
SI
SI

Build
Tasks and Deliverables
The table below lists the tasks executed and the deliverables produced
during Build.

ID

Task

Application and Technical Architecture

Define Application and
TA.090
Database
Server Architecture
Define and Propose
TA.100
Architecture
Subsystems
TA.110 Define System Capacity Plan
TA.120

Define Platform and Network

TA.130
TA.140

Architecture
Define Application
Deployment Plan
Assess Performance Risks

TA.150

Define System Management

Procedures
Module Design and Build
MD.09 Prepare Development
0
Environment
MD.10
Create Database Extensions
0
MD.11 Create Application Extension
0
Modules
MD.12
Create Installation Routines
0
Data Conversion
CV.080 Develop Conversion Programs
CV.090
CV.100

CV.110

Perform Conversion Unit Tests

Perform Conversion Business
Object
Tests
Perform Conversion Validation
Tests

Deliverable
Application and Database
Server
Architecture
Architecture Subsystems
Proposal

Type
*
SI

MI

System Capacity Plan

Platform and Network
Architect

SI

Application Deployment Plan

IT

Performance Risk Assessment

System Management
Procedures

SI

Development Environment

SI

Custom Database Objects

SI

Module Source Code

MI

Installation Routines

MI

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

MI

Validation-Tested Conversion

MI

SI

SI

MI
MI

Programs

ID

Task

Documentation
Publish User Reference
DO.060
Manual
DO.070 Publish User Guide
Publish Technical Reference
DO.080
Manual
Publish System Management
DO.090
Guide
Business System Testing
TE.060 Prepare Testing Environments

Deliverable

Type
*

User Reference Manual

IT

User Guide

IT

Tech Reference Manual

IT

System Management Guide

IT

Testing Environments

Tested Installation Routines

Prepared Key Users
System-Tested Applications

MI
MI,
IT
MI,
IT
IT
SI
IT

Integration-Tested System

IT

Performance Test Transaction

MI

Programs
Performance Test Database
Load
Programs

MI

Performance Test Database

SI

TE.070

Perform Unit Test

Unit-Tested Modules

TE.080

Perform Link Test

Link-Tested Modules

TE.090
TE.100
TE.110

Perform Installation Test

Prepare Key Users for Testing
Perform System Test
Perform Systems Integration
TE.120
Test
Performance Testing
Create Performance Test
PT.080
Transaction
Programs
Create Test Database Load
PT.090
Programs
PT.100
PT.110
PT.120

Construct Performance Test

Database
Prepare Performance Test
Environment
Execute Performance Test

Performance Test Environment

Performance Test Results

MI,
IT
MI,
IT

Create Performance Test

Report
Adoption and Learning
PT.130

AP.150

Develop User Learningware

Prepare User Learning

Environment
Production Migration
AP.160

Performance Test Report

SI

User Learningware

MI,
IT

User Learning Environment

SI

PM.020

Design Production Support

Product Support
Infrastructure Design

SI

PM.030

Infrastructure
Develop Transition and
Contingency
Plan

Transition and Contingency

Plan

SI

Transition:
Tasks and Deliverables
The table below lists the tasks executed and the deliverables produced
during Transition.
Type
ID
Task
Deliverable
*
Data Conversion
CV.120 Install Conversion Programs
Installed Conversion Programs SI
CV.130 Convert and Verify Data
Converted and Verified Data
SI
Business System Testing
TE.130 Perform Acceptance Test
Acceptance Test Results
SI
Adoption and Learning
MI,
AP.170 Conduct User Learning Events Skilled Users
IT
Production Migration
Prepare Production
PM.040
Production Environment
SI
Environment
PM.050 Set Up Applications
Configured Applications
MI
Implement Production
Production Support
PM.060
SI
Support
Infrastructure
Infrastructure

PM.070 Verify Production Readiness

Production-Ready System
SI
PM.080 Begin Production
Production System
SI
*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.
Type
ID
Task
Deliverable
*
Adoption and Learning
Conduct Effectiveness
AP.180
Effectiveness Assessment
SI
Assessment
Production Migration
System Performance
PM.090 Measure System Performance
SI
Assessment
Maintained Production
PM.100 Maintain System
SI
Environment
Refined Production
PM.110 Refine Production System
SI
Environment
Decommission Former
PM.120
Decommissioned Systems
MI
Systems
Propose Future Business
Business Direction
PM.130
SI
Direction
Recommendations
Propose Future Technical
Technical Direction
PM.140
SI
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.