0.3 aim phases_and_documentations

Menu, Functions and Security Profile
Oracle HRMS Functional Document
AIM Phases and Documentations
Part 0.3
Note: This Document is created only for Class Room Training Purpose
By
Regintala Chandra Sekhar
ora17hr@gmail.com
Regintala Chandra Sekhar Page 1 ora17hr@gmail.com

Menu, Functions and Security Profile
Table of Contents
Oracle Project AIM ....................................................................................................................................................................... 3
AIM Phases: .................................................................................................................................................................................... 3
1. Project Definition ........................................................................................................................................................... 3
2. Operation Analysis ......................................................................................................................................................... 4
3. Solution Design ................................................................................................................................................................ 4
4. Build .................................................................................................................................................................................... 4
5. Transition .......................................................................................................................................................................... 5
6. Production ......................................................................................................................................................................... 5
Trying to understand AIM (Application Implementation Methodology): ............................................................... 6
1. Understand the Existing Business Processes and current business baseline .............................................. 6
2. Creating Future Business Model .................................................................................................................................... 6
3. Business Mapping and Gap Resolution ....................................................................................................................... 7
4. Creation of Application and Technical architecture .............................................................................................. 8
5. Gaps and Interfaces Resolution ..................................................................................................................................... 9
6. Business System Testing ............................................................................................................................................... 10
7. Data Migration .................................................................................................................................................................. 11
8. Documentation ................................................................................................................................................................. 13

Oracle Project AIM
Documents which are Prepared at the time of Implementation
Documents
BR Business Mapping and Gap Resolution 10 30 50 90 100 110
MD Gaps and Interface Resolutions 50 70 80 90 110 120
TE Business System Testing 20 30 40 50 60 70 80 100 110 120 130
BP Business Process Document 40 70 80
CF
CV Data Migration 10 50 60 70 80 90 100 110 130
RD Business Requirement Document 20 50 80
TA Creation of Application and Technical Architecture 10 120 140 150
DO Documentation 50 70 90
AIM Phases:
1. Project Definition
This is the phase of project scoping; project planning, resource planning, phase planning, budgeting and
defining constraints and facilitate crucial informed project startup decisions.
This is also the phase to lay down the communication channel, design an effective infrastructure for delegation
and ensure project executive team is in place. In this phase executive team is engaged in interactive sessions
and project team is organized and oriented.
In case, business process change is applicable, then high-level process scenarios are developed.
The main tasks in this phase are:
 Understanding the current business process and baseline current business process.
 Develop the Preliminary Conceptual Architecture (TA.030).
 Develop TO-BE process model, i.e. determine the high-level architectural, technological, and
configuration requirements to support the functional and information needs of the application system
(BP.080).
 Design improved high-level business processes (BP.070).

2. Operation Analysis
This phase is mainly to drill down to the next levels of details from where it was in the previous phase.
In this phase flow of information, function and process models are captured and detailed with all possible
variants.
This is also the phase to define the detailed function, data, and operational requirements that the new
application system must support and map business requirements to application capabilities and propose
solutions to gaps. This will demonstrate that the proposed business process design is feasible for the
organization. The technical architecture of hardware and software is refined and a transition strategy is for
moving from the current system to the new application system is drawn.
Performance testing models and scenarios should be developed and proposed.
3. Solution Design
The objectives of Solution Design are to produce a design that meets functional requirements within
business, technical, and financial constraints and document the design specifications in a way that facilitates
and supports future maintenance of the system.
In this phase functional and technical designs for custom extensions, interfaces, conversion programs and
database extensions are developed along with security architecture and application set-up and test plans. Also
unit, link, system, and system integration test scripts are developed. Test scripts, test transaction programs and
test data load programs are prepared for taking up system performance testing. User-learning needs and User
Learning Plans are developed in this phase.
4. Build
The objectives of the Build phase is to Develop, test, and accept custom software, including application
extensions, interface programs, data conversion software, custom application subsystems integrated with
Oracle Applications, temporary bridge subsystems which transaction data between legacy and new systems
during multiple
Deployments.
The Application and Database Server Architecture (TA.090), Platform and Network Architecture (TA.120) and
Development Environment (MD.090) are defined prior to start the development work.
In this phase, all documentation deliverables are developed and delivered to customer.
They may be User Reference Manual (DO.060), User Guide (DO.070), Technical Reference Manual (DO.080) and
System Management Guide (DO.090).
The database extension and installation routines are created, tested, and accepted along with performance
testing and reports.

