You are on page 1of 31

AIM methodology for Oracle eBusiness Suite

Overview of AIM (Applications Implementation Method)


Where Used - New implementations & re-implementations of Oracles EBusiness Suite Defining Characteristics: Developed exclusively for Oracle Applications Core & Optional tasks provide flexibility Projects are generally Time and Materials (Build to Suit) Related Pre-Packaged Solutions FastForward/FastForwardRPM/FastForward Flows Projects generally Fixed Time/Fixed Scope/Fixed Cost (RPMs only) Related Advantage Offerings - AIM Advantage

Overview of AIM (Applications Implementation Method) contd.


Where Used - New implementations & re-implementations of Oracles E-Business Suite Defining Characteristics: Developed exclusively for Oracle Applications Core & Optional tasks provide flexibility Projects are generally Time and Materials (Build to Suit) Base Approach Iterative Conference Room Pilots using Information Engineering Approach for Extension Development

Related Pre-Packaged Solutions Business Flow Accelerator Service Offerings


Related Advantage Offerings - N/A
3

Methods What are They?


Road map for getting something done so we dont miss something important so we dont dwell on something that is unimportant so we dont reinvent the wheel Common language/process of communication Common place to identify and document forward progress and decisions A proven approach that can be consistently repeated Representative of best practices

Benefits of Using a Method


Well defined work plans Reduced learning curve Pre-defined guidelines, standards, and deliverable templates Higher quality results Path to success Reduced risk Better communication Projects delivered on time and on budget

Method Concepts: Task


A task is a unit of work that results in output of a single deliverable or revision of an existing deliverable. Tasks may have one or more outcomes/outputs: Setup of an application Creation or update of a document Execution of an activity (i.e Test Plan) Two types of Tasks: Core Optional Tasks
Definition
Operations Analysis Solution Design

Build

Transition

Production

Method Concepts: Phase


Phases are a grouping of tasks that lead to a major project deliverable or milestone
Definition Operations Analysis

Phases
Solution Design Build Transition Production

Phases cut vertically through project activities Are natural points to establish milestones for progress checkpoint

Method Concepts: Process


A process is a grouping of tasks within a method based on common functions or disciplines which lead to one or more key deliverables
Definition Operations Analysis Solution Design Build Transition Production

Processes

Method Concepts: Approach


1. An Approach is a variation or subset of a method, packaged in order to efficiently support the delivery of a service or solution. Examples: Classic/Foundation Approach (can be tailored/ build to suit) Pre-packaged Approach (e.g., pre-defined Solutions such as FastForward) 2. An Approach also refers to the project management techniques/ concepts embodied in a method. Examples: Traditional Information Engineering (IE)/(Structured Waterfall) Dynamic Systems Development Method (DSDM)

AIM for Business Flows Top Level Flow


Definition
Project Planning

Elaboration
Determine Exception Dispositions

Build
Determine Exception Dispositions

Transition
Prepare Production Environment

Production

Update Flows Update Procedures

Update Flows Update Procedures Update Setups Update Test Script Prepare CRP 3.0 Environment Conduct CRP 3.0 Identify Exceptions

Conduct CRP 1.1 (Familiarization)

Update Setups Update Test Script Prepare CRP 2.0 Environment

Convert and Verify Data

Conduct CRP 1.2 (Mapping)

Conduct CRP 2.0 Identify Exceptions

Perform Acceptance Test

Identify Exceptions

Design Extensions

Perform Systems Integration Test

Begin Production

Maintain System

Conduct Business Architecture Workshops

Prepare Custom Test Scripts

Create and test Custom Extensions

Propose Future Direction

10

Classic Phases

Analysis
Business Requirements Definition

Build

Production

Existing Systems Examination


Technical Architecture Database Design and Build Module Design and Build Data Conversion

Documentation
Testing Training Transition Post-System Support

11

AIM Business Flow

12

Common AIM documentation


Conversion standard documentation

