Detail Oracle AIM (Application Implementation Methodology) Tool - Oracle Financials and SCM Online Training

Oracle’s Project Management Method (PJM) contains the project planning and management activities. PJM is fully integrated with AIM. Oracle’s EasiPath Migration Method (EMM) Advantage

AIM Phases

Definition:

During Definition, you plan the project, review the organization’s 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 organization’s 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

organization’s 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
The table below lists the tasks executed and the deliverables produced
during Definition.
ID	Task	Deliverable	Type*
Business Process Architecture
BP.010	Define Business and Process Strategy	Business and Process Strategy	SI
BP.020	Catalog and Analyze Potential Changes	Change Catalog	SI
BP.030	Determine Data Gathering	Data Gathering Requirements	SI
	Requirements
BP.040	Develop Current Process Model	Current Process Model	MI
BP.050	Review Leading Practices	Leading Practices Review	MI
BP.060	Develop High-Level Process Vision	High-Level Process Vision	SI
BP.070	Develop High-Level Process Designs	High-Level Process Designs	MI
Business Requirements Definition
RD.010	Identify Current Financial and	Current Financial and Operating	SI
	Operating Structure	Structure
RD.020	Conduct Current Business Baseline	Current Business Baseline	MI
Application and Technical Architecture
TA.010	Define Architecture Requirements and	Architecture Requirements and	SI
	Strategy	Strategy
TA.020	Identify Current Technical Architecture	Current Technical Architecture	SI
		Baseline
TA.030	Develop Preliminary Conceptual	Preliminary Conceptual Architecture	IT
	Architecture
Module Design and Build
MD.010	Define Application Extension Strategy	Application Extension Strategy	SI
Data Conversion
CV.010	Define Data Conversion Requirements	Data Conversion Requirements and	SI
	and Strategy	Strategy

ID	Task	Deliverable	Type*
Documentation
DO.010	Define Documentation Requirements and Strategy	Documentation Requirements and Strategy	SI
DO.020	Define Documentation Standards and	Documentation Standards and	SI
	Procedures	Procedures
DO.030	Prepare Glossary	Glossary	SI
Business System Testing
TE.010	Define Testing Requirements and Strategy	Testing Requirements and Strategy	SI
Performance Testing
PT.010	Define Performance Testing Strategy	Performance Testing Strategy	SI
Adoption and Learning
AP.010	Define Executive Project Strategy	Executive Project Strategy	SI
AP.020	Conduct Initial Project Team Orientation	Oriented Project Team	SI
AP.030	Develop Project Team Learning Plan	Project Team Learning Plan	SI
AP.040	Prepare Project Team Learning Environment	Project Team Learning Environment	SI
AP.050	Conduct Project Team Learning Events	Skilled Project Team	MI
AP.060	Develop Business Unit Managers’ Readiness Plan	Business Unit Managers’ Readiness Plan	SI
AP.070	Develop Project Readiness Roadmap	Project Readiness Roadmap	SI
AP.080	Develop and Execute Communication Campaign	Communication Campaign	SI

*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.
ID	Task	Deliverable	Type*
Business Process Architecture
BP.080	Develop Future Process Model	Future Process Model	MI
Business Requirements Definition
RD.030	Establish Process and Mapping	Process and Mapping Summary	SI
	Summary
RD.040	Gather Business Volumes and Metrics	Business Volumes and Metrics	SI
RD.050	Gather Business Requirements	Business Requirements Scenarios	MI
RD.060	Determine Audit and Control	Audit and Control Requirements	SI
	Requirements
RD.070	Identify Business Availability	Business Availability Requirements	SI
	Requirements
RD.080	Identify Reporting and Information	Master Report Tracking List	MI
	Access Requirements
Business Requirements Mapping
BR.010	Analyze High-Level Gaps	High-Level Gap Analysis	SI
BR.020	Prepare Mapping Environment	Configuration Mapping Environment	SI
BR.030	Map Business Requirements	Mapped Business Requirements	MI
BR.040	Map Business Data	Mapped Business Data	MI
BR.050	Conduct Integration Fit Analysis	Integration Fit Analysis	SI
BR.060	Create Information Model	Information Model	SI
BR.070	Conduct Reporting Fit Analysis	Master Report Tracking List	MI
BR.080	Test Business Solutions	Business Mapping Test Results	MI
BR.090	Confirm Integrated Business Solutions	Confirmed Business Solutions	SI