5. Transition
The transition phase is to plan cut-over and actual scheduling of cut-over. This phase calls for preparation of
going live in terms of application, operating environment, user readiness and cut-over plans. This is the period
of end-user training, users learning and adoption plans is executed.
After the application environment is prepared for production instance and all application, database extensions
are in place, the application is loaded with initial configuration set-ups.
Once the initial configuration set-up is ready, the environment is prepared to load application set-ups for
individual modules and master data files are loaded either using loading scripts are using manual process.
The master data is then verified with users and legacy files to assess data accuracy and ensure that masters are
loaded error-free.
The dynamic data files are then extracted from the legacy and verified for their correctness and then loaded
inside application tables using loading scripts or manual process. All these data are cut-off data on a given date.
Generally, the amount of legacy data to be loaded in the new system is as per the agreed migration strategy.
However, the dynamic data needs to be validated to ensure accuracy and its reliability.
By this time all jobs and routines must have been set. Once the migration process is successful, the system is
handed over to production support.
6. Production
This is the period of hand-holding support for the system newly gone live and devote attention to post-implementation
issues like user acceptance

Trying to understand AIM (Application Implementation Methodology):
1. Understand the Existing Business Processes and current business baseline
AS-IS Business Model
RD.020 – Conduct Current Business Baseline (C)
Understand current processes and practices and document the main activities that keep the
organization operating today.
Output: Current Business Baseline
BP.040 – Develop Current Process Model (O)
Examine current business processes and practices and to identify how the existing business system
meets current business requirements.
Output: Current Process Model
2. Creating Future Business Model
TO-BE Business Model
RD.050 – Gather Business Requirements (C)
Define detailed business requirements and perform an initial assessment of
application fit to these requirements.
Output: Business Requirement Scenarios
BP.070 – Develop High-Level Process Designs (C)
Produce high-level designs, documenting how the new organization will operate after
the applications are implemented.
Output: High Level Process Design
BP.080 – Develop Future Process Model (C)
Defining the future business model in the form of integrated process flows built on the
business processes supported by the new applications.
Output: Future Process Model
RD.080 – Identify Reporting and Information Access Requirements (C)
Identify organization’s future reporting requirements.
Output: Master Report Tracking List

3. Business Mapping and Gap Resolution
Mapping and Gap
Identification
BR.030 – Map Business Requirements (C)
Assess the fit of standard application and system features to detailed business
requirements.
Output: Mapped Business Requirements
BR.010 – Analyze High Level Gaps (C)
Compare the process as envisioned in the High-Level Process Designs (BP.070) with
the processes supported by Oracle Applications. The differences (gaps) revealed by this analysis need to be
resolved by producing alternatives that balance change in the application against change in processes and
organization.
Output: High Level Gap Analysis
BR.050 – Conduct Integration Fit Analysis (O)
Identify the new integration points that you require, based on your conceptual
architecture and the mapping of the new applications onto the existing architecture.
Output: Integration Fit Analysis
BR.090 – Confirm Integrated Business Solution (O)
Secure approval for proposed business alternatives.
Output: Confirmed Business Solution
BR.100 – Define Application Set-up (C)
Capture the setup decisions and implement them in the appropriate environment.
Output: Application Setup Document
BR.110 – Define Security Profile (O)
Gather role and function information and relate them to application security and
responsibilities. As business requirements are established and mapped to application features, you also begin
to define the user security necessary to support the selected alternative in a controlled environment.
Output: Security Profile

4. Creation of Application and Technical architecture
System Installation and Environment
Creation
TA.010 – Define Architecture Requirements and Strategy (C)
Identify the application and technical architecture requirements and strategy that
would be used for the design and development of the system being implemented. This includes support for
both the final production environment and interim development and project support requirements.
Output: Architecture Requirements and Strategy
TA.120 – Define Platform and Network Architecture (C)
Define the physical platform and network configuration to support your final platform
and network architecture. You map the physical application and database server architecture onto specific
computing platforms. This task focuses on the future production environment and not interim environments to
support the project activities. This includes ongoing production supporting testing and learning environments.
Output: Platform and Network Architecture
TA.140 – Assess Performance Risk (C)
Identify any performance risks that are apparent based on the proposed architecture
and suggest techniques to mitigate the risks. This task focuses on the future production environment and not
interim environments to support the project activities. This includes ongoing production supporting testing
and learning environments.
Output: Performance Risk Assessment
TA.150 – Define System Management Procedures (O)
Design the procedures and specify the tools that the client staff will need to manage
the new system. After you design the procedures in this task, you need to test and refine them later in the
project, prior to incorporating them into the System Management Guide (DO.090) and conducting learning
events for the system support staff. This task focuses on the future production environment and not interim
environments to support the project activities. This includes ongoing production supporting testing and
learning environments.
Output: System Management Procedure