Testing standard documentation


Customization standard documentation

13

CV.010 Conversion Requirements and Strategy


Conversion Scope Resources, skills and tools required Conversion approach Conversion process flows Sample CV.10 Data cleanup and testing strategies Acceptance criteria Issue Tracking and Versioning procedures Change and Quality management Also review CV.020 for Conversion Standards
14

CV.040 Conversion Data Mapping


Assumptions specific to a conversion Data Volumes Entities to be converted and their prerequisites Map external data to Oracle Applications tables / APIs Extract File Layout Sample CV.40 Data Cleanup Issues

15

CV.060 Conversion Program Design


Processing Rules Translation Rules Filter Rules Foreign Key Rules Derivation Rules Default Values Validation Logic Conversion Modules Listing

Sample CV.60

16

CV.070, CV.090 Conversion Test Plans, Test Results


Check list for the tester Should explain the testing process in detail All data elements which are important for business testing should be tested Unit Test Test if all the data in the extract has loaded Object Test Verify if a transaction can be executed with the loaded data
Sample CV.70
17

CV.080 Conversion Programs


Actual Conversion Code No document associated with this AIM process

18

CV.120 Conversion Programs Installation


Pre-Installation Steps Installation Steps Verification Make sure that Uninstall steps and uninstall verification steps are provided

Sample CV.120

19

CV.130 Convert and Verify Data


Conversion Execution and Verification Log Prepared by the onsite team during golive
Sample CV.130

20

Most common AIM Documents (Customizations)


MD.030, MD.040 Define Design and Build Standards MD.050 Application Extensions Functional Design MD.070 Application Extensions Technical Design MD.110 Create Application Extension Modules MD.120 Installation Procedures TE.020, TE.030 Unit Test/Link Test Script TE.040 System Test Script TE.070, TE.080 Unit / Link Test Results
21

MD.030, MD.040 Define Design and Build Standards


MD.030 defines design standards for Design documents Forms Reports Database Design Naming MD.040 defines coding standards for File Headers Forms Reports SQL PL/SQL Installation Routines

Sample MD.30

Sample MD.40

22

MD.050 Application Extensions Functional Design


A good MD.050 document should define
Assumptions Functional flow Features Illustrate all the Business Scenarios Sample MD.50 List User Procedures Functional Setups required for implementing the extension

23

MD.070 Application Extensions Technical Design


Form Logic Navigation, Block Relationships, Table Usage, Field Summary Program Logic Arguments, Outputs, Pseudo Code, Data Sources, Validation Logic, SQL statements, Performance considerations Integration Issues Database Design Table changes, DFFs, ValueSets, new database objects Installation Requirements Design, Coding and Testing requirements Sample MD.70

24

MD.110 Create Application Extension Modules


Actual Application Extension Code No document associated with this AIM process

25

MD.120 Installation Procedures


Pre-Installation Steps Installation Steps Verification Make sure that Uninstall steps and uninstall verification steps are provided
Sample MD.120

26

TE.020, TE.030 Unit / Link Test Script


Checklist of items to be checked in the deliverable Detailed instructions on how to test the object Defect Log
Sample TE.20

27

TE.040 System Test Script


Defines the difference scenarios (flows) to be tested Defines Navigation Path, Actions, Data Required and Expected Results

Sample TE.40

28

TE.070, TE.080 Unit / Link Test Results


Document test plans with test results / observations Make sure the observations are detailed

Sample TE.70

29

Ensuring Delivery Quality


(Its your responsibility !! Not the SQAs !!)
Check if version numbers have been updated when a document is modified Author, Creation Date, Last Updated, Document Reference and Version are filled in correctly Verify document versions are updated with each update Maintain Change History Verify Index page Maintain Open / Closed Issues at the end of the document Verify if the document can support itself Peer Review Documents Track Changes, if possible Spill Cheek (Spell Check)

30

AIM Processes

31

You might also like