ID	Task	Deliverable	Type*
Application and Technical Architecture
TA.040	Define Application Architecture	Application Architecture	SI
TA.050	Define System Availability Strategy	System Availability Strategy	SI
TA.060	Define Reporting and Information	Reporting and Information Access	SI
	Access Strategy	Strategy
TA.070	Revise Conceptual Architecture	Conceptual Architecture	SI
Module Design and Build
MD.020	Define and Estimate Application	Application Extension Definition and	MI, IT
	Extensions	Estimates
Documentation
DO.040	Prepare Documentation Environment	Documentation Environment	SI
DO.050	Produce Documentation Prototypes	Documentation Prototypes and	MI
	and Templates	Templates
Performance Testing
PT.020	Identify Performance Test Scenarios	Performance Test Scenarios	MI
PT.030	Identify Performance Test Transaction	Performance Test Transaction Models	MI
	Models
Adoption and Learning
AP.090	Develop Managers’ Readiness Plan	Managers’ Readiness Plan	SI
Production Migration
PM.010	Define Transition Strategy	Transition Strategy	SI

Solution Design

Tasks and Deliverables
The table below lists the tasks executed and the deliverables produced
during Solution Design.
ID	Task	Deliverable	Type*
Business Process Architecture
BP.090	Document Business Procedures	Business Procedure Documentation	MI
Business Requirements Mapping
BR.100	Define Application Setups	Application Setup Documents	MI
BR.110	Design Security Profiles	Security Profiles	SI
Application and Technical Architecture
TA.080	Define Application Security	Application Security Architecture	SI
	Architecture
Module Design and Build
MD.030	Define Design Standards	Design Standards	SI
MD.040	Define Build Standards	Build Standards	SI
MD.050	Create Application Extensions	Application Extensions Functional	MI, IT
	Functional Design	Design
MD.060	Design Database Extensions	Database Extensions Design	SI
MD.070	Create Application Extensions	Application Extensions Technical	MI, IT
	Technical Design	Design
MD.080	Review Functional and Technical	Approved Designs	SI
	Designs
Data Conversion
CV.020	Define Conversion Standards	Conversion Standards	SI
CV.030	Prepare Conversion Environment	Conversion Environment	SI
CV.040	Perform Conversion Data Mapping	Conversion Data Mapping	MI
CV.050	Define Manual Conversion Procedures	Manual Conversion Procedures	MI
CV.060	Design Conversion Programs	Conversion Program Design	MI
CV.070	Prepare Conversion Test Plans	Conversion Test Plans	MI

ID	Task	Deliverable	Type*
Business System Testing
TE.020	Develop Unit Test Script	Unit Test Script	MI
TE.030	Develop Link Test Script	Link Test Script	MI
TE.040	Develop System Test Script	System Test Script	MI
TE.050	Develop Systems Integration Test	Systems Integration Test Script	MI
	Script
Performance Testing
PT.040	Create Performance Test Scripts	Performance Test Scripts	MI
PT.050	Design Performance Test Transaction	Performance Test Transaction Program	MI
	Programs	Designs
PT.060	Design Performance Test Data	Performance Test Data Design	SI
PT.070	Design Test Database Load Programs	Performance Test Database Load	MI
		Program Designs
Adoption and Learning
AP.100	Identify Business Process Impact on	Business Process Organizational	SI
	Organization	Impact
AP.110	Align Human Performance Support	Human Performance Support Systems	MI, IT
	Systems
AP.120	Align Information Technology Groups	Aligned Information Technology	MI
		Groups
AP.130	Conduct User Learning Needs	User Learning Needs Analysis	SI
	Analysis
AP.140	Develop User Learning Plan	User Learning Plan	SI

Build