5. Gaps and Interfaces Resolution
GAP Resolution
MD.050 – Create Application Extension Functional Design (O)
Document the functional features, use, and behavior of required customizations. The
Application Extensions Functional Design confirms that you understand user requirements, and allows users to
evaluate and approve the resulting features that the new modules will provide.
Output: Application Extension Functional Design
MD.070 – Create Application Extension Technical Design (O)
Document the technical specifications for modifications, extensions, and configurable
extensions.
Output: Application Extension Technical Design
MD.080 – Review Application Extension Functional and Technical Designs (O)
Set up a design review meeting between business analysts, key users, technical
analysts, and developers. The goal is to secure final acceptance of the complete designs.
Output: Approved Designs
MD.090 – Prepare Development Environments (C)
Establish a platform and software environment that supports custom development.
Output: Development Environments
MD.110 – Create Application Extension Modules (O)
Produce the modules to support customizations to the Applications. You also perform
the first round of testing as part of this task.
Output: Module Source Code
MD.120 – Create Installation Routines (C)
In this task, you develop automated functions and detailed instructions to install
customizations in the testing and production environments.
Output: Installation Routines

6. Business System Testing
CRP and Module Testing
TE.020/070 – Develop/Perform Unit Test Scripts (C)
TE.020 - Develop the script to test individual application extension components. The tests
validate that the application extension inputs, outputs, and processing logic function as designed.
Output: Unit Test Scripts
TE.070 - Test application extension components on an individual basis to verify that the inputs, outputs, and
processing logic of each application extension component functions without errors. Unit testing is performed in
either the development environment or a testing environment. The goal is to find errors in the smallest unit of
software before you logically link it into larger units. If successful, subsequent link testing should only reveal
errors related to the integration between application extensions.
Output: Unit-Tested Modules
TE.030/080 – Develop/Perform Integrated Test Scripts (C)
TE.030 - Develop scripts to test modifications to standard Oracle Applications as well as new
application extensions as part of a business flow. This uncovers any integration problems with other
application extension components that provide or use the data manipulated by the target modules.
Output: Integrated Test Scripts
TE.080 - Test several application extension components together as part of a business flow to uncover any
integration problems with other application extension components that provide or use the data manipulated by
the target component. Link testing is performed in either the development environment or a testing
environment. The scope of each link test typically includes the set of components that support or are affected
by a single application extension. An application extension is defined for each gap identified during
requirements mapping and is described by a functional design and corresponding technical design document.
Output: Link-Tested Modules
TE.100 – Prepare Key Users for Testing (C)
Provide basic training to key users participating in Business System Testing. A test
environment is used to prepare key users for testing.
Output: Prepared Key Users
TE.040/110 – Develop/ Perform System Test Scripts (C)
TE.040 - Develop the script to test the integration of application extensions with Oracle
Applications modules. A system test script contains detailed steps which testers follow to verify the system
setup and the integrity of custom application extensions for supporting business processes.
Output: System Test Scripts
TE.110 - Test the integration of all business system flows within the target application system, including all
standard and custom processes and reports. This task is equivalent to a full conference room pilot (CRP) where
the environment simulates the future production environment. The system test is performed in a test
environment.
Output: System Tested Applications

TE.050/120 – Develop/ Perform System Integration Test Scripts (O)
TE.050 - Develop the test script that validates the integration between your new application
system and other third-party and legacy systems.
Output: System Integration Test Scripts
TE.120 - Test system’s integration with other application systems in a production-like environment. The
systems integration test is performed in a test environment.
Output: Integration Tested System
TE.060 – Develop Testing Environments (C)
Install and configure one or more testing environments to support all testing activities.
Output: Testing Environments
TE.130 – Perform Acceptance Testing (C)
Support users in performing their acceptance test of the new production system. The
acceptance test is performed in the Production Environment. This task also involves scheduling the acceptance
test team, support staff, and user facilities.
Output: Acceptance Test Results
7. Data Migration
Migration
CV.010 – Define Data Conversion (Migration) Strategy (C)
Define the scope of the conversion project, conversion objectives and approach, and
prepare a strategy for converting information from the legacy systems to the new application
environment. Part of defining the scope is documenting your conversion requirements at the
application and business object level. Additionally, this task provides a roadmap for performing the
conversion of data from the legacy system to the new Oracle system and defines the task steps and
resources needed to fulfill this strategy.
Output: Data Conversion Requirements and Strategy
CV.050 – Define Manual Data Conversion (Migration) Procedures (C)
Define the plan to convert the business objects that require manual conversion. The
resulting procedure provides a detailed guide for manually converting data to successfully meet
conversion project milestones.
Output: Manual Conversion Procedures
CV.060/070/080 – Design/ Prepare/ Develop Conversion Programs (O)
CV.060 - Design and document the conversion programs. Completion of this task provides the
developer with the necessary information for writing an accurate conversion program.
Output: Conversion Program Designs

CV.070 - Outline the testing plans for the unit, business object, and validation testing for
conversion. The unit tests confirm that each module successfully completes the task it is designed to
perform. For example, a unit test should verify that the download program has extracted the expected
number of records from the legacy system. The business object test verifies that the quality of the data
converted to the Oracle system is accurate and a function properly in the individual Oracle Application
to which it has been converted. Validation testing verifies that the converted legacy data performs
accurately within the entire suite of Oracle Applications.
Output: Conversion Test Plans
CV.080 - Create the conversion programs that perform all of the functions required to convert legacy
business objects to the target Oracle Applications. The conversion of each business object typically
involves the creation of five types of programs, including a download program, interface table
creation program, upload program, translation program, and an interface and validation program. The
download program is used to extract the data from the legacy system and create an ASCII flat file that
can be uploaded to the Oracle tables. The interface table creation program creates tables that store the
legacy data before the data is validated and inserted into the production tables of the Oracle
Application. The upload program uploads the legacy ASCII flat file data to the interface tables, while
the translation program performs any data-required translation, transformation, or manipulation
required before moving the data to the production tables. Finally, the interface and validation
program performs validation of the data in the interface tables and updates the data into the Oracle
production tables.
Output: Conversion Programs
CV.090/100/110 – Perform Conversion Unit/ Business Object / Validation Tests (C)
CV.090 - Test the conversion programs to verify that all programs work without errors
and according to the conversion testing specifications pre-defined in the conversion unit testing
components of the Conversion Test Plans (CV.070).
Output: Unit Tested Conversion Programs
CV.100 - Test the complete conversion of each business object by executing all conversion modules
for the business object in the appropriate sequence and verify that the resulting data is correct.
Output: Business-Object Tested Conversion Programs
CV.110 - Validate that the target applications function correctly with the converted business objects.
Output: Validation Tested Conversion Programs
CV.130 – Convert and Verify Data (C)
Convert and migrate the production data from the old system to the new Oracle
production environment. Completion of this task provides data that is ready for production use.
Output: Converted and Verified Data

8. Documentation
Documentation
DO.050 – Produce Documentation Prototypes and Templates
Build and review a single prototype for each type of documentation deliverable. The results
conform to the look and feel of each documentation deliverable, as well as present a clear expectation
of what will be delivered. You also create templates for later use.
Output: Documentation Prototypes and Templates
DO.070 – Publish User Guide
Publish a User Guide that defines a set of detailed procedures for using the applications. This
task is often performed in parallel with Perform System Test (TE.110).
Output: User Guides
DO.090 – Publish System Management Guide
Gather material for the System Management Guide and publish the final version. Perform this
task in parallel with the execution of the business system test.
Output: System Management Guide
Thank you.......
Regintala Chandra Sekhar
You can get more documents on my blogger: http://ora17hr.blogspot.com
Facebook Group: www.facebook.com/groups/ora17hr

0.3 aim phases_and_documentations

More Related Content

What's hot (20)

Viewers also liked (16)

Similar to 0.3 aim phases_and_documentations (20)

Recently uploaded (20)

0.3 aim phases_and_documentations