Tasks and Deliverables
The table below lists the tasks executed and the deliverables produced
during Build.
ID	Task	Deliverable	Type*
Application and Technical Architecture
TA.090	Define Application and Database	Application and Database Server	SI
	Server Architecture	Architecture
TA.100	Define and Propose Architecture	Architecture Subsystems Proposal	MI
	Subsystems
TA.110	Define System Capacity Plan	System Capacity Plan	SI
TA.120	Define Platform and Network	Platform and Network Architect	SI
	Architecture
TA.130	Define Application Deployment Plan	Application Deployment Plan	IT
TA.140	Assess Performance Risks	Performance Risk Assessment	SI
TA.150	Define System Management	System Management Procedures	SI
	Procedures
Module Design and Build
MD.090	Prepare Development Environment	Development Environment	SI
MD.100	Create Database Extensions	Custom Database Objects	SI
MD.110	Create Application Extension Modules	Module Source Code	MI
MD.120	Create Installation Routines	Installation Routines	MI
Data Conversion
CV.080	Develop Conversion Programs	Conversion Programs	MI
CV.090	Perform Conversion Unit Tests	Unit-Tested Conversion Programs	MI
CV.100	Perform Conversion Business Object	Business Object-Tested Conversion	MI
	Tests	Programs
CV.110	Perform Conversion Validation Tests	Validation-Tested Conversion	MI
		Programs

ID	Task	Deliverable	Type*
Documentation
DO.060	Publish User Reference Manual	User Reference Manual	IT
DO.070	Publish User Guide	User Guide	IT
DO.080	Publish Technical Reference Manual	Tech Reference Manual	IT
DO.090	Publish System Management Guide	System Management Guide	IT
Business System Testing
TE.060	Prepare Testing Environments	Testing Environments	MI
TE.070	Perform Unit Test	Unit-Tested Modules	MI, IT
TE.080	Perform Link Test	Link-Tested Modules	MI, IT
TE.090	Perform Installation Test	Tested Installation Routines	IT
TE.100	Prepare Key Users for Testing	Prepared Key Users	SI
TE.110	Perform System Test	System-Tested Applications	IT
TE.120	Perform Systems Integration Test	Integration-Tested System	IT
Performance Testing
PT.080	Create Performance Test Transaction	Performance Test Transaction	MI
	Programs	Programs
PT.090	Create Test Database Load Programs	Performance Test Database Load	MI
		Programs
PT.100	Construct Performance Test Database	Performance Test Database	SI
PT.110	Prepare Performance Test Environment	Performance Test Environment	MI, IT
PT.120	Execute Performance Test	Performance Test Results	MI, IT
PT.130	Create Performance Test Report	Performance Test Report	SI
Adoption and Learning
AP.150	Develop User Learningware	User Learningware	MI, IT
AP.160	Prepare User Learning Environment	User Learning Environment	SI
Production Migration
PM.020	Design Production Support	Product Support Infrastructure Design	SI
	Infrastructure
PM.030	Develop Transition and Contingency	Transition and Contingency Plan	SI
	Plan

Transition:

Tasks and Deliverables
The table below lists the tasks executed and the deliverables produced
during Transition.
ID	Task	Deliverable	Type*
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
AP.170	Conduct User Learning Events	Skilled Users	MI, IT
Production Migration
PM.040	Prepare Production Environment	Production Environment	SI
PM.050	Set Up Applications	Configured Applications	MI
PM.060	Implement Production Support	Production Support Infrastructure	SI
	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.
ID	Task	Deliverable	Type*
Adoption and Learning
AP.180	Conduct Effectiveness Assessment	Effectiveness Assessment	SI
Production Migration
PM.090	Measure System Performance	System Performance Assessment	SI
PM.100	Maintain System	Maintained Production Environment	SI
PM.110	Refine Production System	Refined Production Environment	SI
PM.120	Decommission Former Systems	Decommissioned Systems	MI
PM.130	Propose Future Business Direction	Business Direction Recommendations	SI
PM.140	Propose Future Technical Direction	Technical Direction Recommendations	SI
*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.