Sie sind auf Seite 1von 324

ORACLE METHODSM

APPLICATION
IMPLEMENTATION
METHOD HANDBOOK

Release 2.0.0
July, 1997

Enabling the Information Age™


Application Implementation Method (AIM) Method Handbook, Release 2.0.0
Part No. A53968-01
Copyright © July, 1997, Oracle Corporation
All rights reserved. Printed in the U.S.A.
Authors: Jennifer Bennett, Anne Blaylock, Jim Lange, Craig Martell, William Matson,
Josyf Mychaleckyj, Janet Price, Bob Reary
Editors: Linda Cherney, Mary Sanders
The programs are not intended for use in any nuclear, aviation, mass transit, medical, or
other inherently dangerous applications. It shall be licensee’s responsibility to take all
appropriate fail-safe, back up, redundancy and other measures to ensure the safe use of
such applications if the Programs are used for such purposes, and Oracle disclaims
liability for any damages caused by such use of the Programs.
This software/documentation contains proprietary information of Oracle Corporation; it is
provided under a license agreement containing restrictions on use and disclosure and is
also protected by copyright law. Reverse engineering of the software is prohibited.
If this software/documentation is delivered to a U.S. Government Agency of the
Department of Defense, then it is delivered with Restricted Rights and the following legend
is applicable:
Restricted Rights Legend Programs delivered subject to the DOD FAR Supplement
are ‘commercial computer software’ and use, duplication and disclosure of the
Programs shall be subject to the licensing restrictions set forth in the applicable Oracle
license agreement. Otherwise, Programs delivered subject to the Federal Acquisition
Regulations are ‘restricted computer software’ and use, duplication and disclosure of
the Programs shall be subject to the restrictions in FAR 52.227-14, Rights in Data --
General, including Alternate III (June 1987). Oracle Corporation, 500 Oracle Parkway,
Redwood City, CA 94065.
The information contained in this document is subject to change without notice. If you find
any problems in the documentation, please report them to us in writing. Oracle
Corporation does not warrant that this document is error free.
ORACLE, Designer/2000, Developer/2000, SQL*Plus, SQL*Loader, SQL*Net,
CASE*Method, ORACLE Parallel Server, PL/SQL, Pro*C, SQL*Module are registered
trademarks of Oracle Corporation, Redwood City, California.
AIM Advantage, CDM Advantage, PJM Advantage, Oracle Cooperative Applications,
Oracle Financials, Oracle Alert, Oracle Manufacturing, Oracle Inventory, Oracle Bills of
Material, Oracle Engineering, Oracle Capacity, Oracle Commissions, Oracle Master
Scheduling, Oracle MRP, Oracle Work in Process, Oracle General Ledger, Oracle Assets,
Oracle Order Entry, Oracle Cost Management, Oracle Payables, Oracle Receivables, Oracle
Personnel, Oracle Payroll, Oracle Purchasing, Oracle Quality, Oracle Sales and Marketing,
Oracle Service, and Application Object Library are trademarks of Oracle Corporation,
Redwood City, California.
Oracle Method is a service mark of Oracle Corporation, Redwood City, California.
Microsoft and MS-DOS are registered trademarks and Windows, Word for Windows,
Powerpoint, Excel, and Microsoft Project are trademarks of Microsoft Corporation. Visio is
a trademark of Visio Corporation. Project Workbench and Project Bridge Modeler are
registered trademarks of Applied Business Technology. All other company or product
names mentioned are used for identification purposes only and may be trademarks of their
respective owners.
Preface

T he Application Implementation Method Handbook provides an overview


of the various approaches, phases, processes, and tasks of the
Application Implementation Method (AIM). AIM is Oracle’s full life-
cycle approach for implementing applications.

This handbook contains the information needed by project managers,


sponsors, and team members to understand the scope of an application
implementation effort and to plan and execute AIM projects.

This handbook, and the Application Implementation Method itself, are


part of Oracle MethodSM —Oracle’s integrated approach to solution
delivery.

Oracle Method Preface i


Audience

The Application Implementation Method Handbook is a high-level


description of how AIM can be used to facilitate implementation
projects. Project managers will use this handbook for project planning
and scheduling. Team members can use this book to gain a broad
understanding of AIM. It also provides a context for the detailed
information in the Process and Task Reference manual.

How the Manual is Organized

This handbook consists of an overview of AIM, chapters on each AIM


phase, and several appendices.

Introduction: This chapter presents an overview of AIM and how to


determine a project approach. It provides guidance in estimating
resources and discusses how AIM incorporates Oracle’s Project
Management Method (PJM).

Phase Chapters: Each phase chapter consists of a phase overview and a


section on the approach to completing that phase. The chapters provide
the following information:

Phase Overview:

• Objectives — describes the objectives of the phase


• Critical Success Factors — lists the success factors of the phase
• Overview Table — lists the process, prerequisites, and key
deliverables
• Prerequisites — lists task prerequisites and their sources
• Processes — lists and defines the processes used in the phase
• Key Deliverables — lists and defines the deliverables for the
phase

ii Preface AIM Method Handbook


Approach:

• Tasks and Deliverables – lists the tasks executed and the


deliverables produced
• Task Dependencies – illustrates the dependencies between tasks
• Managing Risks – provides assistance in reducing the risks
associated with this phase
• Tips and Techniques – discusses helpful tips and techniques
• Estimating – illustrates the relative effort of tasks within the
phase by role
• Scheduling – discusses the approach to scheduling this phase
• Staffing – provides suggestions for staffing this phase

Appendix A: Appendix A provides a work breakdown structure for


the Classic approach.

Appendix B: Appendix B provides a description of the roles used in


AIM.

Appendix C: Appendix C lists the roles used in AIM, the tasks


performed by each role, and the percentage of task time assigned to the
role.

Appendix D: Appendix D provides the AIM data model, including


entities and their relationships, as well as definitions and entity
examples.

Glossary: The Glossary contains definitions of terms, abbreviations,


and acronyms used in AIM.

How to Use this Manual

The Application Implementation Method Handbook contains general


information about using AIM for application implementation projects.
Use this handbook in conjunction with the Application Implementation
Process and Task Reference, which provides detailed information on
processes and tasks. Together, the handbook and reference provide a
complete guide for planning and executing application
implementations.

Oracle Method Preface iii


Conventions Used in this Manual

Several notational conventions are used to make this handbook easy to


read.

Capitalization
Names of tasks, deliverables, processes, and phases are given initial
capitals. For example, Gather Business Volumes task, Business Volume
Requirements deliverable, Business Requirements Definition process,
and Design phase.

Abbreviations and Acronyms


Occasionally, it is necessary to use abbreviations and acronyms when
adequate space is not available. The Glossary lists definitions of all
acronyms and abbreviations.

Suggestions
Helpful suggestions appear throughout the handbook to help you get
the most out of the method. They are highlighted with an illuminated
light bulb. Here is an example of a suggestion:

Suggestion: Verify your backup and recovery plan with your


hardware and software vendors.

Attention
Important information or considerations that save time or simplify tasks
are marked with an attention graphic. Here is an example:

Attention: Since project team training occurs simultaneously


with this task, some recommendations (or decisions) from
training may be implemented in the mapping environment.
In this case, these training inputs become predecessors to this
task.

For More Information


Throughout the handbook we alert you to additional information you
may want to review. This may be a task section, appendix, or reference
manual. Here is an example of a reference graphic:

iv Preface AIM Method Handbook


Reference: Hickman, Linda and Longman, Cliff Case*Method
Business Interviewing. Addison-Wesley. 1994
ISBN 0-2-1-59372-6

Related Publications

Books in the AIM suite include:

• A Quick Tour of AIM


• AIM Method Handbook (this book)
• AIM Process and Task Reference - Volume 1
• AIM Process and Task Reference - Volume 2

Each of these books and their relationships to each other is discussed in


A Quick Tour of AIM.

You may also refer to the following Project Management Method (PJM)
suite of reference books:

• PJM Method Handbook


• PJM Process and Task Reference
• PJM Deliverable Reference

Oracle Method Preface v


Your Comments are Welcome

Oracle Corporation values and appreciates your comments as an Oracle


AIM practitioner and reader of the handbook. As we write, revise, and
evaluate our documentation, your comments are the most valuable
input we receive. If you would like to contact us regarding this
reference or any other AIM or Oracle Method manuals, please use the
following address:

Oracle Method - Application Implementation Group


Oracle Corporation
500 Oracle Parkway
Mailstop 30P16
Redwood Shores, CA 94065

For email inquiries use the following Internet address:

aiminfo@us.oracle.com

Please provide the following information:

• AIM user name


• company name
• company address
• telephone number

Please use these channels to send comments only. Contact your local
Oracle Consulting Services office for technical questions about using the
software tools.

vi Preface AIM Method Handbook


CONTENTS

CHAPTER 1 Introduction to AIM .................................................................................1-1

What is AIM? .............................................................................................1-2

Processes in AIM .......................................................................................1-3

AIM Project Phases.................................................................................. 1-10

Determining a Project Approach............................................................ 1-15


Critical Success Factors .................................................................... 1-15
Selecting an AIM Implementation Approach................................. 1-18
Multiple Deployment Phase Considerations .................................. 1-21
Level of Process/Requirements Analysis ....................................... 1-22
Acceleration Techniques .................................................................. 1-23
Estimating AIM Projects ......................................................................... 1-28

Managing an AIM Project ....................................................................... 1-31


Tailoring the Method........................................................................ 1-33
Working on Multi-site/Multi-phase Projects ................................. 1-34
Using AIM with a User Method ...................................................... 1-35

CHAPTER 2 Definition ..................................................................................................2-1

Overview ....................................................................................................2-2
Objectives ............................................................................................2-2
Critical Success Factors ......................................................................2-2
Overview Table...................................................................................2-3
Prerequisites ........................................................................................2-4
Processes..............................................................................................2-6

Oracle Method Contents vii


Key Deliverables ................................................................................. 2-7
Approach.................................................................................................. 2-10
Tasks and Deliverables..................................................................... 2-10
Task Dependencies ........................................................................... 2-12
Managing Risks................................................................................. 2-14
Tips and Techniques......................................................................... 2-16
Estimating.......................................................................................... 2-22
Scheduling ......................................................................................... 2-24
Staffing............................................................................................... 2-27

CHAPTER 3 Operations Analysis................................................................................. 3-1

Overview.................................................................................................... 3-2
Objectives ............................................................................................ 3-2
Critical Success Factors ...................................................................... 3-2
Overview Table................................................................................... 3-3
Prerequisites........................................................................................ 3-5
Processes.............................................................................................. 3-6
Key Deliverables ................................................................................. 3-8
Approach.................................................................................................. 3-13
Tasks and Deliverables..................................................................... 3-13
Task Dependencies ........................................................................... 3-16
Managing Risks................................................................................. 3-20
Tips and Techniques......................................................................... 3-23
Estimating.......................................................................................... 3-28
Scheduling ......................................................................................... 3-30
Staffing............................................................................................... 3-34

CHAPTER 4 Solution Design ........................................................................................ 4-1

Overview.................................................................................................... 4-2
Objectives ............................................................................................ 4-2
Critical Success Factors ...................................................................... 4-2
Overview Table................................................................................... 4-3
Prerequisites........................................................................................ 4-6
Processes.............................................................................................. 4-8
Key Deliverables ................................................................................. 4-9
Approach.................................................................................................. 4-13
Tasks and Deliverables..................................................................... 4-13
Task Dependencies ........................................................................... 4-16
Managing Risks................................................................................. 4-20

viii Contents AIM Method Handbook


Tips and Techniques......................................................................... 4-23
Estimating.......................................................................................... 4-28
Scheduling ......................................................................................... 4-30
Staffing............................................................................................... 4-34

CHAPTER 5 Build ...........................................................................................................5-1

Overview ....................................................................................................5-2
Objectives ............................................................................................5-2
Critical Success Factors ......................................................................5-2
Overview Table...................................................................................5-3
Prerequisites ........................................................................................5-5
Processes..............................................................................................5-8
Key Deliverables .................................................................................5-9
Approach.................................................................................................. 5-13
Tasks and Deliverables..................................................................... 5-13
Task Dependencies ........................................................................... 5-16
Managing Risks................................................................................. 5-18
Tips and Techniques......................................................................... 5-20
Estimating.......................................................................................... 5-24
Scheduling ......................................................................................... 5-26
Staffing............................................................................................... 5-28

CHAPTER 6 Transition...................................................................................................6-1

Overview ....................................................................................................6-2
Objectives ............................................................................................6-2
Critical Success Factors ......................................................................6-2
Overview Table...................................................................................6-3
Prerequisites ........................................................................................6-5
Processes..............................................................................................6-6
Key Deliverables .................................................................................6-7
Approach....................................................................................................6-9
Tasks and Deliverables.......................................................................6-9
Task Dependencies ........................................................................... 6-10
Managing Risks................................................................................. 6-12
Tips and Techniques......................................................................... 6-13
Estimating.......................................................................................... 6-16
Scheduling ......................................................................................... 6-18
Staffing............................................................................................... 6-20

Oracle Method Contents ix


CHAPTER 7 Production ................................................................................................. 7-1

Overview.................................................................................................... 7-2
Objectives ............................................................................................ 7-2
Critical Success Factors ...................................................................... 7-2
Overview Table................................................................................... 7-3
Prerequisites........................................................................................ 7-4
Processes.............................................................................................. 7-5
Key Deliverables ................................................................................. 7-5
Approach.................................................................................................... 7-7
Tasks and Deliverables....................................................................... 7-7
Task Dependencies ............................................................................. 7-8
Managing Risks................................................................................... 7-9
Tips and Techniques........................................................................... 7-9
Estimating.......................................................................................... 7-12
Scheduling ......................................................................................... 7-14
Staffing............................................................................................... 7-16

APPENDIX A AIM Work Breakdown Structure .......................................................... A-1

AIM Classic Approach Work Breakdown Structure ............................. A-2

APPENDIX B AIM Roles................................................................................................. B-1

Role Descriptions.......................................................................................B-2

APPENDIX C Role Usages .............................................................................................. C-1

Role Usages ............................................................................................... C-2

APPENDIX D AIM 2 Data Model...................................................................................D-1

Purpose and Objective of the Data Model.............................................. D-2

AIM Data Object Definitions ................................................................... D-4


Relationship to AIM Processes, Tasks, and Deliverables ............... D-4
Relationship to the AIM Glossary .................................................... D-4
Data Object Definitions ..................................................................... D-4

GLOSSARY

x Contents AIM Method Handbook


CHAPTER

1 Introduction to AIM

T his chapter discusses the content and structure of Oracle’s


Application Implementation Method (AIM).

Business Requirements Definition

Business Requirements Mapping

Application and Technical Architecture

Module Design and Build

Data Conversion

Documentation

Business System Testing

Performance Testing

Training

Production Migration

Figure 1-1 Application Implementation Process Overview Diagram

Oracle Method Introduction to AIM 1 - 1


What is AIM?
Oracle’s Application Implementation Method (AIM) is a proven
approach for implementing packaged applications. It is comprised of
well-defined processes that can be managed in several ways to guide
you through an application implementation project. AIM provides the
tools needed to effectively and efficiently plan, conduct, and control
project steps to successfully implement business solutions.

AIM defines business needs at the beginning of the project and


maintains their visibility throughout the implementation. It defines
internal, external, and time-sensitive business events and maps each
event to the responding business and system processes. Using this
method, the business community gains an accurate understanding of
the business requirements to be met by the final system.

AIM was developed primarily for moderate- and large-sized projects,


but is also applicable to smaller projects. Although it is designed to be
used in Oracle Applications projects, with minor changes in technique,
AIM can be applied to other technologies and appropriate products as
well.

AIM meets the demand for faster business solutions. While traditional
implementations make it difficult to realize business benefits quickly,
AIM defines the fastest route to implementation, thereby reducing the
implementation life cycle.

1 - 2 Introduction to AIM AIM Method Handbook


Processes in AIM
AIM tasks are organized into processes. Each process represents a
related set of objectives, resource skill requirements, inputs, and
deliverable outputs. A task can belong to only one process. Project
team members are usually assigned to a process according to their
specialization and background.

Figure 1-2 illustrates the AIM processes and the process overlap that
occurs during a project. The extent to which overlap is permitted is a
function of task prerequisites and the availability of project resources.

Business Requirements Definition

Business Requirements Mapping

Application and Technical Architecture

Module Design and Build

Data Conversion

Documentation

Business System Testing

Performance Testing

Training

Production Migration

Figure 1-2 Processes in AIM

This section provides a brief overview of the AIM processes:

• Business Requirements Definition


• Business Requirements Mapping
• Application and Technical Architecture
• Module Design and Build
• Data Conversion
• Documentation
• Business System Testing
• Performance Testing

Oracle Method Introduction to AIM 1 - 3


• Training
• Production Migration

Business Requirements Definition


Business Requirements Definition defines the business needs that must
be met by the implementation project. You document business
processes by identifying business events and describing the steps that
respond to these events. You then organize processes into scenarios
that reflect the business requirements. The project team conducts a
Current Business Baseline to ensure requirements are considered, then
constructs future business process and function models to portray
future business requirements.

As part of Business Requirements Definition, the company’s financial


and operating structure is identified, business transactions volumes are
documented, and storage requirements are determined. Audit and
control considerations for financial and system administration further
define security and operating requirements.

Business Requirements Mapping


Business Requirements Mapping compares the 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 are then mapped to
application functionality.

As gaps between requirements and functionality emerge, they are


resolved by documenting workarounds, alternative solutions,
application extensions, or by changing the underlying business process.

After business processes have been mapped to the application and gaps
resolved, the project team documents how the business will operate
using the new system.

Application and Technical Architecture


During the Application and Technical Architecture you design an
information systems architecture that reflects your business vision.
Using the business and information systems requirements, this process
facilitates development of a plan for deploying and configuring:

• Oracle, third-party, and custom applications

1 - 4 Introduction to AIM AIM Method Handbook


• supporting application databases
• critical enterprise interfaces and data distribution mechanisms
between applications, servers, and data centers
• computing hardware including servers and client desktop
machines
• networks and the data communications infrastructure

A coherent and well-designed information systems architecture is a


critical success factor for any implementation project. The information
systems architecture design should be:

• derived from balanced input of business and technical


requirements
• consistent with the corporate business vision and provide the
information technology framework to achieve it
• realistic about the capabilities and limitations of the technology
on which it is based

The first bullet above is especially important because the architecture


part of an implementation project is often considered to be purely
technical in nature, with the resulting risk that the business
requirements are treated as subservient to the technology. A well-
managed architecture project uses the business requirements and
functional mapping as drivers for:

• optimal configuration of the applications being implemented


• hardware and network infrastructure providing the applications
processing
• tools and procedures needed to manage the complete system

To arrive at an architecture for the newly implemented systems, the


architecture team may need to consider the following types of complex
issues:

• the best deployment strategy for the applications across one or


more data centers, business organizations, and business functions
• the high-level configuration of the applications to support
financial, administration, manufacturing, and distribution
business units
• interface points between the applications and/or remote sites,
including specifications, dataflows, and mechanisms

Oracle Method Introduction to AIM 1 - 5


• the deployment and capacity planning for the hardware and
network infrastructure that will support the applications
processing
• management tools and procedures that will enable the system to
continue to operate as intended

Relative to other processes, the architecture process occurs early in an


implementation project. While the formal process is active only during
Definition, Operations Analysis, and Solution Design, architecture
deliverables are required and used throughout the entire
implementation project. This is because the architecture process defines
the framework for the technical aspects of the future system and also for
the project that is defining and creating the new system.

Both application and technical architecture designs become more


detailed and concrete as they progress from Definition through
Operations Analysis to Solution Design. It is important to consider both
aspects of architecture throughout the process so that a top-to-bottom
view of the future system architecture is created early. Any issues that
affect the technical architecture can then be assessed in the context of
the application architecture design, and vice versa.

Module Design and Build


Module Design and Build produces custom software solutions to gaps
in functionality identified during Business Requirements Mapping.
Custom software solutions include program modules (forms, reports,
zooms, alerts, database triggers) that must be designed, built, and tested
before they can be incorporated into the system. Module Design and
Build addresses the design and development of the custom modules;
Business System Testing supports testing of custom modules.

Working together, technical analysts and business analysts define the


specific custom extensions needed to support the requirements and then
estimate the work effort required to design and build the extensions.
Module designers write functional and technical specifications for each
module that together comprise the detailed design. Programmers code
new modules or modify existing modules based on the detailed design
documents.

Data Conversion
Data Conversion defines the tasks and deliverables required to convert
legacy data to the Oracle Applications tables. The first step of this
process explicitly defines the business objects that are required for
conversion and the legacy source systems that store these objects. The

1 - 6 Introduction to AIM AIM Method Handbook


converted data may be needed for system testing, training, and
acceptance testing, as well as for production.

An overall strategy determines how the conversion requirements will be


met. Both automated and manual methods should be considered as
possible solutions. The conversion process includes designing, building,
and testing the required conversion programs as well as the actual
conversion of the legacy data.

Documentation
Documentation begins with materials created early in the project. Using
detailed documents from the project, the writing staff develops user and
technical material that is tailored to the implementation.

A complete documentation set includes a System Management Guide,


User Guide, User Reference Manual, Technical Reference Manual and
online help text. Producing prototypes for each document encourages
early consensus on documentation design, format, and content.

Business System Testing


Early in the project life cycle, Business System Testing focuses on linking
test requirements back to business requirements and securing project
resources needed for testing. It supports utilizing common test
information including data profiles to promote testing coordination and
to minimize duplication of test preparation and execution effort.

Business System Testing provides a formal integrated approach to


testing. The primary deliverable is a high-quality application system,
including packaged applications components and custom extensions.

Performance Testing
Performance Testing enables you to define, build, and execute a
performance test. It does not assume a particular scope for the
performance test. You can use the same process to define a complex
test on an entire system, or a simpler test on a component or subset of
the system. You may also initiate the process more than once on a
project with differing scope and objectives to test the performance of
different aspects of your system. The specific goals of each process and
the relative timing within a project may be different, but the method
you use can be the same.

As a primary benefit, this process provides a powerful and direct means


of assessing the performance quality of your system. Use the results to

Oracle Method Introduction to AIM 1 - 7


make decisions on whether the performance is acceptable for the
business and to help propose tactical or strategic changes to address the
performance quality shortfall. If the performance characteristics you
measure prove to be unacceptable, you can implement tuning to
improve the performance quality or, alternatively, propose a change in
the system architecture to provide the improvement you desire.
Performance Testing is closely related to Application and Technical
Architecture; they are interdependent.

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. Technical analysts create or set up transaction
programs to simulate system processing within the scope of the test and
populate a volume test database against which to execute the
transactions. Once the system and database administrators have
created the test environment, the test is executed by the project team
and the final results are documented.

Training
Training prepares both users and administrators to take on the task of
running the new application system. It includes development of
materials and methods, as well as administration. Instructors and
courseware developers orient their material toward roles and jobs, and
not toward application modules.

AIM distinguishes between education and training. Education provides


an understanding of the fundamentals of how the business operates in a
certain type of environment; training refers to the Oracle products and
skills courses.

Production Migration
Production Migration 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.

During Production Migration, the project team deploys the finished


solution into the organization. This transition depends on Business
Requirements Mapping, Module Design and Build, Data Conversion,
Business System Testing, Training, and Documentation for fully tested
business solutions, custom extensions, conversion programs,
documentation, and training materials. Transition is complete when
data has been converted and verified and users have started using the

1 - 8 Introduction to AIM AIM Method Handbook


new system. When the system is stabilized, regular maintenance and
system refinement begins. In addition, management begins preliminary
planning of the company’s future business and technical direction as it
relates to the new systems.

Oracle Method Introduction to AIM 1 - 9


AIM Project Phases
Conduct an AIM project in phases that provide quality and control
checkpoints to coordinate project activities that have a common goal.
During a project phase, your project team will be executing tasks from
several processes. Figure 1-3 illustrates the relationship between phases
and processes.

Definition Operations Solution Build Transition Production


Analysis Design

Business Requirements Definition

Business Requirements Mapping

Application and Technical Architecture

Module Design and Build

Data Conversion

Documentation

Business System Testing

Performance Testing

Training

Production Migration

Figure 1-3 AIM Context Diagram

Following is a description of each AIM phase:

Definition
During Definition you plan the project, review the organization’s
business objectives, and evaluate the feasibility of meeting those
objectives under time, resource, and budget constraints. The emphasis
is on building an achievable workplan and introducing it with
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.

To achieve an early understanding of current business operations and


future processes, the team also performs baselining and process
modeling during this phase.

1 - 10 Introduction to AIM AIM Method Handbook


The goal is to identify business and system requirements, propose the
future business model, and determine the current application and
information technology architecture. The information gathered
provides input to downstream activities in subsequent phases. The
team reviews financial, operational, technical, and administrative
processes to verify that everyone understands and agrees on the
detailed business requirements. All business requirements are
associated with planned future business processes. Sharing an accurate
understanding of these requirements is a critical success factor to the
project.

Operations Analysis
During Operations Analysis, the project team develops Business
Requirements Scenarios based on deliverables from Definition that are
used to assess the level of fit between the business requirements and
standard application functionality. Gaps are identified and
corresponding solutions developed. The analysis results in a proposal
for conducting business operations under the envisioned application
technical architecture. Solutions for gaps evolve into detailed designs
during Solution Design.

A model for the application architecture is created and the technical


architecture is designed. The technical architecture includes high-level
hardware, software, and communications components to support the
future business system. The Application and Technical Architecture
documents are used to develop detailed designs during Solution
Design.

To develop models of future business operations you must verify your


initial assumptions regarding solutions for gaps. Solutions may require
only minor modifications to forms, reports, and programs. The team
should explore workarounds to application gaps before considering
custom modifications or new development. If solutions require custom
development, the team prepares high-level solution documents. These
documents include general descriptions of the required features and a
work estimate for each customization. The customization approach and
estimates are approved before detailed design begins during Solution
Design.

The Performance Testing team creates models for testing the


performance characteristics of the new system. These models usually
focus on critical system processing associated with key business
functions and transactions.

Oracle Method Introduction to AIM 1 - 11


Finally, a transition strategy is developed for migrating the company
from the current to the future way of doing business.

Solution Design
The purpose of Solution Design is to develop the detailed designs for
the optimal solutions to meet the future business requirements. During
this phase, project team members create detailed narratives of process
solutions developed during Operations Analysis.

Supporting business requirements may require building application


extensions to standard features; several alternative solutions may have
been defined during Operations Analysis. The project team carefully
scrutinizes these solutions and chooses the most cost effective
alternatives.

To design effective business solutions, you should make sure that


planned user roles and job procedures are efficient. When designing
solutions, consider organizational changes, process improvement, and
reengineering initiatives to the extent that these are within project scope.
These initiatives often affect how application features should be utilized.

While solution 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
custom solutions 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.

As solutions to business requirements are created you will begin to


develop operating documentation. As the system is refined the
documentation is revised.

Business process design is iterative. Tasks that span both Operations


Analysis and Solution Design may be performed as a unit by a design
team.

Build
The coding and testing of all customizations and other custom software
including enhancements, data conversions, and interfaces are done
during Build. Policy and procedure changes relating to business
process modifications are developed. Business system testing is
performed to validate that the developed solutions meet business
requirements.

1 - 12 Introduction to AIM AIM Method Handbook


If customizations, extensions, or conversions are not required, Build is
still important because it includes the business system test, which is
commonly conducted as a formal conference room pilot. The business
system test validates the solutions and is performed in an environment
that closely resembles production.

During Build the performance testing team creates performance testing


components and executes the performance tests. Developers produce
unit-tested program modules. Integration, performance, and business
system tests are performed and a working, tested business system
solution is delivered at the end of the phase.

Transition
During Transition, the project team deploys the finished solution into
the organization. All the elements of the implementation must come
together to transition successfully to actual production. The project
team trains the end users while the technical team configures the
production environment and converts data. Transition ends with the
cutover to production, when end users start performing their job duties
using the new system.

Transition is a demanding experience for the project team and, in


particular, for the end users who have to maintain two systems until
production is declared. Managing changes and buffering your
organizations from negative impacts must be a top priority.
Preparation and planning in advance facilitates the transition process.

If a phased deployment approach 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. Included in this final phase is a series of refinements and
performance measurement steps. The Information Systems (IS)
personnel work quickly to stabilize the system and begin regular
maintenance. They will provide the ongoing support to the
organization for the remaining life of the system. During Production,
you compare actual results to project objectives. System refinement
begins in a controlled manner to minimize impact to end users. Finally,
you start preliminary planning of the future business and technical
direction of the company.

Oracle Method Introduction to AIM 1 - 13


If multiple deployment exists, Production will occur at different times
for the various geographical sites and/or business units.

1 - 14 Introduction to AIM AIM Method Handbook


Determining a Project Approach
When deciding on the project approach for your implementation
consider the following dimensions:

• Scope—project objectives, business functions, sites, and


applications addressed
• Cost/Time/Quality—the balance among cost, implementation
speed, and quality in meeting requirements
• Risk—the potential of an adverse condition occurring that will
impact the project or the organization
• Track Record—the approaches that have or have not worked in
the past for this organization
• Resources—the resource constraints that affect the practicality of
certain project approaches

Critical Success Factors

Critical success factors may affect the selection of a project approach.


The following table shows typical critical success factors and the impact
they can have on the success of the implementation.

Internal/
External to
Critical Success Factor Percent Impact Project

Sufficient infrastructure 10 External

Clear understanding of business 15 External


needs

Upper management support 20 External

Strong program/project 20 Internal


management

Team strength 15 Internal

Oracle Method Introduction to AIM 1 - 15


Internal/
External to
Critical Success Factor Percent Impact Project

Organizational readiness 10 External

Sufficient technical architecture 10 External

Table 1-1 Impact of Critical Success Factors

Sufficient Infrastructure
It is possible to attempt an application implementation where the
demands on the information systems infrastructure are too great.
Determine how far you can realistically stretch the infrastructure over a
specific period of time.

Clear Understanding of Business Needs


Before starting a project, do not assume that the organization has a clear
understanding of its needs. Even if there is a clear understanding of the
perceived business problems to be addressed there may be additional
undocumented issues.

Upper Management Support


Upper Management Responsibilities
Upper management has several key responsibilities that are connected
to project success. They include:

• clearly defining project scope


• resolving major issues in a timely manner
• allocating resources
• instilling a positive attitude throughout the organization
• establishing project priority
• managing the organizational changes associated with the project
• making sure that project management has critical information
about major planned or potential events that could impact the
project

1 - 16 Introduction to AIM AIM Method Handbook


Time/Budget/Quality Considerations
The project budget and schedule must be based on realistic estimates
with appropriate contingencies. If real time and budget constraints
exist, Project Management must work closely with upper management
to ensure an appropriate balance is reached. Frequently, time and
budget constraints are imposed before the project scope has been
determined and a detailed project plan has been developed.

Strong Project Management


A strong project manager identifies problems, determines solutions, and
drives the solution process. An inexperienced or ineffective manager
may be unable to identify problem areas that could escalate and
negatively impact the project. If high risk project approaches (such as
Fast Track implementations) are selected, strong project management is
essential to complete the project successfully

The organization’s willingness or ability to delegate responsibility and


control to the project manager should also impact your selection
approach. If complete responsibility and control is held by the project
manager, communication with upper management can occur through
exception reporting and issues management. Frequently, incomplete
delegation of authority results in responsibility without control. In
these cases, the project manager may not be able to perform effectively
because he does not have the right level of decision making authority.
Fast Track approaches are unusually dependent on full
project/program management authority since decisions must be made
quickly.

Team Strength
Capitalizing on individual and team strengths while compensating for
weaknesses are critical factors affecting the project’s success. Potential
team factors include:

• a strong team with a weak project manager may succeed, but the
risk is high; a weak team with strong project management can
become a strong, effective project team
• a group of strong individuals does not guarantee a strong team;
teamwork is essential

Oracle Method Introduction to AIM 1 - 17


Organizational Readiness
Application implementations cause change and change management
can mean the difference between project success or failure. Project
managers should be tuned to organizational factors impacted by the
project, for example:

• Do various levels in the organization view the project as a


desirable solution to current problems?
• Is the Information Systems department able to absorb new
technology and support the project?
• What is the level of computer literacy? How many people will be
using an automated system for the first time?
• How stable is the organization? Change may be difficult for the
user community if it is also being driven by other initiatives.
• Are all levels of management ready? Authorizing a system
implementation is different than managing the associated
organizational changes.
• Did the user community participate in the system selection?
Greater involvement can mean less resistance to subsequent
changes.
• If the applications will be deployed at various sites, are business
functions performed differently at each location?
• What is the organization’s strategy regarding centralized versus
decentralized planning and control?
• What is the history of system implementation and has it created a
positive mindset regarding future projects?

Selecting an AIM Implementation Approach

AIM defines two implementation approaches:

AIM Classic
AIM processes are conducted with resources and timeframes optimized
for low risk and quality.

1 - 18 Introduction to AIM AIM Method Handbook


AIM Fast Track
AIM processes are conducted with resources and timeframes optimized
to achieve the earliest possible go-live date. However, by accelerating
implementation you assume a greater risk that some requirements may
be missed or you will not achieve the quality of a classic
implementation.

Before you decide to use Fast Track, analyze the associated risks and
weigh the cost and benefits of an early implementation against potential
problems after production.

Ensure that you do not eliminate tasks and deliverables that will have a
serious downstream impact on the project. Every task in AIM is related
to another. If you remove a task, its deliverable will not be available for
related subsequent tasks. Verify that the information contained in the
deliverable will not be required for your project.

Table 1-2 summarizes some of the criteria you should consider in


selecting a Classic or Fast Track implementation categorized by AIM
process.

AIM Processes Classic Implementation Fast Track Implementation

Business Requirements Business requirements not well Business processes documented and
Definition understood. requirements clearly defined and
well understood.

Business process changes are No significant changes to business


anticipated. process that could impact the project.

Business Requirements Moderate to substantial changes Minimal application customizations.


Mapping to the application software may Gaps between requirements and the
be performed. standard application software will be
resolved by changing business
policies and procedures.

Application and Major shifts in computing Little change in technology; solid IS


Technical Architecture paradigm, tools, and skill set.
architecture.

Oracle Method Introduction to AIM 1 - 19


AIM Processes Classic Implementation Fast Track Implementation

Organization has little Sound expertise regarding planned


knowledge or experience in new architecture.
architecture.

Module Design and Significant application software Few or no customizations.


Build changes.

Data Conversion Large conversion volumes and Straightforward data conversion.


moderate to complex
conversion processes and tools.

Documentation Significant custom Few or no changes to standard


documentation required. documentation.

Business System Substantial business system Small scope to the business system
Testing testing required for testing - few customizations, custom
customization, data conversion, interfaces, and data conversions.
interfaces.

Many complex business Few complex business processes.


processes.

Substantial business process Few business process changes.


changes.

Performance Testing Some performance testing Sufficient hardware and network


required. capacity clearly exists. No
performance test required.

Training Requires custom developed Standard training materials and


materials and classes. classes.

Production Migration Complex migration to Simple cutover to production.


production.

Table 1-2 Classic Versus Fast Track Implementation

1 - 20 Introduction to AIM AIM Method Handbook


Multiple Deployment Phase Considerations

Determine if the transition into production needs to occur for all


organizations at the same time. If a phased implementation is planned,
decide what applications will be implemented in each phase. This
combination of choices presents four scenarios:

• Deploy all applications for all organizations at the same time.


• Deploy all applications for different organizations at different
times.
• Deploy subsets of the applications for all organizations at the
same time.
• Deploy subsets of the applications for different organizations at
different times.

Consider the following factors when deciding on a single-phase or


multiple-phase deployment:

• Is the organization facing changes from other sectors? Allow


time for an organization to absorb major changes before
introducing new factors.
• Is the organizational culture amenable to integrating the new
system into its operations? The risk will be less if the
organization is accustomed to using a common system with
related policies and procedures. If business units have been
operating independently the organization must adapt to a
cultural change as well as the new system.
• Can the project team adequately execute the project so that there
is minimal risk in implementing all applications for all
organizations at one time?
• What is the company’s experience with previous system
implementations?
• What is the project team’s experience with previous system
implementations?
• Is the application a production, controlled, or beta release of the
software?

To minimize risk, use the pilot implementation approach. Go live with


a carefully selected subset of users who are well trained and able to deal
with initial problems.

Oracle Method Introduction to AIM 1 - 21


Develop an interface between the applications and the existing system
so that transactions are posted to both systems. This allows the
remainder of the organization to use the current system in parallel with
the pilot implementation. For example, journal entries could post to the
new General Ledger and to the existing General Ledger. This allows
consolidated reporting from the current system until all regions are cut
over.

Along with risk reduction, phased deployment adds complexity and


cost to the project:

• The project duration is lengthened requiring the project team to


remain intact for a longer period of time.
• The phase overlaps can create peak resource loading problems.
You may be starting a new deployment at the end of a previous
one. Production migration needs, startup demands, and support
requirements are occurring in parallel.
• Peaks in computer resource utilization may occur during phase
overlaps due to multiple application database instances being
needed for training, data conversion, and production for the
deployment just ending, and start up tasks for the next
deployment.

Level of Process/Requirements Analysis

The scope of process analysis and requirements definition activity can


vary greatly. For example, the objective may be to minimize
customizations by matching the business processes to the applications.
Or the objective may be to change the applications to match the business
processes because of an overall strategy of minimizing changes to
business procedures.

If the organization intends to replace many business practices, there


may be little need for the team to assess or understand how business is
currently done. On the other hand, if the strategy is to integrate the
applications into current processes, it is critical that the team
understand how the business is currently operating.

At a minimum, each current business process must be identified to


ensure everything is addressed by the project. Substantial time and
expense can be saved by minimizing current process analysis but there
is a tradeoff between cost, time, and risk.

1 - 22 Introduction to AIM AIM Method Handbook


Acceleration Techniques

In certain situations you may be able to condense the project duration


by using acceleration techniques. This is how you can tailor the AIM
Workplan and use a Fast Track implementation approach.

Project Management (PJM) imposes phase start and completion


checkpoints that are valuable for project management and control but
may disrupt natural process/task overlap opportunities and project
flow.

In large, complex implementations, the formal phase signoffs are


needed for scope and risk management. The Classic implementation
approach is the best way to control a project and mitigate risk.

In smaller, less complex projects or for Fast Track implementations,


there may be opportunities to expedite project activities with an
acceptable degree of risk by collapsing tasks within a phase.
Collectively, they will deliver results close to a Fast Track approach.

Examples of acceleration opportunities categorized by AIM processes


follow:

Definition
Definition should always be a standalone phase. Have a milestone and
phase-end checkpoint after Definition and use it to reassess the future
project approach.

Operations Analysis and Solution Design


Collapse Operations Analysis and Solution Design into a single phase.
Start creating design deliverables as the mapping progresses. This is a
popular approach, but incurs greater risk because the Operations
Analysis checkpoint is removed. The full vision of the future system
does not emerge until Solution Design is nearing completion. This
technique increases the risk of major design issues associated with non-
integrated analysis and costly rework, as well as scope creep.

Solution Design and Build


Frequently Build begins while Solution Design is in process. This
technique offers economies in projects with numerous customizations,
but there is a risk of non-integrated designs and scope creep.

Oracle Method Introduction to AIM 1 - 23


Operations Analysis, Solution Design and Build
Collapse the first three phases into a single super-phase. This is only
suitable for small scale projects that are easy to control and that use
alternative risk mitigation steps.

Other considerations:

• If there is uncertainty regarding any aspect of the project, use the


classic approach to assure good checkpoint and risk management.
• By using multiple parallel business process definition/mapping,
teams can speed up Definition and Operations Analysis. Mitigate
risk for this technique by assigning a specific process/solution
team to ensure cross-process integration. Use a project data
repository such as Designer/2000 for custom developed
solutions. The repository automatically cross-validates designs
and enforces integrated solutions.
• If there are minimal large, complex customizations, begin work
on them early because of the timeframes required for designing,
building, and testing major customizations. It may be possible to
selectively overlap specific customizations. To further mitigate
risk, define a formal subproject specifically for a given
customization.

Process Teams for Requirements Definition and Mapping


Process teams formed within a business function to define requirements
should continue into requirements mapping.

Business requirements scenarios created during Definition will be


mapped to the applications during Operations Analysis. The process
teams create scenarios that represent how the process driven business
requirements can be satisfied using the standard application features.
The goal is to arrive at a solution that satisfies the business needs of the
users, resolves current system problems, and optimizes process
efficiency. These solutions can be a combination of several components:
application supported process steps, manual processes or process steps,
application setups, system features, reports, and background processes.

These prototype solutions are interactively developed by project team


members, key users, and application consultants. The application
consultants enable features, set system parameters, and guide process
mapping to illustrate how the new system supports proposed scenarios.
This process continues until a solution is arrived at or an application-
process gap is identified.

1 - 24 Introduction to AIM AIM Method Handbook


This prototyping method expedites the requirements mapping process
by capitalizing on the early knowledge transfer in both directions, from
process teams to application consultant, and from application
consultant to process teams. Internal resources can save time by relying
more heavily on the consultant’s participation and interpretation of
requirements. Less reliance is placed on users’ grasp of new system
functionality and experimentation to arrive at optimal solutions.
Therefore, the project team and users can concentrate on business
process design and leave the mechanics of application set up to the
consultants.

A repetitive implementation process task cycle for business processes are


performed multiple times for different subject areas. For example,
Current Business Baseline, Future Process Model, Business
Requirements Scenarios, and Business Requirements Mapping Form
will occur for each business process. An example is shown in the
following diagram:

Current
Business
Baseline
(Payment
Current Processes)
Business
Baseline Define Future
(Receiving Process and
Current Processes) Function Model
Business (Payment
Baseline Define Future Processes)
(Procurement Process and
Processes) Function Model Define Business
g
e linin (Receiving Requirements
Bas Define Future Processes) Scenarios
Process and (Payment
Function Model Define Business Processes)
(Procurement Requirements
Processes) Scenarios Map Business
(Receiving Requirements
Define Business Processes)
ng (Payment
eli Requirements
Mod Scenarios Processes)
Map Business
(Procurement Requirements
Processes) (Receiving Test Business
ss
u sine Processes) Solutions
gB Map Business (Payment
inin
Def a r io s Requirements Processes)
c e n (Procurement Test Business
S
Processes) Solutions
(Receiving
Processes)
m ents Test Business
uire
Req ing Solutions
p
Map (Procurement
Processes)

ting
Tes e s s
in
B u s tions
S lu
o

Figure 1-4 Repetitive Implementation Process Task Cycle Example

Oracle Method Introduction to AIM 1 - 25


Acceleration Techniques for Module Design and Build
Multiple Tasks for Program Modules
The default Project Workplan for AIM includes a single task for Create
Custom Modules. In reality, this task must be repeated for all the
customizations, conversions, and interfaces required by the project.
When preparing a detailed project plan, add tasks for each individual
program module that must be built and tested. This gives you the
flexibility to assign several programmers to the construction tasks and
perform resource leveling to derive the detailed schedule. There may
also be opportunities for parallel development that can be identified
using this technique.

Prioritization for Customizations


Some customizations identified during Solution Design may not be
critical for initial production cutover. By delaying these Build activities
you can move to Business System Testing and Production Migration
more quickly. Development of these less important programs can
continue in parallel with other activities, but are introduced after
production.

Schedule Optimization
Work closely with the designers so that you can define the inter-module
dependencies in the project plan. You may also wish to assign priorities
so that the auto-leveling feature of your project planning tool can
generate an appropriate schedule. We recommend that you use
resource-driven scheduling for program construction tasks so that
multiple resources can be most efficiently utilized. Fixed-duration
scheduling can be used for Business System Testing since additional
resources may be brought in during this process.

Parallel Design and Development


Since the primary predecessor for program construction is the detailed
design document, the project plan may include Build activities in
parallel with Solution Design activities. If development is accelerated in
this way, some of the assumptions incorporated into earlier designs
could change when later designs are developed, which may require that
the earlier designs are revisited and the related programs updated or
rewritten. This approach could also shorten the lead-time of Module
Design and Build.

1 - 26 Introduction to AIM AIM Method Handbook


Project Tracking
Careful attention to progress reporting, signoffs, and scope control are
particularly important while managing Solution Design. Include
frequent checkpoints and milestones so that you always know the status
of the project.

Oracle Method Introduction to AIM 1 - 27


Estimating AIM Projects
The preliminary application implementation project estimate is based
on:

• What is the business objective?


• What is the vision regarding the solution?
• How do Oracle Applications contribute to the vision?
• What is the scope of the project and how does it relate to the
overall vision?
• Who will participate in the project (employees, consultants,
vendors)?
• What are the constraints affecting the project (timing or budget
limitations, organization changes)?
• Which applications will be implemented?
• What sites will be involved?
• Will a phased deployment approach be employed? If so, in what
sequence will the applications be implemented?
• When will work commence?
• What experience does the organization have regarding the
technology that will be used?

Before creating a detailed work plan, develop the project scope,


suggested approach, and preliminary budget. Use an iterative process
where different project scenarios are defined at a summary level and
then estimated.

Generally accepted industry practices include using experience and


results from similar projects to develop estimates for the different
scenarios.

The final budget should be developed using a detailed bottom up


estimating process based on the detailed work plan. This project plan
should include:

• Work Breakdown Structure (WBS)


• Resource Assignments

1 - 28 Introduction to AIM AIM Method Handbook


• Dependencies
• Deliverables
• Dependency Relationships

Appropriate contingencies should be included in the estimate. Use the


plan to baseline the project and then review and update it on a day-to-
day basis.

AIM includes project planning tools which provide a starting point for
developing the detailed work breakdown structure and contain all the
AIM tasks with associated dependencies, project roles, and deliverable
names.

Table 1-3 summarizes Oracle’s experience in medium size projects. It


presents a “Process as a Percentage of Project Effort” view that is the
result of using the detailed bottom up model. Each cell represents the
process’ percentage of project effort in that phase. The table sums down
for phase totals and across for process totals. For example, Solution
Design is the most work intensive phase of the project and requires 30
percent of the project work effort.

Operations

Production
Transition
Definition

Analysis

Solution
Design

Build

Total
Process (as % of Project Effort)
RD - Business Requirements Definition 4% 2% 6%
BR - Business Requirements Mapping 6% 1% 7%
TA - Application & Technical Architecture 1% 1% 2% 4%
MD - Module Design & Build 0% 0% 6% 5% 12%
CV - Data Conversion 0% 0% 6% 4% 2% 13%
DO - Documentation 1% 0% 4% 2% 7%
TE - Business System Testing 3% 9% 1% 13%
PT - Performance Testing 0% 0% 1% 5% 7%
TR - Training 1% 3% 2% 5% 11%
PM - Production Migration 0% 1% 1% 4% 6%
PJM - Project Management 3% 2% 4% 4% 1% 1% 15%
TOTAL 10% 15% 30% 29% 11% 5% 100%

Table 1-3 Process as a Percentage of Project View

Warning: Use caution in using these estimated percentages


“as is”; you must take into account the specifics of your
implementation.

The following table summarizes Oracle’s experience in medium-size


projects as a “Process Effort as a Percentage of Phase.” Each cell in the

Oracle Method Introduction to AIM 1 - 29


table represents the percentage of phase effort incurred by a process in
each project phase. Phase columns must then total 100 percent, and
process rows sum to process totals.

Operations

Production

% of Total
Transition
Definition

Analysis

Solution
Design

Build
Process (% of Phase Effort)
RD - Business Requirements Definition 36% 17% 6%
BR - Business Requirements Mapping 41% 5% 7%
TA - Application & Technical Architecture 15% 4% 5% 4%
MD - Module Design & Build 1% 2% 21% 17% 12%
CV - Data Conver sion 3% 1% 20% 14% 17% 13%
DO - Documentation 7% 3% 14% 6% 7%
TE - Business System Testing 9% 32% 13% 13%
PT - Per formance Testing 2% 1% 4% 17% 7%
TR - Training 11% 18% 6% 47% 11%
PM - Production Migration 1% 2% 10% 78% 6%
PJM - Project Management 25% 13% 13% 13% 13% 22% 15%
TOTAL Phase 100% 100% 100% 100% 100% 100% 100%

Table 1-4 Process Effort as a Percentage of Phase View

The phase chapters in this manual provide additional estimating tables


that detail the percentage of task distributions by process for the project
roles in that phase.

1 - 30 Introduction to AIM AIM Method Handbook


Managing an AIM Project
Oracle’s Project Management Method (PJM) provides a framework in
which all types of projects can be planned, estimated, controlled, and
tracked in a consistent manner. This consistency is required in today’s
business environment where projects often implement packages,
develop custom solutions, and create a data warehouse in order to
satisfy a business need.

There are two dimensions to PJM. The first addresses What work needs
to be done to manage and support a project. The second is When those
management and support tasks should be performed in the project life-
cycle.

PJM tasks are organized into five processes that help project
management understand What tasks need to be performed for a
successful project. The PJM processes are as follows:

• Control and Reporting determines the scope and approach of the


project, manages change, and controls risks. It contains guides
for reporting progress status externally and for controlling the
Quality Plan.
• Work Management defines, monitors, and directs the work
performed on the project. It also maintains the financial view of
the project for Oracle management.
• Resource Management determines the right level of staffing and
skills for the project, and the working environment to support
them.
• Quality Management implements quality measures to ensure
that the project meets the organization’s purpose and
expectations throughout the project life-cycle.
• Configuration Management stores, organizes, tracks, and
controls all items produced from and delivered to the project. It
also provides a single location from which all project deliverables
are published.

The tasks within each PJM process are assigned to a PJM life-cycle
activity. Each activity is integrated into a project plan that shows when
the project management and support tasks should be performed. The
PJM life-cycle activities are as follows:

Oracle Method Introduction to AIM 1 - 31


• Project Planning defines the project scope, quality, timeline, and
cost. It also determines the appropriate organization of resources
and assigns responsibilities for project tasks.
• Phase Planning tasks update project plans and procedures for
the phase.
• Phase Control tasks execute concurrently with the phase
execution. They perform project monitoring, directing, and
reporting functions.
• Phase Completion tasks conclude and secure sign-off of a phase.
• Project Completion results in the satisfactory conclusion of the
project and settlement of all outstanding issues prior to shutting
down the project.

Figure 1-5 illustrates the relationship between the process and life-cycle
activities in PJM:

Project Project
Phase Management
Planning Completion

Planning Control Completion

Control and Reporting

Work Management

Resource Management

Quality Management

Configuration Management

Figure 1-5 Project Management Life-cycle

Figure 1-6 shows PJM and its relationship with AIM. PJM life-cycle
activities are integrated into the project plan at the appropriate project
and phase levels. Project planning and completion activities are
performed once at the beginning and end of a project, while phase
planning, control, and completion are performed once for each phase of
the project. PJM dependencies do not appear on the critical path.

1 - 32 Introduction to AIM AIM Method Handbook


Initial Intermediate Final
Phase Phases Phase
Project Planning

Phase Planning

Phase Control Control Control Control

Execution Execution Execution

Phase Completion

Project Completion

Figure 1-6 Managing an AIM Project

For more information on PJM, refer to the Oracle Method Project


Management suite of reference books:

• PJM Method Handbook


• PJM Process and Task Reference
• PJM Deliverable Reference

Tailoring the Method

AIM is designed to be flexible. It has standard tasks and activities that


can be tailored to specific user needs. For example, you can combine
tasks from a business process re-engineering project with your
application implementation project.

Keeping it Simple
The standard workplan in AIM is designed to track progress and issues.
It can easily accommodate the integration of subprojects you address
within the following risk areas:

• Plan resources.
• Track budget to actuals.
• Adhere to project scope and terms.

Oracle Method Introduction to AIM 1 - 33


• Follow an efficient and complete design, build, and transition
route.
• Provide for a quality control mechanisms for key deliverables.
• Communicate progress and future tasks.
• Manage the system environment.

The implementation process you design with your user influences the
tasks and dependencies in your workplan. If a hybrid method will be
used, ensure that the dependencies are preserved.

Adding and Removing Tasks


Some tasks are optional depending on the project. For example, if a
user does not require software modifications, the related design, build,
and test tasks are not necessary. However, a project may also need
tasks added. If a business process re-engineering effort is conducted
instead of doing a current process baseline, new tasks must be defined
and entered.

Customizing Templates and Deliverables


You can use the standard features in AIM to perform some
customizations to templates. For example, you can add a company logo
or make Microsoft Word style changes that suit your user’s preferences.
You can also make global variable changes to documents that will
rename key processes using company terminology.

Working on Multi-site/Multi-phase Projects

The AIM project plan includes all the necessary tasks to implement
Oracle Applications, although some tasks may be optional depending
on the project. Large or multi-site projects may require that repeated
tasks, such as administration and standards creation, be moved to a
central repository and shared between projects. When a task is elevated
to the enterprise level, the same task in AIM takes on a different form.
These AIM tasks are transformed into reviews of the enterprise
deliverables. However, the AIM tasks can also modify the enterprise
deliverable to incorporate the local requirements.

1 - 34 Introduction to AIM AIM Method Handbook


Using AIM with a User Method

Sometimes a project team member or user wishes to use their own


project method. When this occurs, do a detailed fit and gap analysis
between the methods. For any identified gaps, incorporate the
appropriate AIM tasks and dependencies into the user’s method. Make
sure that the associated deliverables will be produced and develop a
gap strategy for all remaining open issues.

Oracle Method Introduction to AIM 1 - 35


CHAPTER

2 Definition

T his chapter describes the Definition phase of AIM. The goal of


Definition is to determine the business and information system’s
high-level requirements necessary to meet a set of defined business
objectives.

Definition Operations Solution Build Transition Production


Analysis Design

Business Requirements Definition

Business Requirements Mapping

Application and Technical Architecture

Module Design and Build

Data Conversion

Documentation

Business System Testing

Performance Testing

Training

Production Migration

Figure 2-1 Context of AIM Definition Phase

Oracle Method Definition 2 - 1


Overview
This section provides an overview of Definition.

Objectives

The objectives of Definition follow:

• Obtain a clear understanding of the business processes, functions,


and information required to meet the project’s defined business
objectives.
• Develop a high-level conceptual architecture.
• Determine the high-level architectural, technological, and
configuration requirements to support the functional and
information needs of the application.
• Defines the project scope clearly.
• Obtain management approval to proceed with Operations
Analysis.
• Optional: Examine the existing business processes and
information systems affected by the project’s defined business
objectives.

Critical Success Factors

The critical success factors for Definition follow:

• clear definition of the business objectives to be addressed


• active participation by key management and knowledgeable user
and technical representatives from the areas of the business
affected by the project’s objectives
• access to information related to the existing business processes
and systems affected by the project
• detailed, thorough, and documented process modeling sessions
• effective project management of scope and issues
• sufficient time and resources

2 - 2 Definition AIM Method Handbook


Overview Table

This table illustrates the prerequisites, processes, and key deliverables


for Definition.

Process Prerequisites Key Deliverables

Business Requirements Business Process Reengineering Business Volume Requirements


Definition Studies

Existing Reference Material Current Business Baseline

Future Business Strategy Financial and Operations Structure

High-Level Existing System Data Future Business Function Model


Model

Original Justification for Business Future Process Model


Systems Investment

Sales and Presales Material Process and Mapping Summary

Application and Technical Architecture Designs and Technical Architecture Scope, Objectives and
Architecture Documents from Sales Cycle Approach

Existing System Architecture or Architecture Requirements


Technical Configuration
Documents

Existing System Management Architecture Strategy


Procedures Documents

Existing Systems Architecture Conceptual Architecture


Strategy or Policy Documents

Technical Architecture Baseline

Module Design and Build Customization Strategy

Oracle Method Definition 2 - 3


Process Prerequisites Key Deliverables

Data Conversion Legacy System Documentation Conversion Scope, Objectives and


Approach

Conversion Strategy

Documentation Business Documentation Standards Glossary Documentation


and Guidelines Requirements

Documentation Standards and


Procedures

Performance Testing Application User Manuals Performance Test Scope, Objectives


and Approach

Performance Testing Strategy

Training Training Material Standards and Education and Training Plan


Guidelines

Current Training Resources Trained Project Team

Table 2-1 Definition Phase Overview Table

Prerequisites

Prerequisites for Definition follow. You should use these prerequisites,


if they exist, prior to beginning the project. Otherwise, you may need to
create them during Definition.

Prerequisite Source

Application Manuals Client

Architecture Designs and Technical Client


Documents from Sales Cycle

Business Documentation Standards Client

Business Process Reengineering Client


Studies

2 - 4 Definition AIM Method Handbook


Prerequisite Source

Existing Reference Material Client

Existing Systems Architecture Client


Strategy or Policy Documents

Existing System Architecture or Client


Technical Configuration Documents

Existing System Management Client


Procedures Documents

Future Business Strategy Client

High-level Existing System Data Client


Model

Legacy System Documentation and Client


Guidelines

Original Justification for Business Client


Systems Investment

Performance Testing Standards and Client


Guidelines

Sales and Presales Material Client

Table 2-2 Definition Phase Prerequisites

Oracle Method Definition 2 - 5


Processes

The processes used in this phase follow:

Business Requirements Definition


Complete baseline understanding of current events and business
processes. Develop process and function models of future business
operations. Gather volumes of business transactions and storage
requirements. Establish repository of key process and mapping
information, as well as decisions.

Application and Technical Architecture


Identify the scope, objectives, and strategy you will use for the
architecture process. Collect the high-level business requirements and
policies affecting architecture. Create a conceptual integrated model
application and technical architecture.

Module Design and Build


Define a strategy for extending and customizing the applications and
developing custom interface software.

Data Conversion
Define the Conversion Scope, Objectives, and Approach, and prepare
the Conversion Strategy.

Documentation
Define a glossary of terms for the project. Specify the documentation
requirements and determine the documentation standards and
procedures.

Performance Testing
Identify the scope, objectives, and strategy you will use for the
performance testing process, including measurements to make, testing
methods, and testing tools.

2 - 6 Definition AIM Method Handbook


Training
Plan education and training for the project team. Deliver skills and
applications education to prepare team members for process modeling
and requirements definition.

Key Deliverables

The key deliverables of this phase follow:

Deliverable Description

Architecture Requirements Documents the high-level


requirements for the architecture of
the new systems. The requirements
are classified by whether or not they
constitute policies for the new
business systems.

Architecture Scope, Documents the scope of the


Objectives, and Approach architecture process, the objectives of
the design, and the approach that
you will use. This is created if a
more precise definition of scope,
objectives, and approach is needed
for an architecture subproject.

Architecture Strategy Documents the strategy that you will


use for the architecture process. It
includes a discussion of the methods,
tools, and techniques that you will
employ to perform the work outlined
in the scope document.

Business Volume Inventory of key transaction and data


Requirements volumes by business functional area.

Oracle Method Definition 2 - 7


Deliverable Description

Conceptual Architecture Documents the conceptual


architecture for the new systems. It
is a high-level view of the new
application and technical architecture
and is intended as a working model
for the architecture work and for the
broader project team. It is also the
primary vehicle for communication
of the future information system’s
architecture to management.

Conversion Scope, The conversion requirements and


Objectives, and Approach related scope, objectives, and
approach.

Conversion Strategy The conversion strategy for


implementing the defined conversion
requirements.

Current Business Baseline An analysis of the current business


processes and functions.

Customization Strategy A strategy document that describes


how the project will respond to
customization requests.

Documentation The business needs that must be met


Requirements by project documentation.

Documentation Standards The standards and procedures to be


and Procedures applied to project documentation.

Education and Training Plan Contains the training schedule for


courses. Determines the resources
needed for preparing training and
holding the session. Also assesses
general education course needs.

Financial and Operating A depiction of the financial structure


Structure and the operating organizations of
the company.

2 - 8 Definition AIM Method Handbook


Deliverable Description

Future Business Function Catalogs the elementary functions to


Model be supported within future business
processes.

Future Process Models Contains Process Flow Diagrams of


the events and business processes
that will be supported by the
applications and functions of the
business area.

Glossary Documents the definitions of key


terms used throughout the project.

Performance Testing Scope, Documents the scope of the


Objectives, and Approach performance testing process, the
objectives of the testing, and the
approach that you will use.

Performance Testing Documents the strategy that you will


Strategy use for the performance testing
process. It includes a discussion of
the methods, tools, and techniques
that you will employ to perform the
work outlined in the scope
document.

Process and Mapping A summary of key processes,


Summary business requirements, and mapping
decisions.

Technical Architecture Documents technical information


Baseline about the existing legacy systems,
including the applications, hardware,
networks, and interfaces.

Trained Project Team Project Team members qualified to


transfer knowledge to the
constituents they represent.

Table 2-3 Definition Phase Key Deliverables

Oracle Method Definition 2 - 9


Approach
This section describes the approach for Definition.

Tasks and Deliverables

This table lists the tasks executed and the deliverables produced during
Definition.

ID Task Deliverable

Business Requirements Definition


RD.010 Identify Financial and Operating Structure Financial and Operating Structure
RD.020 Conduct Current Business Baseline Current Business Baseline
RD.030 Develop Future Process Model Future Process Model
RD.040 Develop Future Business Function Model Future Business Function Model
RD.050 Establish Process and Mapping Summary Process and Mapping Summary
RD.060 Gather Business Volumes Business Volume Requirements
Application and Technical Architecture
TA.010 Define Architecture Scope, Objectives, and Architecture Scope, Objectives, and
Approach Approach
TA.020 Prepare Architecture Strategy Architecture Strategy
TA.030 Establish Architectural Requirements Architecture Requirements
TA.040 Develop Conceptual Architecture Conceptual Architecture
TA.050 Conduct Technical Architecture Baseline Technical Architecture Baseline
Module Design and Build
MD.010 Prepare Customization Strategy Customization Strategy
Data Conversion
CV.010 Define Conversion Scope, Objectives, and Conversion Scope, Objectives, and
Approach Approach
CV.020 Prepare Conversion Strategy Conversion Strategy
Documentation
DO.010 Prepare Glossary Glossary
DO.020 Specify Documentation Requirements Documentation Requirements
DO.030 Determine Documentation Standards and Documentation Standards and
Procedures Procedures

2 - 10 Definition AIM Method Handbook


ID Task Deliverable

Performance Testing
PT.010 Define Performance Testing Scope, Objectives, Performance Testing Scope,
and Approach Objectives, and Approach
PT.020 Prepare Performance Testing Strategy Performance Testing Strategy
Training
TR.010 Prepare Training Strategy Education and Training Plan
TR.030 Conduct General Education Classes Trained Project Team
TR.040 Conduct High-level Overview of Application Trained Project Team
Features
Table 2-4 Definition Phase Tasks and Deliverables

Oracle Method Definition 2 - 11


Task Dependencies

This diagram shows the dependencies between tasks in Definition.

Definition

RD.020 RD030
Conduct Current Develop Future
Business Baseline Process Model
RD.020 RD.030

BUSINESS
REQUIREMENTS
RD.010
DEFINITION Identify Financial
and Operating
Structure
RD.010

TA.010 TA.020 TA.030


Define
Prepare Establish
Architecture
APPLICATION AND Architecture Architecture
Scope, Objectives,
TECHNICAL Strategy Requirements
and Approach
TA.020 TA.030 TA.050
ARCHITECTURE TA.010
Conduct Technical
Architecture
Baseline
TA.050

M ODULE DESIGN
AND BUILD

D ATA
CONVERSION

DOCUMENTATION

TR.030
Conduct General
Education Classes
TR.010 TR.030 TR.040
T RAINING Conduct High-level
Prepare Training Overview of
Strategy Application
TR.010 Features
TR.040

PT.010 PT.020
P ERFORMANCE Performance Prepare
Testing Scope,
TESTING Performance
Objectives, and Testing Strategy
Approach
PT.020
PT.010

Figure 2-2 Definition Phase Task Dependencies

2 - 12 Definition AIM Method Handbook


Definition

RD040 RD.080
Develop Future Gather Business
Business Function
Volumes
Model RD.060
RD.040

BUSINESS
R EQUIREMENTS
RD.050
Establish Process D EFINITION
and Mapping
Summary
RD.050

TA.040
Develop
Conceptual APPLICATION AND
Architecture T ECHNICAL
TA.040
ARCHITECTURE

MD.010
Prepare
Customization
M ODULE DESIGN
Strategy AND BUILD
MD.010

CV.010 CV.020
Define Conversion Prepare DATA
Scope, Objectives, Conversion
and Approach Strategy CONVERSION
CV.010 CV.020

DO.010 DO.030 DO.020


Determine
Documentation Specify
Prepare Glossary Documentation DOCUMENTATION
Standards and
DO.010 Procedures Requirements
DO.020
DO.030

TRAINING

P ERFORMANCE
TESTING

Figure 2-2 Definition Phase Task Dependencies (cont.)

Oracle Method Definition 2 - 13


Managing Risks

The areas of risk and mitigation for Definition include the following:

Risk Mitigation

Management, users, or Have clearly stated objectives from


project team not committed executive management and regular
to the magnitude of change. reporting to executive steering
committee.

The tendency to preserve old Select key area team leaders who
processes and not develop support the need for change, can
new ones. facilitate change in their areas, and
are knowledgeable about their areas
and processes.

Knowledgeable users not Assign a project sponsor role to a


involved in current and leader from the user community who
future process definition. can promote a high level of
commitment from key users and will
nurture support for project team
members as they work outside their
normal jobs and duties.

Project team not adequately Conduct process modeling sessions


trained in process modeling for team members; have them
techniques. demonstrate required skills with a
qualified instructor.

Missed or incomplete Have functional executive


processes and unidentified management review the integrated
events. process model and event catalog for
completeness.

Process model does not Have representatives from each


tightly couple all integrated process team review the process
processes. models from other teams.

Insufficient data gathered on Have both functional and


volumes and processing information processing management
windows. review and agree upon volume and
processing windows.

2 - 14 Definition AIM Method Handbook


Risk Mitigation

Incomplete definition of Create a project organization that


scope for the architecture enables input and consideration of
work. business, functional, and technical
requirements in architecture.

Treatment of the architecture Consider business requirements and


as a purely technical pursuit functional mapping as well as
and inadequate consideration technical requirements as drivers for
of business requirements as the optimal configuration and
drivers for architecture deployment of the applications being
(bottom-up approach). implemented.

Lack of project team Screen project team candidates for


expertise in application prerequisite skills and experience.
deployment strategies or
advanced technical
architecture.

Lack of involvement or sign- Communicate conceptual


off by senior management of architectures to senior management
key architecture strategies, and organize a review, if appropriate.
plans, and issue resolutions.

Inadequate or non-existent Appoint a quality manager who has


quality assurance in the responsibilities for quality assurance
implementation project. and enforcing review and approval
procedures.

Imprecise definition of scope Ensure that the scope and objectives


and objectives for for performance testing are made
performance testing, leading clear by senior management, and that
to false conclusions . they understand what performance
testing can or cannot achieve or
predict.

Lack of a structured method Use a structured method for


for performance testing, performance testing to ensure that
leading to measurements that the test results can be interpreted in
are difficult to interpret the context of their meaning for the
relative to the target real production system.
production system.

Oracle Method Definition 2 - 15


Risk Mitigation

Lack of appreciation of the Have a member of the performance


dependency of performance testing team review the work and
testing on good quality deliverables relating to application
applications setup data and setup and conversion.
data conversion programs.

Lack of project resources to Plan ahead so that the required


provide a controlled, resources are available for this
segregated performance test activity.
environment.

Conversion requirements, Discuss conversion requirements


scope, and objectives not with the client early in the project
clearly defined. life-cycle. Encourage the client to
make decisions that impact the
conversion scope during Definition.

Conversion strategy not Make decisions about the conversion


clearly documented and strategy (such as using automated
understood. conversion tools during Definition)
and communicate this strategy to the
client.

Documentation standards Require documentation standards


and procedures poorly and procedures input and approval
defined or incomplete. from key client areas involved in
using the final documentation.

Training requirements not Create a detailed set of training


fully developed. requirements listing expected roles
that are within the project scope.

Table 2-5 Risk Management Table for Definition

Tips and Techniques

This section provides tips and techniques for managing Definition. In


addition, advice and comments on each process are included.

2 - 16 Definition AIM Method Handbook


Business Requirements Definition
Business Requirements Definition begins in Definition with the task of
constructing the current business baseline in order to understand the
events to which existing business processes currently respond. This
examination of current requirements expands to create a vision of how
future processes and requirement scenarios will respond to those
events, as well as any additional ones anticipated by the company’s
future business strategy. Model the future processes with both process
models and function models to ensure sufficient breadth and depth of
process definition.

The operating and financial structure of the business entity affects


application and technical architecture definition as well as set up.
Gather and formalize business volumes and use them to determine
storage and performance requirements.

Application and Technical Architecture


Architecture work performed during Definition complements the
business requirements definition and helps to provide the technical
framework for subsequent phases of the project. Substantive work on
architecture needs to occur relatively early in an implementation project
because it underpins the technical environment of all other project
activities. At the completion of this phase, the architecture team should
have defined the critical architecture requirements and policies and
should have as much information as needed about the existing technical
architecture. They should also have identified a preferred conceptual
architecture that incorporates the new systems being implemented.

The architecture team defines the scope of the project architecture work
in this process. Issues and scope vary from project to project, so it is
important to set detailed parameters for the work early in the project.
An important part of the scope is to establish to what extent the project
is defining the architecture and information systems strategy for the
evolving business. If the project is replacing a subset of the existing
systems, the architecture of the newly implemented systems will need
to be consistent with the existing systems architecture and the
information systems strategy for the business. If, however, the project is
replacing most or all of the major existing systems in the business, the
architecture of the newly implemented systems will assume an added
importance in helping to define the future information systems strategy.

The existing technical architecture of a business may or may not be


important for the implementation of a new system, depending on the
scope of the implementation. If the existing legacy systems are to be

Oracle Method Definition 2 - 17


completely or largely replaced and/or the project is a Fast Track
implementation, gathering information about the existing systems may
not be necessary. Conversely, an implementation that will reuse the
existing business technical infrastructure, or will integrate with
preserved existing systems, may require additional work to understand
the technical components of the existing systems.

The application architect works closely with the technical architect to


create a prototype architecture that satisfies the high-level business and
information systems requirements and policies. The prototype
Conceptual Architecture forms the basis of the architecture working
model for the project and covers both application and technical
architecture. After this stage the Conceptual Architecture is preliminary
and will be in a format that both non-technical project managers and
sponsors can understand. If there are multiple architectural options,
this deliverable should present the options and their tradeoffs, and the
review of the Conceptual Architecture will include a decision regarding
which option to use as a working architecture model. Even in projects
where the architecture is fairly clear cut (such as a single application
installation on a single database server) creating a conceptual view of
the architecture so that senior management understands the architecture
and technical direction of their business can still be useful.

Module Design and Build


A worthwhile goal of any implementation is to use the Applications as
they were designed; in other words, without customization. However,
most projects include custom development, even if it is limited to
interfaces and custom reports. Descriptive Flexfields, Alerts, and
Zooms are also customizations, even though you can implement them
without traditional coding.

The Customization Strategy outlines the customization philosophy, such


as minimizing customization as much as possible. It also describes the
development tools developers will use for each type of module.

An important part of the strategy is how much overlap is acceptable


between phases. For example, some of the functional teams may
complete their mapping earlier than others. Should designers begin
writing design documents for required custom extensions before other
teams have completed their mapping? After the team approves some
design documents, should programmers begin building custom
modules before other designs are completed? Allowing some overlap
can speed up the implementation; however, it increases the risk of
rework, since solutions arrived at later may affect earlier decisions.

2 - 18 Definition AIM Method Handbook


Data Conversion
Definition provides the client with two deliverables that define
Conversion Scope, Objectives, and Approach and Conversion Strategy.
Detail the client’s conversion requirements (both programmatic and
manual conversion requirements) when defining Conversion Scope,
Objectives, and Approach. These requirements then form the
foundation for documenting the Conversion Strategy. This strategy
should provide a complete solution for meeting the client’s conversion
requirements. If an automated tool provides the best conversion
solution for your client, then discuss this in the Conversion Strategy
document.

The two conversion tasks in this phase are prerequisite tasks for
preparing the project workplan and estimate. Prepare the initial project
workplan and estimate after the Conversion Scope, Objectives, and
Approach task is complete. Revise the project workplan and estimate
after the Conversion Strategy deliverable is prepared.

Documentation
The documentation process addresses the needs of users, technical, and
operations staff. Designate a key resource from each area as part of the
committee that specifies documentation requirements, standards, and
procedures. The detailed documentation plan should identify all
sources of information required by the documentation team, as well as
roles and responsibilities for reviewing the deliverables.

The glossary documents the vocabulary of a project and should include


unfamiliar or confusing terms. The business community, IS
department, and project team should participate in the selection of
words for the glossary and reach agreement on the definitions. The
glossary often includes terms that describe the new system
functionality, or words whose meanings are changing from the old to
the new system.

Performance Testing
The Performance Testing Scope, Objectives, and Approach, and Strategy
tasks define the high-level scope for this process, the requirements for
testing, and the main tools and techniques that will be used. The
complexity of the test and any specialized resources needed to perform
the work are also documented.

Decide whether to use some form of automated testing tools in the


Performance Testing Strategy. Some automated load testing tools can

Oracle Method Definition 2 - 19


provide the means to simulate complex processing environments with
many simultaneous online transactions. However, these tools are
generally costly and require special expertise and training. If this
process will not employ an automated tool, then the team will have to
devise other methods for conducting the test.

The timing of when to initiate a performance test will depend on the


precise scope and goals of the project. If the test objective is to provide
metrics to support architectural decisions (for example, the capacity
needed for a database server, or the performance viability of a
centralized or distributed hardware configuration), the test should
probably be conducted early in the implementation project. If a test
objective is to validate business processes throughout the project, then it
may occur in the middle of a project. At the very end of a project,
performance testing may help to tune the system. The same test
programs can be reused throughout the project life-cycle.

Performance testing usually requires a controlled test environment that


may mean isolating the test from other project work, on separate test
machines. This may also be wise from the standpoint that a
performance test may put an undue load on servers and networks and
could severely impact other project processes in shared environments.
Plan the test environment and identify hardware that is available to the
test team in Definition. Ideally, the technical hardware and software
environment should be identical to the production environment, but
this may not be possible depending on project circumstances. If it is
not, you should try to minimize the differences and establish the impact
on the test results. If the test will require a volume test database, you
will also need to plan for significant disk capacity.

Training
The project team must prepare to take on the challenges of business
process redesign and systems implementation. The more they know
about proven methods for adapting the business to a new system, the
more they will perform an advocacy role. The team must gain an
understanding of the fundamentals of application implementation and
how the business must operate in the new environment. The team must
acquire a conceptual level of knowledge about application features and
functionality. Additionally, courses to improve their skills (such as
project management skills, manufacturing principles and practices, and
so on) must be delivered.

2 - 20 Definition AIM Method Handbook


This page intentionally left blank.

Oracle Method Definition 2 - 21


Estimating

The following table indicates the typical percentage of effort required by


each task by role.

Application Administrator

Business Line Manager

Database Administrator
Client Project Manager
Configuration Manager
Applications Architect
Applications Expert

Database Designer

IS Operations Staff
Business Analyst
Phase Effort

IS Manager
Facilitator
Analyst
Definition
ID Task %
Business Requirements Definition 36.1%
A.RD.010 Identify Financial and Operating Structure 0.9% 100 0
A.RD.020 Conduct Current Business Baseline 9.0% 90 0 10
A.RD.030 Develop Future Process Model 18.1% 90 0 10
A.RD.040 Develop Future Business Function Model 5.4% 100
A.RD.050 Establish Process and Mapping Summary 0.5% 100 0
A.RD.060 Gather Business Volumes 2.2% 100 0
Application & Technical Architecture 15.0%
A.TA.010 Define Architecture Scope, Objectives, and Approach 0.9% 10 0
A.TA.020 Prepare Architecture Strategy 1.1% 10 0
A.TA.030 Establish Architecture Requirements 1.6% 45 10 0
A.TA.040 Develop Conceptual Architecture 8.6% 40 20 0 0
A.TA.050 Conduct Technical Architecture Baseline 2.7% 20 0 0
Module Design & Build 1.4%
A.MD.010 Prepare Customization Strategy 1.4%
Data Conversion 2.7%
A.CV.010 Define Conversion Scope, Objectives, and Approach 1.4% 0
A.CV.020 Prepare Conversion Strategy 1.4% 0
Documentation 7.3%
A.DO.010 Prepare Glossary 1.8% 95
A.DO.020 Specify Documentation Requirements 2.7% 85 0
A.DO.030 Determine Documentation Standards and Procedures 2.7% 0
Performance Testing 1.8%
A.PT.010 Define Performance Testing Scope, Objectives, and Approach 0.9% 0
A.PT.020 Prepare Performance Testing Strategy 0.9% 0
Training 10.8%
A.TR.010 Prepare Training Strategy 1.9% 0 0
A.TR.030 Conduct General Education Classes 4.0% 0
A.TR.040 Conduct High-level Overview of Application Features 4.9% 0
Project Management 24.9%
PJM Manage Phase 24.9%
CONT Contingency 0.0%
100.0%

Table 2-6 Definition Phase Estimating

2 - 22 Definition AIM Method Handbook


0
IS Support Staff

Lead Tester

Module Designer

5
Network Adminstrator

Oracle Method
Production Database Administrator

Programmer

5
Project Database Administrator

5
Project Manager

60
15
30
10
30
30

0
0
0
0
0
Project Sponsor

Quality Auditor

5
Systems Administrator

System Architect

Table 2-6
Team Leader-Architecture

80
40
45
50
50
Team Leader - BR

0
Team Leader-Conversion

20
Team Leader-Customization

25
Team Leader-Documentation

30
10
Team Leader - Mapping

Team Leader-Performance Testing

70
55
Team Leader - Testing

5
5
Team Leader-Training

30
Technical Analyst

15
80
90

Technical Architect
10
10

Technical Expert
75

Definition Phase Estimating (cont.)


Technical Expert - Build

Technical Expert - Design

Technical Expert - Environment


5

Technical Expert-Existing Systems

Technical Writer
70

Tester

Trainer
95
95
10
0
0
0
0
0
0
0

User

Definition 2 - 23
Task Summary
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
Scheduling

The critical role during Definition is the analyst. By assigning more


analysts during this phase, you may be able to shorten the critical path.

Key decision makers in the user and upper management communities


are frequently on the critical path. Although their availability can
impact the project schedule and the quality of decisions, their schedules
can be difficult to predict. Upper management should encourage key
personnel to allocate sufficient time to the project.

Be realistic about the number of resources that can be applied to a task


effectively. In general, you should stop adding resources to a role when
average utilization starts to fall below 100 percent of the target. This is a
symptom that the incremental communication and administration
associated with adding resources is reducing productivity. Allow a
time contingency in the schedule to cover unforeseen events or delays.

Scheduling Suggestions
Scheduling suggestions for Definition follow:

Project Management
During Definition, spend sufficient time developing a sound project
plan with associated resource and cost forecasts. For moderate to large
projects it is not unusual to spend several person weeks developing a
good plan. The critical path is a sequence of critical tasks throughout
the project. If one of those tasks takes one day longer than planned, the
end date of the project will be one day later. Tasks not on the critical
path have slack; they can be completed later than planned without
affecting the end date for the project.

Warning: Avoid planning with too much detail. It is


tempting to define tasks at a very detailed level during
planning. However, later you may discover that tracking
progress at this level is so time consuming that you abandon
tracking altogether.

Business Requirements Definition


An organization may want to implement the applications as quickly as
possible with minimal customizations and, if necessary, change the way

2 - 24 Definition AIM Method Handbook


they do business to match the application’s functionality. In other cases,
the approach is to minimize operational changes by appropriately
customizing the applications.

The need for thorough fact gathering and analysis regarding current
business processes depends on how much business change is expected.
At a minimum, you need to identify all business processes and
functions that will be affected by the implementation and develop a
sufficient understanding of those processes and functions to determine
how to change them to match how the applications work.

Application and Technical Architecture


Carefully consider the timing of this work. Too often the need for
additional hardware, systems software, and data administration time is
identified after the project budget has been finalized.

This can be an opportunity to use external consulting resources in a


cost-effective way. Consultants can have a large impact in a short time.
In this way important knowledge can be transferred to local staff and
correct sizing estimates and architectural decisions can be made.

Consider the impact of a multi-phased deployment on the scheduling of


this process. For example, you may elect to go live with the new
applications at different times at different sites. In this case, your
technical architecture may need to grow over time to support the
phased deployments.

Module Design and Build


Module Design and Build scheduling depends on several factors that
can be determined during Definition, for example:

• When will you need the development environment?


• When will you begin to bring developers onto the team?
• What is your approach to establishing test data so your
developers can test their custom software?
• What kinds of technical design, coding, testing and
documentation standards do you need, and when must they be
ready?

Oracle Method Definition 2 - 25


• Will you deploy the applications in multiple phases? If so, over
what period of time will you need development resources? Will
you be doing all custom software development up front, or will
you do customization, interface, or conversion custom
development for each deployment phase?

Seek an optimally sized development group. Development activity


seems to be more sensitive to the size of the group than other activities.
Avoid too large of a group, which can introduce inefficiencies due to
incremental communication and administrative time requirements as
the number of people increases.

Data Conversion
The Data Conversion tasks from subsequent phases can be performed in
Definition if the existing systems data is well understood and no
significant issues arise. The benefit of an early execution of Data
Conversion is the support for module and module integration testing in
Module Design and Build.

Documentation
Determine what documentation will need to be produced. For example:

• Will you produce a user manual? If so, what will it contain?


• What kind of technical documentation will be produced?
• If multiple deployments will occur for different business units,
will user documentation be different for each deployment? Will
all business units use the applications in the same way?

The scope of the user and technical documentation to be produced and


the techniques used to create this material can have a major impact on
the project schedule.

Performance Testing
Early in the project, assess the risk of encountering performance
problems. If there is significant risk, incorporate Performance Testing in
the project plan. Consider the following questions:

• What will the system load be?


• What technical architecture will be provided?
• What are the system’s performance requirements (for example,
response time, report creation, and delivery time)?

2 - 26 Definition AIM Method Handbook


Staffing

This diagram illustrates a typical project organization for Definition.

Definition Organization

Project Management

Project Management Administrative Assistant/


Support Team Project Librarian

Configuration Management Resource Management

Control & Reporting Quality Management

Resource Management Oracle Product/SupportLiaison

Oracle Account Manager Data Base Administration

Business Requirements Technical Architecture &


Definition & Mapping Performance Testing

Existing Systems
Examination

Functional Area
Team
(A)

Team Lead

Team Members

Functional Area
Team
(B)

Team Lead

Team Members

Business Process
Integration

Data Conversion Training &


Documentation

Figure 2-3 Staffing Chart for Definition

Oracle Method Definition 2 - 27


Staffing Suggestions
This section provides advice and comments on project organization for
Definition.

Project Management
One of the most important decisions for an application implementation
is the kind of project management team that will be established. A full-
time project manager should be provided for all but the smallest
application implementation projects.

If the complexity of a project goes beyond a certain point, frequently


driven by the need for multiple deployment phases, you may need to
treat the effort as multiple projects.

Business Requirements Definition


A key staffing requirement is recruiting analysts with good
interpersonal skills, a knowledge of the business and application
functionality, and sufficient data conversion expertise to conduct
preliminary conversion analysis. If applications will be deployed in
phases at multiple sites, your analysis activities will be more complex,
which may require more experienced staff. For example, a phased
deployment may mean that some sites will be using the new
applications, while others are still using the legacy systems. This can
necessitate the use of temporary bridge systems. Until all sites are
deployed, these systems pass transactions to the appropriate system
used for consolidating reporting.

Application and Technical Architecture


This process must be staffed by an experienced technical architect. A
multi-phased deployment approach may complicate the technical
architecture by introducing time phased requirements. In this case, be
sure your technical architect has experience with this approach.

Module Design and Build


The key Definition activity for this process concerns design and
planning for establishing the development environment. Ensure that
someone skilled in development management is available for this task.

A phased deployment approach may significantly affect the timing of


staffing needs for Module Design and Build. For example, if you are
deploying to different sites at different times, you may need to develop

2 - 28 Definition AIM Method Handbook


custom software associated with various deployments. This could
significantly affect the timing of your staffing needs.

Data Conversion
This process requires individuals skilled in analysis, programming,
testing, performance tuning, and transition. During this phase, you
need someone who can perform high-level analysis tasks to identify
data conversion needs.

Software tools that can significantly improve productivity are available


from various vendors. Using these tools may require lead time for
evaluation, acquisition, and installation. If you use such a tool, you may
need staff with related expertise.

If you deploy in multiple phases, you will need to perform data


conversions at different times. This affects the timing of your staffing
needs.

Documentation
Since this phase includes finalizing the documentation strategy, you
need staff that can advise you on various documentation approaches.
Determine if new documentation will be required or existing
documentation will be updated.

A multi-phased deployment approach may require documentation tasks


to be performed for each deployment. If various business units do
business in different ways, some user documentation may need to
change for each deployment. This would affect the timing of related
staffing requirements.

Performance Testing
Specialists are required to effectively perform this process. Decisions
regarding whether such staff will be needed are made in this phase.

If you deploy in multiple phases, you may need a phased Performance


Testing approach. Make sure that the maximum load your system will
experience after all deployments can be handled by the planned
configuration. This consideration could affect the timing of staffing
needs.

Oracle Method Definition 2 - 29


Training
Decisions about the training approach are made in this phase; therefore
you need staff that can advise you on approaches. For example, you
might decide to:

• develop custom training


• use standard Oracle training
• use Oracle instructors at your site
• use internal people as trainers with a separate class to “train the
trainers”
• train Information Systems analysts to support the new
applications
• conduct separate training for each deployment in a multi-phased
project

Decisions related to these issues will impact your staffing requirements.

2 - 30 Definition AIM Method Handbook


CHAPTER

3 Operations Analysis

T his chapter describes the Operations Analysis phase of AIM. The


goal of Operations Analysis is to formulate the detailed
requirements for the computer application system and to propose a
solution.

Definition Operations Solution Build Transition Production


Analysis Design

Business Requirements Definition

Business Requirements Mapping

Application & Technical Architecture

Module Design & Build

Data Conversion

Documentation

Business System Testing

Performance Testing

Training

Production Migration

Figure 3-1 Context of AIM Operations Analysis Phase

Oracle Method Operations Analysis 3 - 1


Overview
This section provides an overview of Operations Analysis.

Objectives

The objectives of Operations Analysis follow:

• Produce accurate information, function, and process models for


the business areas being addressed.
• Define the detailed function, data, and operational requirements
that the new application system must support.
• Map business requirements to application capabilities and
propose solutions to gaps.
• Define a technical architecture of hardware and software in
which the application system must perform.
• Propose a transition strategy for moving from the current system
to the new application system.
• Identify audit and control reporting and application integration
requirements.
• Train the project team.
• Develop performance testing models and scenarios.

Critical Success Factors

The critical success factors of Operations Analysis follow:

• active participation by team management and knowledgeable


user and technical representatives from the area of the business
affected by the project
• thorough knowledge of the standard functionality of the
applications being implemented
• timely resolution of outstanding issues and questions

3 - 2 Operations Analysis AIM Method Handbook


• clear definition of the business objectives to be addressed by the
project
• access to information related to the existing business processes
and systems affected by the project
• effective management

Overview Table

This table illustrates the prerequisites, processes, and key deliverables


for Operations Analysis.

Process Prerequisites Key Deliverables

Application and Architectural Requirements Application Security Architecture


Technical Architecture
Architectural Strategy Application Function Architecture

Business Volume Requirements Hardware and Network


Architecture
Conceptual Architecture
Logic Application and Database
Architecture
Future Applications Deployment
Performance Risk Assessment
Process and Mapping Summary
Physical Database Architecture
System Availability Strategy
System Capacity Plan
Technical Architecture Baseline
System Management Procedures

Module Design and Business Data Mapping Form Database Extension Design
Build
Customization Strategy Module Function Design

Solution Document Module Technical Design

Oracle Method Operations Analysis 3 - 3


Process Prerequisites Key Deliverables

Data Conversion Conversion Scope, Objectives Conversion Data Mapping


and Approach

Conversion Standards Conversion Program Design

Conversion Strategy Conversion Test Procedures

Current Business Baseline

Documentation Document Prototypes and


Templates

Document Requirements

Document Standards and


Processes

Documentation Environment

Business Systems Testing Mapping Scenario Testing Strategy

Integration Fit Analysis

Performance Testing Performance Test Transaction Performance Test Data Design


Models
Performance Test Scripts

Test Database Load Program


Design

Test Transaction Program Design

Training User Training Manuals

Production Migration Education and Training Plan Detailed Transaction and


Contingency Plan

Transition Strategy Production Support Infrastructure

Table 3-1 Operations Analysis Phase Overview Table

3 - 4 Operations Analysis AIM Method Handbook


Prerequisites

Prerequisites for Operations Analysis follow. You should use these


prerequisites, if they exist, prior to beginning this phase. Otherwise,
you may need to create them during Operations Analysis.

Prerequisite Source

Architectural Requirements Application and Technical


Architecture

Architectural Scope, Objectives, and Application and Technical


Approach Architecture

Architectural Strategy Application and Technical


Architecture

Business Volume Requirements Business Requirements


Definition

Conceptual Architecture Application and Technical


Architecture

Conversion Scope, Objectives, and Data Conversion


Approach

Conversion Strategy Data Conversion

Current Business Baseline Business Requirements


Definition

Customization Strategy Module Design and Build

Documentation Standards and Documentation


Procedures

Documentation Requirements Documentation

Education and Training Plan Training

Financial and Operating Structure Business Requirements


Definition

Oracle Method Operations Analysis 3 - 5


Prerequisite Source

Future Business Function Model Business Requirements


Definition

Future Process Model Business Requirements


Definition

Glossary Documentation

Performance Testing Scope, Performance Testing


Objectives, and Approach

Performance Testing Strategy Performance Testing

Process and Mapping Summary Business Requirements


Definition

Technical Architectural Baseline Application and Technical


Architecture

Table 3-2 Operations Analysis Phase Prerequisites

Processes

The processes used in this phase follow:

Business Requirements Definition


Create detailed business requirements scenarios that depict sequenced
elementary business functions for mapping process steps to
applications. Determine business requirements for system availability.
Define audit and control requirements for financial and system
administration purposes. Define reporting requirements for all
functions.

Business Requirements Mapping


Map business requirements to application functionality. Prove the
viability and feasibility of proposed business processes and their
integration. Map information flow and access needs by organization.

3 - 6 Operations Analysis AIM Method Handbook


Application and Technical Architecture
Develop strategies to meet the reporting needs and system availability
requirements of the business. Determine the details of deploying the
new application across data centers within the scope of the new
architecture. Refine the initial conceptual architecture and identify any
subsystems that need to be developed or integrated.

Data Conversion
Prepare the Conversion Standards to be used throughout the conversion
process.

Documentation
Create the documentation environment and produce the prototypes and
templates.

Performance Testing
Identify the test models that will be used to simulate the system or
system components that are within the scope of the test.

Training
Provide technical and functional application training to the project
team, including specific training segments for defining and using the
applications as well as maintaining the system.

Production Migration
Prepare a transition strategy for migrating the company, systems, and
people into the new enterprise system.

Oracle Method Operations Analysis 3 - 7


Key Deliverables

The key deliverables of this phase follow:

Deliverable Description

Acceptance Certificate Agreement by management that the


integrated business solutions satisfy
business objectives.

Architecture Subproject Proposals for architecture subprojects


Proposals to design and build, or integrate,
architecture subsystems.

Architecture Subsystems Describes the subsystems needed to


support the new architecture. The
subsystems may be designed and
built in-house, or may be purchased.
Examples include data warehouses,
OLAP systems, and enterprise data
transport mechanisms.

Audit and Control A statement of security, maintenance,


Requirements and monitoring of the production
system.

Business Availability A statement of the business needs in


Requirements terms of operating hours, system
uptime, and response and
turnaround time.

Business Data Mapping Verification that the underlying table


structures and attributes will support
business processes.

3 - 8 Operations Analysis AIM Method Handbook


Deliverable Description

Business Requirements Detailed business requirements


Mapping Form written in business language and
associated with business processes,
analysis and comparison of the
current solution for a business
requirement to a proposed solution,
and details for the type and nature of
the solution in a descriptive format.

Business Requirements A set of formal statements of the


Scenarios detailed business requirements for
each business process, the source of
these requirements, how these
requirements will be satisfied (either
by the application, manual process
steps, workarounds or other
application solutions), and what
prototyping steps must be taken to
prove the designs.

Conceptual Architecture Revision of the original Conceptual


Architecture to reflect analysis done
during Operations Analysis.

Conversion Standards Documents naming conventions, file


structures, automated data
conversion toll usage standards, and
so on, used to ensure consistency and
quality.

Documentation Environment Contains the Documentation


Environment Proposal, procurement
information, and installation
documentation.

Documentation Prototypes Prototypes and templates developed


and Templates for documentation, for example: User
Reference Manual, User Guide,
Technical Reference Manual, and
System Management Guide.

Oracle Method Operations Analysis 3 - 9


Deliverable Description

Future Application Details the future deployment of


Deployment applications needed to support the
business and information systems
requirements and the broader
corporate vision.

Future Process Models Defines the future business model in


the form of integrated process flows
built upon the business processes
supported by the new application.

Information Access Model A model that depicts access to key


process and organization information
for reporting and/or security
purposes.

Information Flow Model A model that visually depicts


information flows in the business
between business functions, business
organizations, and applications.

Integration Fit Analysis Identifies the new integration points


which will require interfaces.

Mapping Scenario A plan for and record of business


solution testing, including business
processes involved in the test, the
business conditions that are needed
to test the application system,
definition of test script execution,
support tools required during
execution of the test, and a record of
test actions.

Master Report Tracking List A document that supports the


analysis and mapping of report
requirements to future business
processes and standard application
reports. It contains a consolidated
list of reporting requirements and the
final disposition of report
requirements.

3 - 10 Operations Analysis AIM Method Handbook


Deliverable Description

Performance Test Scenarios The performance test scenarios that


will be simulated in performance
testing. These are point-in-time
snapshots of the total production
system processing environment that
will be modeled in the performance
test. There may be more than one
performance test scenario to model,
and each may have a different set of
transactions.

Performance Test The transaction models that will be


Transaction Models used to simulate each performance
test scenario. They will, in general,
contain a subset of the total
transactions and processing that
would occur in a real system and are
approximations to the real processing
environment in a live system. This
also discusses the transaction rates
and measurements to be used for
testing.

Project Team Training The environment to be used for


training the project team.

Training Preparation Lists the resources required for


Checklist project team training.

Trained Project Team Project personnel trained to perform


assigned project tasks.

Reporting Strategy Strategy for the reporting systems


needed to support the various
reporting requirements of the
business. Includes operational, ad
hoc, decision support, and analytical
reporting across applications,
databases, and sites.

Oracle Method Operations Analysis 3 - 11


Deliverable Description

Solution Document A document that summarizes the


business need that the application
features cannot meet, and proposes a
solution that can include a
combination of custom components,
manual workarounds, and other
existing application features.

System Availability Strategy Documents the strategy for handling


planned and unplanned outages. It is
the system implementation of the
more general business availability
requirements.

Transition Strategy Outlines the approach for migrating


the people, company, and system to
production status. Includes
transition and contingency plans and
transition support strategy.

Table 3-3 Operations Analysis Phase Key Deliverables

3 - 12 Operations Analysis AIM Method Handbook


Approach
This section describes the approach for Operations Analysis.

Tasks and Deliverables

This table lists the tasks executed and the deliverables produced during
Operations Analysis.

ID Task Deliverable

Business Requirements Definition


RD.070 Create Business Requirements Scenarios Business Requirements Scenarios
RD.080 Determine Audit and Control Requirements Audit and Control Requirements
RD.090 Identify Business Availability Requirements Business Availability Requirements
RD.100 Develop Reporting Requirements Master Report Tracking List
Business Requirements Mapping
BR.010 Prepare Mapping Environment Configure Mapping Environment
BR.020 Map Business Requirements Business Requirements Mapping
Form
BR.030 Map Business Data Business Data Mapping Form
BR.040 Conduct Integration Fit Analysis Integration Fit Analysis
BR.050 Develop Information Flow Model Information Flow Model
BR.060 Develop Information Access Model Information Access Model
BR.070 Conduct Reporting Fit Analysis Master Report Tracking List
BR.080 Test Business Solutions Mapping Scenario
BR.090 Confirm Integrated Business Solutions Acceptance Certificate
Application and Technical Architecture
TA.060 Develop System Availability Strategy System Availability Strategy
TA.070 Define Future Application Deployment Future Applications Deployment
TA.080 Develop Reporting Strategy Reporting Strategy
TA.090 Revise Conceptual Architecture Conceptual Architecture
TA.100 Define Architecture Subsystems Architecture Subsystems
TA.110 Propose Architecture Subprojects Architectural Subproject Proposals
Module Design and Build
MD.020 Define and Estimate Custom Extensions Solution Document

Oracle Method Operations Analysis 3 - 13


ID Task Deliverable

Data Conversion
CV.030 Prepare Conversion Standards Conversion Standards
Documentation
DO.040 Prepare Documentation Environment Documentation Environment
DO.050 Produce Documentation Prototypes and Documentation Prototypes and
Templates Templates
Performance Testing
PT.030 Identify Performance Test Scenarios Performance Test Scenarios
PT.040 Identify Performance Test Transaction Models Performance Test Transaction Models
Training
TR.020 Prepare Project Team Training Environment Project Team Training Environment
TR.050 Prepare Project Team Training Training Preparation Checklist
TR.060 Train Project Team Trained Project Team
Production Migration
PM.010 Prepare Transition Strategy Transition Strategy
Table 3-4 Operations Analysis Phase Tasks and Deliverables

3 - 14 Operations Analysis AIM Method Handbook


This page intentionally left blank.

Oracle Method Operations Analysis 3 - 15


Task Dependencies

This diagram shows the dependencies between tasks in Operations


Analysis.
Operations
Analysis

RD.100
Develop Reporting
Requirements
RD.100

BUSINESS RD.090 RD.060 RD.070


Identify Business Create Business Determine Audit
R EQUIREMENTS Availability Requirements and Control
D EFINITION Requirements Scenarios Requirements
RD.090 RD.070 RD.080

RM.040
Map Business
Data
BR.030

RM.010 RM.020
Prepare Mapping Map Business
Environment Requirements
BR.010 BR.020
BUSINESS
R EQUIREMENTS
M APPING RM.050
Conduct
Integration Fit
Analysis
BR.040

TA.070
Define Future
Application
APPLICATION AND Deployment
T ECHNICAL TA.070
ARCHITECTURE TA.060
Develop System
Availability
Strategy
TA.060

Figure 3-2 Operations Analysis Phase Task Dependencies

3 - 16 Operations Analysis AIM Method Handbook


Operations
Analysis

BUSINESS
REQUIREMENTS
DEFINITION

RM.060
Test Business
Solutions
BR.080 BUSINESS
REQUIREMENTS
M APPING
RM.110 RM.070
Develop Confirm Integrated
Information Flow Business
Model Solutions
BR.050 BR.090

RM.120 RM.030
Develop
Conduct Reporting
Information
Fit Analysis
Access Model
BR.070
BR.060

TA.080
Develop Reporting
Strategy
TA.080
APPLICATION AND
TECHNICAL
TA.090 TA.100 TA.110 ARCHITECTURE
Define Propose
Revise Conceptual
Architecture Architecture Architecture Sub-
Subsystems projects
TA.090
TA.100 TA.110

B C

Figure 3-2 Operations Analysis Phase Task Dependencies (cont.)

Oracle Method Operations Analysis 3 - 17


Operations
A
Analysis

MODULE DESIGN
AND BUILD

CV.030
Prepare
DATA Conversion
Standards
CONVERSION CV.030

DOCUMENTATION

PERFORMANCE
TESTING

TR.050
Prepare Project
Team Training
TR.050
TRAINING TR.020 TR.060
Prepare Project
Team Training Train Project Team
Environment TR.060
TR.020

PRODUCTION
MIGRATION

Figure 3-2 Operations Analysis Phase Task Dependencies (cont.)

3 - 18 Operations Analysis AIM Method Handbook


B C
Operations
Analysis
MD.020
Define and
Estimate Custom MODULE DESIGN
Extensions
AND B UILD
MD.020

DATA
CONVERSION

DO.040 DO.050
Produce
Create
Documentation
Documentation
Prototypes and DOCUMENTATION
Environment
Templates
DO.040 DO.050

PT.030 PT.040
Identify
Identify
Performance Test
Performance Test PERFORMANCE
Transaction
Scenarios
PT.030
Models TESTING
PT.040

TRAINING

PM.010
PRODUCTION
Prepare Transition
Strategy MIGRATION
PM.010

Figure 3-2 Operations Analysis Phase Task Dependencies (cont.)

Oracle Method Operations Analysis 3 - 19


Managing Risks

The areas of risk and mitigation for Operations Analysis include the
following:

Risk Mitigation

Team members inadequately Provide project team training


trained on the use of regarding methods and tools.
methods and tools.

Screen project team candidates to


ensure necessary skills and
experience will be available.

Insufficient business process Ensure training sessions sufficiently


research. explain that process research goes
down to the level of Elementary
Business Functions and validate that
the research reaches this level.

Erroneous statement of Obtain agreement from the user


required system availability. community about the level of system
outage that can be tolerated by the
business.

Inconsistency of team Assign process design and mapping


composition and expertise teams to groups of business
across process design, processes or areas and keep them
mapping, narrative writing, together across all analysis and
and approval activities. design tasks.

Inconsistency of team Conduct training sessions for team


methods and approaches members on methods and
across business areas or approaches. Have them demonstrate
process groups. required skills with a qualified
instructor.

Inadequate integration of Create an integration team that


processes across design and monitors process designs. As they
mapping teams. are in-process, look for inter-team
integration problems.

3 - 20 Operations Analysis AIM Method Handbook


Risk Mitigation

Limited understanding by Screen project team candidates to


the project team of the ensure necessary skills and
applications tools to be experience are present.
implemented and generally
accepted industry practices.

Limited access to information Conduct frequent checkpoints that


about business areas, their include a management review to
processes, and information ensure that teams engaged in analysis
generation and use. activities are not being blocked from
gathering information.

Incomplete consideration of Employ team members with


the capabilities and appropriate experience or knowledge
limitations of the technology about the technology.
on which the architecture
will be based.

Lack of visibility of major Assemble architecture team


architecture issues occurring representation in channels or forums
in different areas or teams. to discuss major cross-functional or
business issues.

Insufficient communication Communicate the conceptual


to the wider project team of architecture model to the broader
the chosen conceptual project team so that everyone is
architecture model to all properly informed.
team members.

Not initiating development of Allow adequate investment of


complex, bi-directional resources and time in developing a
system interfaces early sound project plan and follow it to
enough in the project. ensure tasks are begun early enough
in the project life cycle.

Lack of technical expertise Recruit team members with


affecting decisions appropriate experience and
concerning appropriate knowledge.
technology solutions.

Oracle Method Operations Analysis 3 - 21


Risk Mitigation

Lack of expertise in Careful design of the test transaction


designing system transaction models with a clear vision of the
models that will provide objectives of the test and the extent to
useful results and provide which approximate models can
answers to the questions provide useful answers.
posed by the objectives of the
performance testing process.

Transaction models for Communicate the conceptual


performance testing built architecture model to the wider
without allowing for future project team so that everyone is
business growth, peak properly informed.
periods, or detailed
workflow patterns.

Poor or nonexistent business Survey and establish business


volume metrics and inability volume metrics in advance of
to relate the performance test conducting performance testing.
results in a meaningful way
to the production system.

Insufficient development of Start development of standards in


conversion standards. Operations Analysis using the
template for Prepare Conversion
Standards.

Poorly designed Include all key project areas in the


documentation prototypes design and approval of the
and templates. documentation prototypes and
templates.

Table 3-5 Risk Management Table for Operations Analysis

3 - 22 Operations Analysis AIM Method Handbook


Tips and Techniques

This section provides tips and techniques for managing Operations


Analysis. In addition, advice and comments on each process are
included.

Business Requirements Definition


In Operations Analysis, format detailed business requirements into
scenarios containing elementary business functions. These include
sequenced process steps that need to be supported by a combination of
application functions, manual process steps, other interfaced or
integrated applications, workarounds, or custom modules.

Along with the business requirements identified in Definition, gather


and formalize the business availability requirements that dictate system
availability needs. This will be considered during the technical
architecture process.

The flow of information that results from business processes and


transactions is portrayed both within and across organizations. The
type of information access required for operating, reporting, and
consolidation for each organization is also identified (for example, some
organizations are creators of information while others are consumers of
information). These tasks will help to formalize the understanding and
control of information access and timing requirements.

Business Requirements Mapping


During Operations Analysis, good team organization is the most
important factor affecting the quality of this process. Mapping teams
should address the same business areas and business processes as
process design teams. Ideally, the same teams will work on process
modeling and design, business requirements identification, and
mapping of requirements to application capabilities.

Key users should participate in mapping sessions. Perform mapping


close to the business process, in order to have access to agents and key
users and to allow users to witness process execution. As decisions are
made and agreements reached, document them in Business
Requirements Scenarios so that the final product reflects the proposed
business process design.

Oracle Method Operations Analysis 3 - 23


Follow the “Rule of 3-2-1.” This means that roughly three hours of
research are normally required for two hours of process design and one
hour of formal entry (capturing the BRS using a template or other tool).
Talk with real users and review real process outputs; avoid mapping
exclusively in a conference room.

Maintain a meticulous record of process prototyping. This will make


acceptance of business solutions easier. Obtain an informal agreement
before the formal signoff, if possible.

Application and Technical Architecture


The information used to refine and extend the detail of the Conceptual
Architecture comes from Application and Technical Architecture itself,
and also from Business Requirements Definition and Business
Requirements Mapping. As the business mapping proceeds, the
mapping team will make decisions about how the new applications will
be configured to run the business, and it is important that the
architecture team has visibility to these decisions and any identified
mapping gaps. Gaps which correspond to major architecture
components having a pervasive impact on the overall system become
the responsibility of the architecture team. If the gaps require
standalone architecture components, they may also be identified as
architecture subsystems.

When the architecture team has refined the Conceptual Architecture,


they should also identify architecture components that are standalone
subsystems and have a wider impact on the information systems
architecture than a localized extension to a collection of modules or a
simple interface to a third party application. Examples of such
subsystems might include a data distribution system that links multiple
application installations and legacy applications; an operational data
repository that is synchronized to provide real-time information about
the state of business; a data warehouse; or an intranet web interface to
the new systems. Typically, these types of subsystems are only
important in larger scale projects, but the concept of a non-localized
component to an architecture, affecting multiple different applications,
interfaces, or databases is entirely general.

Because of the possible impact of these subsystems on the overall


systems architecture and on multiple individual technical groups
working on the project, separate the specification, design, and build of
these systems into separate subprojects linked to the core Application
and Technical Architecture process. The individuals or teams assigned
the task of managing the subsystems will produce individual proposals
for the work needed to integrate the subsystems into the overall

3 - 24 Operations Analysis AIM Method Handbook


technical infrastructure. Even if the subprojects components are
purchased as pre-built packaged applications, significant integration
work may be necessary to integrate them.

Module Design and Build


One of the key deliverables of Operations Analysis is Solution
Documents which describes required custom extensions with work
estimates to design, build, and test all components. This is an important
decision-making document for upper management since it allows them
to evaluate the full cost of the implementation. If the time and cost to
implement the required extensions is greater than the perceived benefit,
management may ask the project team to reevaluate some of the gaps
and propose alternate solutions. You may decide to delay some of the
optional extensions until after production cutover.

The detailed work estimates in the Solution Documents are an


important input to the project manager for planning the detailed tasks
in Solution Design and Build. They also specify the need for the
technical resources you must secure for the project.

Data Conversion
In Operations Analysis, Conversion Standards should be prepared and
followed throughout Data Conversion

Documentation
The appropriate documentation environment includes the hardware,
software, and utilities that will accommodate the previously specified
documentation procedures and adequately support the technical needs
of the writing staff. Those assisting in the environment proposal should
have a thorough knowledge of the documentation procedures,
hardware, software, and utilities being considered.

Create a prototype for each document that contains a table of contents


and a sample chapter that can be easily reviewed for document design,
format, and suggested content. Prototypes present a clear visual
indicator of the final product and serve as the model for template
development.

Templates provide a baseline for the writing staff. They standardize the
style of each document and may eliminate formatting inconsistencies.
This allows the writer to concentrate on content and simplifies the
editing process that occurs later.

Oracle Method Operations Analysis 3 - 25


Performance Testing
In systems that support many tightly integrated business functions, the
processing environment may be complex and have a large number of
detailed transaction flows. In such cases approximations are inevitable
in the definition of a test model.

During this phase the performance test team constructs test models that
meet technical needs and will be financially feasible to implement. The
team will construct the models relative to predicted or actual
production system snapshots, and use input from the Business
Requirements Definition and Mapping teams to understand the way the
business will run on the new system. In this way, the team can interpret
the test results properly in the context of a real production situations.
Typically, the models selected will reflect situations of the highest
processing load on the system or on some critical component of the
system. The performance testing process depends on Business
Requirements Definition and Mapping to obtain information of
sufficient detail and quality so that the test team can construct accurate
models.

Training
During Operations Analysis, the project team is introduced to key
application features. Examples of key features are the use of multiple
sets of books and available to promise functions. This background
prepares the team for mapping tasks. Team members must have a
good understanding of system capabilities.

Production Migration
One of the key deliverables of Operations Analysis is the Transition
Strategy which outlines the approach for migrating the people,
company, and business systems to production. It includes estimated
transition resource requirements, high-level transition and
implementation contingency plans, and a transition support strategy.

The components of the Transition Strategy document are an important


input to the project manager for planning the detailed tasks in
Transition and for updating the Project Workplan. They also identify
the need for specific resources needed during the transition process.

3 - 26 Operations Analysis AIM Method Handbook


This page intentionally left blank.

Oracle Method Operations Analysis 3 - 27


Estimating
The following table indicates the typical percentage of effort required by
each task by role.

Applications Administrator

Database Administrator
Business Line Manager

Configuration Manager
Client Project Manager
Applications Architect

IS Operations Staff
Applications Expert

Database Designer
Business Analyst
Phase Effort

IS Manager
Facilitator
Analyst
Operations Analysis
ID Task
Business Requirements Definition 16.6%
B.RD.070 Create Business Requirements Scenarios 12.8% 30 50 10 5
B.RD.080 Determine Audit and Control Requirements 1.8% 100 0
B.RD.090 Identify Business Availability Requirements 0.6% 95 0
B.RD.100 Develop Reporting Requirements 1.5% 100 0
Business Requirements Mapping 40.9%
B.BR.010 Prepare Mapping Env ironment 1.7% 20 0
B.BR.020 Map Business Requirements 15.3% 5 25 35 0 5 5
B.BR.030 Map Business Data 3.0% 30 50 0
B.BR.040 Conduct Integration Fit Analysis 1.6%
B.BR.050 Develop Information Flow Model 1.4%
B.BR.060 Develop Information Access Model 1.4% 75 0
B.BR.070 Conduct Reporting Fit Analysis 2.1% 5 20 35 10 5
B.BR.080 Test Business Solutions 12.8% 30 60 0
B.BR.090 Confirm Integrated Business Solutions 1.5% 25 25 0
Application & Technical Architecture 3.6%
B.TA.060 Develop System Av ailability Strategy 0.6% 10 0 0
B.TA.070 Define Future Application Deployment 0.5% 85 15 0
B.TA.080 Develop Reporting Strategy 0.8% 50 20 0 0
B.TA.090 Revise Conceptual Architecture 0.5% 35 20 0 0
B.TA.100 Define Architecture Subsystems 0.6% 30 0
B.TA.110 Propose Architecture Subprojects 0.6% 0
Module Design & B uild 1.9%
B.MD.020 Define and Estimate Custom Extensions 1.9% 10 0
Data Conversion 0.9%
B.CV.030 Prepare Conv ersion Standards 0.9%
Documentation 2.8%
B.DO.040 Prepare Documentation Env ironment 1.2% 0
B.DO.050 Produce Documentation Prototypes and Templates 1.6%
Performance Testing 1.4%
B.PT .030 Identify Performance Test Scenarios 0.6% 35 0
B.PT .040 Identify Performance Test Transaction Models 0.7% 10 0
Training 17.8%
B.TR.020 Prepare Project T eam Training Env ironment 1.5% 20 0
B.TR.050 Prepare Project T eam Training 3.0% 45
B.TR.060 Train Project Team 13.3%
Production Migration 0.8%
B.PM.010 Prepare T ransition Strategy 0.8% 0
Project Management 13.2%
PJM Manage Phase 13.2%
CONT Contingency 0.0%
100.0%

Table 3-6 Operations Analysis Phase Estimating

3 - 28 Operations Analysis AIM Method Handbook


0
0
IS Support Staff

Lead Tester

Module Designer

70
Network Adminstrator

10

Oracle Method
Production Database Administrator

30
Programmer

2
Project Database Administrator

25
Project Manager

90
20
20
10

0
0
Project Sponsor

Quality Auditor

2
Systems Administrator

35
80
10
40
System Architect

Table 3-6
Team Leader-Architecture

80
20
5

Team Leader-BR

Team Leader - Conversion

Team Leader - Customization

5
Team Leader-Documentation
5
5
5
5
5

25
Team Leader-Mapping
10

Team Leader-Performance Testing

65
65
Team Leader - Testing

6
5
Team Leader-Training

10
5
5

Technical Analyst

25
25
20
25
95
95
20
20

10 0
Technical Architect

10
30
35
30
70

20 Technical Expert

Technical Expert - Build

Technical Expert - Design

Technical Expert - Environment

Technical Expert - Existing Systems

Operations Analysis Phase Estimating (cont.)


Technical Writer

25
15
10 0

Tester

Trainer
90
25
10
0
0
0
0

0
0
0
0
0
0

User

Operations Analysis 3 - 29
10 0
10 0

10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
Scheduling

The critical role during Operations Analysis is the analyst. By assigning


more analysts to this phase, you can shorten the critical path. Executing
tasks on the critical path in parallel also allows you to compress the
phase timeline.

Scheduling Suggestions
Scheduling suggestions for Operations Analysis follow:

Project Management
In Operations Analysis the last portion of Business Requirements
Definition is completed and the majority of Business Requirements
Mapping tasks occur. Managing the overlap between these processes
can significantly affect your schedule.

Leverage analysis time with key users since user availability may be a
critical resource constraint. If you have skilled analysts and
knowledgeable users, several objectives associated with various
processes can be achieved in one work session. To ensure quality,
formal acceptance of the deliverables from these key tasks must occur.

Operations Analysis requires a considerable time commitment from


user management and staff. Time must be allocated from day-to-day
work to provide information about the business areas’ objectives,
requirements, and work practices, and to attend reviews. The project
manager should set expectations about the level of user participation
needed by explicitly scheduling these reviews and consultations in the
workplan.

Consider the impact of a multi-phase deployment. If applications will


be deployed in phases, there may be additional requirements, gaps, and
solutions needed at each site.

Business Requirements Definition


At the beginning of Operations Analysis, assess the completeness and
accuracy of your team’s work to date. Inaccuracies occurring early in
the project can have large scheduling impacts later on.

Business Requirements Mapping


Schedule slippage for this process is often caused by:

3 - 30 Operations Analysis AIM Method Handbook


• unrealistic test data in the mapping instance
• inadequate knowledge of Oracle Applications functionality
• inadequate time commitment by key users
• neglecting to adequately assess the impact of a multi-
phased/multi-site deployment approach

Usually at this point the Oracle demo database is being used to run
mapping scenarios. Depending on your business processes, the demo
data may not be sufficient to exercise the Oracle Applications according
to your scenarios. Consider augmenting the demo data.

If you are using a multi-phase deployment approach consider using


special Oracle features such as the open application program interfaces
(APIs) to support temporary bridges from your legacy systems that may
support some business units during initial deployment phases. By
passing transaction data to Oracle Applications you can use them for
consolidated reporting and query even though a portion of the
organization temporarily continues to use legacy systems.

Application and Technical Architecture


Coordinate the detailed scheduling of this process with the Business
Requirements Definition development teams. Make sure function
frequencies and data retention rules are reviewed and agreed on from a
business perspective before finalizing the Capacity Plan.

Determine the impact of a multi-phased deployment approach on


technical architecture; they may cause schedule slippage later in the
project.

Both the new applications and legacy systems may need support until
all business units convert to the Oracle Applications. A phased
deployment approach may appear straightforward; however, there
could be major complexities in this area.

Module Design and Build


Carefully maximize overlap between the beginning of this process and
the end of Business Requirements Mapping. If there are obvious gaps
requiring custom software development, getting an early start could
shorten your schedule or, this could be done prematurely causing the
schedule to slip and overrunning the budget due to rework.

Oracle Method Operations Analysis 3 - 31


If different business units will be in production on legacy systems and
new applications, you may need to build temporary bridges between
them to support consolidated query and reporting. Consider using
Oracle’s application programming interfaces (APIs) to facilitate
bridging.
Data Conversion
Effective software products exist for data conversion that can
significantly enhance a team’s productivity. At this point the decision
regarding whether you will use such tools should have been made to
allow for acquisition, implementation, and training.

A multi-phase deployment approach may require iterations of some


data conversion tasks as the various subsets of business units go live on
the new system.

Documentation
Use an approach that leverages documentation developed earlier in the
project. A multi-phased deployment approach may have time
consuming impacts on documentation that should be addressed.

Performance Testing
A key advantage of a multi-phased approach is minimizing the risk of
major schedule slippage due to unexpected performance problems after
production. You can use actual production performance statistics to
assess capacity and add resources if necessary. A big bang approach
provides no leeway for incorrect capacity forecasts.

Training
Procrastination regarding training tasks (such as curriculum
development, training site scheduling, and instructor identification) is
common. This may result in schedule slippage later in the project or a
decision to accept lesser quality training than initially planned.

Accurately assess your training needs and determine the appropriate


approach. Curriculum development is expensive but may be the most
effective method of introducing a heavily customized system. Standard
Oracle education and custom developed training have considerations
that can end up on the critical path. When will standard Oracle classes
be taught? How soon can custom training be developed?

3 - 32 Operations Analysis AIM Method Handbook


Production Migration
The most important consideration is whether a multiple deployment
approach will be used, since Production Migration must occur for each
deployment.

Oracle Method Operations Analysis 3 - 33


Staffing

This diagram illustrates a typical project organization for Operations


Analysis.

Operations Analysis Organization

Project Management

Project Management Administrative Assistant/


Support Team Project Librarian

Business Requirements Technical Architecture &


Definition & Mapping Performance Testing

Existing Systems Team Lead


Examination

Functional Area
Team Team Members
(A)

Team Lead

Team Members

Functional Area
Team
(B)

Team Lead

Team Members

Business Process
Integration

Data Conversion Training &


Documentation

Team Lead Team Lead

Team Members Team Members

Transition Oracle Applications


Specialists

Figure 3-3 Staffing Chart for Operations Analysis

3 - 34 Operations Analysis AIM Method Handbook


Staffing Suggestions
This section provides advice and comments on project organization for
Operations Analysis.

Project Management
The most important staffing related factors in Operations Analysis are:

• having the right mix of skills due to the diversity of processes


occurring simultaneously
• fostering a sense of ownership of key decisions by appropriate
managers
• obtaining sufficient upper management, Information Systems,
and user commitment to ensure accurate and timely results
• ensuring staff follow a systematic plan with appropriate
guidelines, standards, and milestones
• dealing effectively with a mixed project team if you are using
people from various organizations (such as multiple consulting
firms, hardware/software vendors, or employees)

User and IS membership in the core project team is an effective tool in


fostering a sense of ownership in the new system. Consideration should
be given to full-time participation by key user and IS staff. Management
personnel who realize the importance of the application implementation
and the fact that its success is based on their involvement will
understand your request for full-time staff.

Business Requirements Definition


Substantial efficiencies can be gained by using some key people
throughout Business Requirements Definition and Business
Requirements Mapping.

The main difference, from a staffing point of view, between these two
processes is that a critical mass of knowledge must exist regarding how
the standard Oracle Applications function during Business
Requirements Mapping. This is where final decisions are made
regarding what aspect of the standard applications will suffice and
where customizations and/or workarounds are needed. Ideally,
thorough applications knowledge will exist throughout the entire
project.

Oracle Method Operations Analysis 3 - 35


Business Requirements Mapping
Sufficient expertise must exist regarding standard application
functionality to accurately map requirements to the applications,
identify gaps, and define customizations and/or workarounds.
Maximize continuity between the Business Requirements Definition and
Business Requirements Mapping by retaining key personnel.

Application and Technical Architecture


This process must be staffed by an experienced technical architect who
is knowledgeable in hardware, network, and operating system
considerations.

Module Design and Build


Module Design and Build work can begin when a custom solution is
complete. In some cases, team members may be assigned too late to
take advantage of the process overlap opportunities between mapping
and design. As a result, benefits to the project schedule are not
recognized.

Data Conversion
This process requires individuals skilled in analysis, programming,
testing, and transition. This process requires a diverse set of skills that
may be difficult to find.

Documentation
During Operations Analysis, the documentation environment must be
prepared to meet the needs of the people assigned to developing
documentation. Be certain to involve the writers in determining their
environment requirements.

Performance Testing
The fundamental approach to Performance Testing, and the design of
the mechanisms to be used, is defined during Operations Analysis. If
the work in this phase is accomplished well, it may be possible to use
less skilled staff to carry out the remainder of the performance testing
plan. Assure yourself that the technical architecture will support the
forecasted load by ensuring that sufficient expertise is applied to this
process.

3 - 36 Operations Analysis AIM Method Handbook


Training
By the end of this phase all major decisions regarding training
development and delivery should be made.

Production Migration
During Operations Analysis, the Transition Strategy is prepared. This
document is critical for a successful move to production. Be sure that
the individuals selected to define the strategy have a sufficient
understanding of the transition requirements.

Oracle Method Operations Analysis 3 - 37


CHAPTER

4 Solution Design

T his chapter describes the Solution Design phase of AIM. The goal of
Solution Design is to use the requirements created during
Operations Analysis and finalize the system design and proposed
applications setups.

Definition Operations Solution Build Transition Production


Analysis Design

Business Requirements Definition

Business Requirements Mapping

Application and Technical Architecture

Module Design and Build

Data Conversion

Documentation

Business System Testing

Performance Testing

Training

Production Migration

Figure 4-1 Context of AIM Solution Design Phase

Oracle Method Solution Design 4 - 1


Overview
This section provides an overview of Solution Design.

Objectives

The objectives of Solution Design follow:

• Produce a design that meets functional requirements within


business, technical, and financial constraints.
• Document the design specifications in a way that facilitates and
supports future maintenance of the system.
• Define proposed application setups and test plans.
• Create job-level designs that will support proposed business
processes.
• Design the application, security, database, and network
architectures.
• Develop functional and technical designs for custom extensions,
interfaces, conversion programs, and database extensions.
• Develop unit, link, system, and system integration test scripts.
• Design performance test scripts, test transaction programs, and
test data.
• Develop User Training Manuals.
• Develop the detailed transition and contingency plans.

Critical Success Factors

The critical success factors of Solution Design follow:

• clearly define the business objectives to be addressed by the


project
• ensure active participation by key management and
knowledgeable user and technical representatives from areas of
the business affected by the project

4 - 2 Solution Design AIM Method Handbook


• know the capabilities and features of the application and
available technology
• ensure that designs are traceable to business requirements
• manage designs so that they remain within scope
• allocate sufficient time resources
• utilize a well-managed change control system
• build a good framework for transition and contingency planning

Overview Table

This table illustrates the prerequisites, processes, and key deliverables


for Solution Design.

Process Prerequisites Key Deliverables

Business Requirements Business Requirements Mapping Applications Setup Document


Mapping Form
Process Narrative
Business Requirements Scenario
Security Profiles
Financial and Operations Structure

Information Access Model

Oracle Method Solution Design 4 - 3


Process Prerequisites Key Deliverables

Application and Technical Architectural Requirements Application Security Architecture


Architecture
Architectural Strategy Application Function Architecture

Business Volume Requirements Hardware and Network


Architecture
Conceptual Architecture
Logic Application and Database
Future Applications Deployment Architecture

Process and Mapping Summary Performance Risk Assessment

System Availability Strategy Physical Database Architecture

Technical Architecture Baseline System Capacity Plan

System Management Procedures

Module Design and Build Business Data Mapping Form Build Standards

Customization Strategy Design Standards

Master Report Tracking List Database Extension Design

Solution Document Module Function Design

Module Technical Design

Data Conversion Conversion Scope, Objectives, and Conversion Environment


Approach
Conversion Data Mapping
Conversion Standards
Conversion Program Design
Conversion Strategy
Conversion Test Plan Procedures
Current Business Baseline
Manual Conversion Strategy

4 - 4 Solution Design AIM Method Handbook


Process Prerequisites Key Deliverables

Documentation Document Prototypes and Initial User Reference Manual


Templates
Initial User Guide
Document Requirements
Initial Technical Reference Manual
Document Standards and
Processes Initial System Management Guide

Documentation Environment

Business Systems Testing Mapping Scenario Testing Strategy

Integration Fit Analysis Unit Test Scripts

Link Test Scripts

System Test Scripts

Systems Integration Test Scripts

Performance Testing Performance Test Transaction Performance Test Data Design


Models
Performance Test Scripts
Performance Test Scenarios
Test Database Load Program
Design

Test Transaction Program Design

Training Trained Project Team User Training Manuals

Production Migration Conversion Strategy Detailed Transition and


Contingency Plan
Education and Training Plan
Production Support Infrastructure
Performance Test Strategy

Transition Strategy

Table 4-1 Solution Design Phase Overview Table

Oracle Method Solution Design 4 - 5


Prerequisites

Prerequisites for Solution Design follow. You should use these


prerequisites, if they exist, prior to beginning this phase. Otherwise,
you will need to create them during Solution Design.

Prerequisite Source

Architecture Requirements Application and Technical


Architecture

Architectural Strategy Application and Technical


Architecture

Business Data Mapping Form Business Requirements


Mapping

Business Requirements Mapping Business Requirements


Form Definition

Business Requirements Scenario Business Requirements


Definition

Business Volume Requirements Business Requirements


Definition

Conceptual Architecture Application and Technical


Architecture

Conversion Scope, Objectives, and, Data Conversion


Approach

Conversion Standards Data Conversion

Conversion Strategy Data Conversion

Current Business Baseline Business Requirements


Definition

Customization Strategy Module Design and Build

Documentation Prototypes and Documentation


Templates

4 - 6 Solution Design AIM Method Handbook


Prerequisite Source

Documentation Standards and Documentation


Procedures

Documentation Environment Documentation

Documentation Requirements Documentation

Education and Training Plan Training

Financial and Operating Structure Business Requirements


Definition

Future Application Deployment Business Requirement


Mapping

Information Access Model Business Requirement


Mapping

Integration Fit Analysis Business Requirement


Mapping

Mapping Scenario Business Requirements


Mapping

Master Report Tracking List Business Requirements


Mapping

Performance Test Scenarios Performance Testing

Performance Testing Strategy Performance Testing

Performance Testing Transaction Performance Testing


Models

Process and Mapping Summary Business Requirements


Definition

Solution Document Module Design and Build

System Availability Strategy Application and Technical


Architecture

Oracle Method Solution Design 4 - 7


Prerequisite Source

Technical Architecture Baseline Application and Technical


Architecture

Transition Strategy Production Migration

Table 4-2 Solution Design Phase Prerequisites

Processes

The processes used in this phase follow:

Business Requirements Mapping


Develop process narratives documentation that will serve as input into
the creation of training materials and user procedures. Finalize
application setups, security profiles, parameters, and user security
structures.

Application and Technical Architecture


Create detailed designs for application and database deployment and
application configuration. Document the detailed hardware and
network configuration needed to support the applications deployment,
including system capacity planning. Design the system management
procedures needed to maintain the system.

Module Design and Build


Design customizations to address functionality gaps identified during
Business Requirements Mapping.

Data Conversion
Prepare the Conversion Environment, Conversion Data Mapping,
Manual Conversion Strategy, Conversion Program Design, and the
Conversion Test Plans.

Documentation
Create the Initial User Reference Manual, User Guide, Technical
Reference Manual, and System Management Guide.

4 - 8 Solution Design AIM Method Handbook


Business System Testing
Prepare a Testing Strategy that encompasses all tasks in the testing
process. Include an overview of the testing approach, the type of test
scripts to be developed, the testing to be performed, a schedule of
testing resources and responsibilities, the testing tools and
environments required, and a discussion of the problem management
process. Develop the detailed test scripts for each type of testing
including unit, link, business system, systems integration, and
regression testing. Test scripts can include test checklists, test
specifications or steps, test data profiles, and test sequences.

Performance Testing
Design the performance test database and identify how it will be
populated. Design any special database loading programs needed.
Design the test transaction programs needed to execute the test model.
Develop performance test scripts.

Training
Create materials for end-user training.

Production Migration
Develop the production support infrastructure, as well as contingency
and transition plans.

Key Deliverables

The key deliverables of this phase follow:

Deliverable Description

Application Functional The design of the functional


Architecture architecture for the applications for
each installation site.

Application Security The design of the security architecture


Architecture to support the (inter-) organization
security requirements.

Application Setup Document Setup data detailed documentation.

Oracle Method Solution Design 4 - 9


Deliverable Description

Conversion Data Mapping The mapping of the legacy system files


and data elements to the target
application tables and columns.

Conversion Program Design The program logic and rules data


conversion programs.

Conversion Test Plans The detailed conversion test plan for


both manual and automated data
conversions.

Database Extensions Design A design for new and changed


database objects, including their
relationships to standard application
database objects.

Hardware and Network The hardware, systems software, and


Architecture networks to support the applications
deployment and database architecture.

Initial User Reference Preliminary version of the User


Manual Reference Manual.

Initial User Guide Preliminary version of the User Guide.

Initial Technical Reference Preliminary version of the Technical


Manual Reference Manual.

Initial System Management Preliminary version of the System


Guide Management Guide.

Logical Application and The design of the application and


Database Architecture database architecture at the logical
level. Includes the relationship
between the functional architecture
and the logical data partitioning.
Encompasses database schemes and
logical database objects.

Manual Conversion Strategy The strategy for performing manual


data conversion in contrast to
automated conversions.

4 - 10 Solution Design AIM Method Handbook


Deliverable Description

Module Functional Design Custom module designs expressed in


user terms.

Module Technical Design Specifications for the program


modules with sufficient technical detail
enabling the programs to be
successfully coded.

Performance Risk Study of the performance risks


Assessment inherent in the chosen architecture and
the techniques and steps that can be
taken to mitigate the risk.

Performance Test Data The detailed design for the


Design construction of the test database. This
specifies the business objects and
volumes needed in the test database
and how you will populate the test
database with the prerequisite data.

Performance Test Scripts The details of the individual steps that


you will execute for each transaction
test user profile.

Physical Database The detailed design for the physical


Architecture layout of databases in the architecture.
Includes the mapping of the logical
database architecture onto the physical
subsystems that support the database.

Process Narrative A textual description of a business


diagram at a job level.

Production Support Identifies the operational


Infrastructure infrastructure for managing and
maintaining the application
environment, database, and network
communications.

Security Profiles List of role-based security


specifications necessary to ensure good
controls and transaction access.

Oracle Method Solution Design 4 - 11


Deliverable Description

System Capacity Plan The system capacity plan for the


technical configuration. Includes the
planning of client and server machines,
and addresses CPU, memory, and disk
capacity.

System Management The detailed design for the systems


Procedures management procedures necessary to
support the architecture.

Test Database Load Program The designs for any programs needed
Designs to load data into the test database.

Test Transaction Program The detailed design for any transaction


Designs programs needed for the test. This
might include programs that execute
transactions against the database, or
automated programs that manage the
execution of multiple simultaneous
transaction flows.

Testing Strategy Establishes the approach and scope of


testing activities. Identifies the testing
tools and environment to be used, and
how defects will be managed.

Transition and Contingency Detailed plan for Transition including


Plan contingency plans if problems arise.

User Training Materials Workbooks, slides, lab exercises, and


product demonstrations for user
training.

Table 4-3 Solution Design Phase Key Deliverables

4 - 12 Solution Design AIM Method Handbook


Approach
This section describes the approach for Solution Design.

Tasks and Deliverables

This table lists the tasks executed and the deliverables produced during
Solution Design.

ID Task Deliverable

Business Requirements Mapping


BR.100 Create Process Narratives Process Narrative
BR.110 Define Application Setups Application Setup Document
BR.120 Design Security Profiles Security Profiles
Application and Technical Architecture
TA.120 Design Application Security Architecture Application Security Architecture
TA.130 Design Application Functional Architecture Application Functional Architecture
TA.140 Design Logical Application and Database Logical Application and Database
Architecture Architecture
TA.150 Design Physical Database Architecture Physical Database Architecture
TA.160 Design Hardware and Network Architecture Hardware and Network Architecture
TA.170 Develop System Capacity Plan System Capacity Plan
TA.180 Assess Performance Risks Performance Risk Assessment
TA.190 Design System Management Procedures System Management Procedures
Module Design and Build
MD.030 Define Design Standards Design Standards
MD.040 Define Build Standards Build Standards
MD.050 Design Database Extensions Database Extensions Design
MD.060 Produce Module Function Design Module Function Design
MD.070 Produce Module Technical Design Module Technical Design
MD.080 Review Detailed Designs Acceptance Certificate
Data Conversion
CV.040 Prepare Conversion Environment Conversion Environment
CV.050 Perform Conversion Data Mapping Conversion Data Mapping
CV.060 Design Manual Conversion Strategy Manual Conversion Strategy

Oracle Method Solution Design 4 - 13


ID Task Deliverable

CV.070 Design Conversion Programs Conversion Program Design


CV.080 Prepare Conversion Test Plans Conversion Test Plans
Documentation
DO.060 Produce Initial User Reference Manual Initial User Reference Manual
DO.070 Produce Initial User Guide Initial User Guide
DO.080 Produce Initial Technical Reference Manual Initial Technical Reference Manual
DO.090 Produce Initial System Management Guide Initial System Management Guide
Business Systems Testing
TE.010 Develop Testing Strategy Test Strategy
TE.020 Develop Unit Test Scripts Unit Test Scripts
TE.030 Develop Link Test Scripts Link Test Scripts
TE.040 Develop System Test Scripts System Test Scripts
TE.050 Develop Systems Integration Test Scripts Systems Integration Test Scripts
Performance Testing
PT.050 Create Performance Test Scripts Performance Test Scripts
PT.060 Design Performance Test Transaction Programs Test Transaction Program Designs
PT.080 Design Performance Test Data Performance Test Data Design
PT.090 Design Test Database Load Programs Test Database Load Programs Designs
Training
TR.070 Develop User Training Materials User Training Materials
Production Migration
PM.020 Design Production Support Infrastructure Production Support Infrastructure
PM.030 Develop Detailed Transition and Contingency Detailed Transition and Contingency
Plan Plan
Table 4-4 Solution Design Phase Tasks and Deliverables

4 - 14 Solution Design AIM Method Handbook


This page intentionally left blank.

Oracle Method Solution Design 4 - 15


Task Dependencies

This diagram shows the dependencies between tasks in Solution Design.

Solution RM.080
Design Create Process
Narratives
BR.100
RM.100 RM.090
BUSINESS Design Security Define Application
REQUIREMENTS Profiles Setups
MAPPING BR.120 BR.110

TA.160 TA.170
TA.120 Design Hardware
Design Application Develop System
and Network
Security Capacity Plan
Architecture
Architecture TA.170
TA.160
TA.120

APPLICATION AND
TECHNICAL
TA.130 TA.140 TA.150 TA.180
ARCHITECTURE Design Logical
Design Application Design Physical Assess
Functional Application and Database Performance
Database
Architecture Architecture Risks
Architecture
TA.130 TA.150 TA.180
TA.140

MD.020 MD.060
Produce Module
Define Design
Functional
Standards
Designs
MD.030
MD.060
MD.050
Define Build
Standards
M ODULE DESIGN MD.040
AND BUILD MD.050
Design Database
Extensions
MD.050

CV.04
0 Prepare
Conversion
Environment
CV.040
DATA
C ONVERSION

A B
Figure 4-2 Solution Design Phase Task Dependencies

4 - 16 Solution Design AIM Method Handbook


Solution
Design

BUSINESS
R EQUIREMENTS
M APPING

TA.190
Design System
Management
Procedures
TA.190

APPLICATION AND
T ECHNICAL
ARCHITECTURE

MD.070 MD.080
Produce Module Review Detailed
Technical Designs Designs
MD.070 MD.080

M ODULE DESIGN
AND BUILD

CV.05 CV.07 CV.08


0 Perform 0 0 Prepare
Design Conversion
Conversion Data Conversion Test
Mapping Programs Plans
CV.070
CV.050 CV.080
DATA
CONVERSION
CV.06
0
Design Manual
Conversion
Strategy
CV.060
C D E F G H

Figure 4-2 Solution Design Phase Task Dependencies (cont.)

Oracle Method Solution Design 4 - 17


A B
Solution
Design

DOCUMENTATION

TE.010
Develop Test
Strategy
TE.010

BUSINESS SYSTEM
TESTING

PERFORMANCE
TESTING

TRAINING

PM.020
Design Production
PRODUCTION Support
M IGRATION Infrastructure
PM.020

Figure 4-2 Solution Design Phase Task Dependencies (cont.)

4 - 18 Solution Design AIM Method Handbook


C D E F G H
Solution
Design
DO.070
Produce Initial
User Guide
DO.070
DO.060
Produce Initial
User Reference
DO.060 DOCUMENTATION
DO.080 DO.090
Produce Initial
Produce Initial
System
Technical
Management
Reference
Guide
DO.080
DO.090

TE.020
Develop Unit Test
Scripts
TE.020

TE.030 TE.040
Develop Link Test Develop System
Scripts Test Scripts BUSINESS SYSTEM
TE.030 TE.040 TESTING

TE.090
Develop System
Integration Test
Scripts
TE.050

PT.050 PT.060 PT.080 PT.090


Create Design Design Design Test
Performance Test
Performance Test
Performance Test Database Load P ERFORMANCE
Scripts Transaction Data Programs TESTING
Programs
PT.050 PT.080 PT.090
PT.060

TR.070
Develop User
Training Materials TRAINING
TR.070

PM.030
Develop Detailed
Transition and PRODUCTION
Contingency Plan
PM.030
M IGRATION

Figure 4-2 Solution Design Phase Task Dependencies (cont.)

Oracle Method Solution Design 4 - 19


Managing Risks

The areas of risk and mitigation for Solution Design include the
following:

Risk Mitigation

Disruptive testing due to Create a comprehensive testing


unplanned revisions, even strategy that details the coordination
though decisions have been and execution of every task in the
made regarding key testing process, that should be
application setups. developed and communicated prior
to commencement of any testing-
related activity.

Disruption to design Implement a configuration


activities due to frequent management subsystem for
changes in requirements controlling project deliverables.
design and assumptions, and
weak control over design
libraries.

Establish review and sign-off process


for each design.

Inaccurate or non-existent Encourage detailed capacity planning


capacity planning. including future volume projections,
peak periods, and changes of
headcount.

Assess capacity risks and the strategy


for dealing with uncertainties.

Ensure expertise is available to


support the need for capacity
planning.

Lack of good business Train project staff in techniques for


volume information gathering business volume
necessary for capacity information.
planning.

4 - 20 Solution Design AIM Method Handbook


Risk Mitigation

Ensure effective management


support for the project, including
encouraging assignment of
knowledgeable staff to provide
information to the project team.

Lack of clear standards and Conduct reviews of database design


procedures for database before approving.
design.

Ensure that appropriate database


design standards are followed.

Poor design of automated Recruit experienced automated


tool test programs leading to testing tool technical staff or allow
re-coding to change time to adequately train staff on the
transaction models and rates tool.
during test execution.

Inaccurate or incomplete Link solution designs and setup data


application setup data. definitions to Definition and
Operations Analysis deliverables.

Inadequate design standards. Encourage the development and use


of design standards.

Conversion data mapping is Resolve the application setup


incomplete due to application unresolved issues that impact the
configuration issues not conversion data mapping and decide
being resolved and data on required data defaults.
defaults not selected.

Incorrect data conversion Provide project team training on


rules in conversion program establishing data conversion rules.
design document.

Define all conversion rules that


impact the conversion code in the
Conversion Design deliverable.

Oracle Method Solution Design 4 - 21


Risk Mitigation

Inaccurate or incomplete Ensure that test scripts, including test


linking between mapping specifications and data profiles, build
solutions and test plans. on the mapping scenarios that were
developed during Business
Requirements Definition.

Failure to develop a complete Create a comprehensive testing


and thorough testing strategy strategy that details the coordination
that covers not only test and execution of every task in the
execution, but also the testing process (develop and
coordination of test script communicate prior to
development resources, commencement of any testing-related
testing environments and activity).
tools, defect management
and the overall approach to
the testing process.

Inadequate reflection of Involve team members who were


business requirements in test responsible for analyzing business
scripts. processes and developing business
requirements in test script
development.

Underestimation of Develop a detailed plan mapping


Transition resource transition activities to existing project
requirements. resources; if needed, augment
existing resources by enlisting
additional client personnel and/or
additional consulting support.

Inadequate contingency plan. Emphasize the importance of having


contingency plans to support normal
business operations for key processes
(shipping, invoicing) in the event that
production cutover is unsuccessful.

Table 4-5 Risk Management Table for Solution Design

4 - 22 Solution Design AIM Method Handbook


Tips and Techniques

This section provides tips and techniques for managing Solution Design.
In addition, advice and comments on each process are included.

Business Requirements Mapping


Process Narratives are based on business process designs and define
how work is performed at the job level. They lay a foundation for user
procedures and user training, as well as business systems and
acceptance testing. Applications setups are defined and security
profiles are designed.

Application and Technical Architecture


Solution Design is the phase where Application and Technical
Architecture is designed. The degree of detail needed for these designs
depends on the scope of the project and the project architecture process.
If the architecture is being designed for a localized application
implementation project with a single installation, the architect will
perform these tasks in detail. The system administrators can then
configure and set up the technical infrastructure for the new system
without requiring further work.

If, however, the architecture is at the enterprise level (spanning multiple


site implementations, installations, or databases) designing to the lowest
level of detail may not be possible. Under these circumstances the
architects will design to the degree of detail possible, with the
understanding that the enterprise-level architecture will only address
the enterprise-level issues. Individual architecture processes of more
limited scope will create the detailed designs for the individual
implementations.

The application architecture design developed in this phase involves the


following areas:

• Application Security Architecture


• Application Functional Architecture
• Logical Application and Database Architecture
• Physical Database Architecture
• Hardware and Network Architecture

Oracle Method Solution Design 4 - 23


The System Capacity Plan is developed and Systems Management
Procedures are designed. Performance risks are also assessed.

The application architect creates a detailed application deployment plan


specifying key application setup configurations, logical database
architecture and application installations, and determines the
application-level security to be implemented in the system. Key
application setup parameters may be specified by the business
requirements mapping team. The application architect will take this
information as input, validate the impact of the setup decisions on
application data partitioning and logical database architecture and make
recommendations to the mapping team if necessary.

The technical architect works with the application architect to design the
hardware and network infrastructure to support the application
architecture and ensure key business and information systems
requirements are met.

Module Design and Build


A major focus of Solution Design is the design of custom extensions as
well as interfaces between Oracle Applications, legacy systems, and
third-party applications.

The overall customization approach is defined in the customization


strategy prepared during Definition. Solution Documents produced
during the end of Operations Analysis are refined and detailed designs
created.

The first step is to define the Design and Build Standards that designers
and programmers must follow. Design and Build Standards are needed
for the types of modules that you plan to build to support the solutions
defined during Operations Analysis. For example, if no solutions
require the use of database triggers, related standards are not needed.
Once design standards are defined, designers can begin writing
functional design documents while the build standards are being
documented.

If there are many customizations, the Module Design and Build process
can consume a large portion of the schedule and budget. It is important
to schedule the appropriate technical resources and allocate time for
business analysts and users to participate in testing. The project plan
should include sufficient detail so that resources can be assigned to
individual modules.

4 - 24 Solution Design AIM Method Handbook


Data Conversion
Prepare the environment that will be used for the data conversion
design, build, and testing tasks, then map the legacy data elements to
the Oracle Application tables and columns. If a standard interface is
provided with the Oracle Application, the legacy data should be
mapped to the standard interface tables and columns.

After the conversion data mapping is complete, the conversion


programs should be designed. If an automated conversion tool is being
used, you may need traditional code. Regardless of the tools being
used, conversion business rules must be defined.

During this phase, conversion test plans are developed. A manual


conversion plan needs to be constructed if manual data conversions will
be employed.

Documentation
Prototypes developed during Solution Design depict documentation
design, format and content. They are created for user review and
approval before formal documentation begins. Usually documentation
prototypes are required for:

• User Reference Manual


• User Guide
• Technical Reference Manual
• Systems Management Guide

Business System Testing


The Testing Strategy describes the high-level direction and guidelines
for testing all components of the application system. This includes
outlining the overall approach to the testing process, coordinating the
development and execution of test scripts, scheduling adequate and
appropriate testing resources, configuring testing environments and
tools, and problem management. The Testing Strategy is a working
document that can be referenced throughout all tasks in the testing
process.

Based on the characteristics of the system to be built, specific testing


activities may vary in importance. Specific considerations include the
number of custom modules, availability and reliability of converted
data, system performance, number of system interfaces, the scope of

Oracle Method Solution Design 4 - 25


testing, testing standards, the types of testing, and the significance of
the system to the business.

The key focus is developing test scripts for unit, link, system, and
systems integration testing. In general, test scripts include test steps
and test data profiles. Unit tests usually include checklists, while
systems and systems integration tests include test sequences.

The testing process emphasizes re-using test script components


wherever possible to avoid duplication of effort. For example, when
developing the components of the system test scripts, it is important to
build on the mapping scenarios and data profiles that were previously
developed as well as the link test scripts that are related to the business
functionality that is being tested. Each level of testing builds on the
previous level, testing materials are re-used, and business processes are
tested in successively larger and larger pieces.

Performance Testing
After the team arrives at feasible models for performance testing, the
technical analysts will design the database and test programs needed to
create the test transactions. The technical analysts decompose the
transaction models into test scripts that specify the individual
transactions and events to be created during the test. If performance
testing is using an automated load testing tool, the technical analysts
will create programs to manage the specific transactions and test user
simulation. If not, there may be little or no design of special
performance test transaction programs and the majority of the work in
Solution Design will be focused on the test database design.

One of the critical success factors for this process is the inclusion of
testing against a volume test database. Performance Testing is
potentially the only area where testing of the system against a
significant volume of data occurs. Unfortunately, the bulk loading of
data to create a database that is “industrial-sized” can be time
consuming. There may be opportunities to leverage other work in the
project to alleviate this task (for example, by reusing the programs
created by the data conversion process). If the project has good quality
application data already set up, copy another database to provide the
setup data to bulk load transaction data.

Training
Training courseware is created during Solution Design using the User
Guide, User Reference Manual, and System Management Guide as the
basis for the content. The classes should be role-based and provide

4 - 26 Solution Design AIM Method Handbook


users with a thorough introduction to their new responsibilities and
procedures.

Production Migration
Define production support infrastructure by identifying and
documenting the support requirements for application, database, and
network administration. Review the external software and hardware
providers’ support programs and existing internal support procedures.
Map the requirements to the support programs, and develop
procedures to meet any requirements in areas that are not already
covered. Create and document a method for identifying and
categorizing internal and external support problems. Finally, develop a
training plan to communicate the support procedures to both IS
personnel and users.

Develop a detailed transition and contingency plan that includes a


series of tasks or checklists to assist project management and users in
preparing for and executing the transition to production. The general
checklist tasks facilitate planning and estimating Transition. The
specific checklist tasks provide guidance in executing Transition.

The contingency plan outlines alternatives that may be implemented if


the cutover to production is unsuccessful. It discusses the
circumstances that require the execution of a contingency plan and lists
the implementation steps. It also identifies a migration step to re-
transition to the new system once problems are corrected.

Oracle Method Solution Design 4 - 27


Estimating
The following table indicates the typical percentage of effort required by
each task by role.

Applications Administrator

Business Line Manager

Database Administrator
Client Project Manager

Configuration Manager
Applications Architect

Applications Expert

Database Designer

IS Operations Staff
Business Analyst
Phase Effort

IS Manager
Facilitator
Analyst
S o lu tio n D e s ig n
ID T a sk
B u s in e s s R e q u ire m e n ts M a p p in g 4 .7 %
C .B R .1 0 0 C re a te P ro c e s s N a rra tiv e s 3 .1 % 95 0
C .B R .1 1 0 D e fin e A p p li c a tio n S e tu p s 1 .5 % 80
C .B R .1 2 0 D e sig n S e c u rity P ro file s 0 .1 % 80
A p p lic a tio n & T e c h n ic a l A r c h ite c tu r e 5 .2 %
C .T A .1 2 0 D e sig n A p p li c a tio n S e c u rity A rc h ite c tu re 0 .2 % 60 30
C .T A .1 3 0 D e sig n A p p li c a tio n F u n c tio n a l A rc h ite c tu re 0 .2 % 60 40
C .T A .1 4 0 D e sig n L o g ic a l A p p lic a tio n a n d D a ta b a se A rc h ite c tu re 0 .3 % 40 10 10
C .T A .1 5 0 D e sig n P h y sic a l D a ta b a se A rc h i te c tu re 1 .1 % 80 0
C .T A .1 6 0 D e sig n H a rd w a re a n d N e tw o rk A rc h ite c tu re 0 .8 % 10 0 0
C .T A .1 7 0 D e v e lo p S y ste m C a p a c ity P la n 1 .0 % 20 0 0
C .T A .1 8 0 A sse ss P e rf o rm a n c e R isk s 0 .5 % 25 0
C .T A .1 9 0 D e sig n S ys te m M a n a g e m e n t P ro c e d u re s 1 .1 % 10 20 0 0
M o d u le D e s ig n & B u ild 2 1 .2 %
C .M D .0 3 0 D e fin e D e s ig n S ta n d a rd s 0 .3 %
C .M D .0 4 0 D e fin e B u ild S ta n d a rd s 0 .3 %
C .M D .0 5 0 D e sig n D a ta b a se E x te n s io n s 0 .4 % 60
C .M D .0 6 0 P ro d u c e M o d u le F u n c tio n a l D e sig n 6 .1 % 20
C .M D .0 7 0 P ro d u c e M o d u le T e c h n ic a l D e sig n 1 2 .0 %
C .M D .0 8 0 R e v ie w D e ta ile d D e si g n s 2 .2 % 30 0
D a ta C o n v e rs io n 2 0 .2 %
C .C V .0 4 0 P re p a re C o n v e rsio n E n v iro n m e n t 0 .9 % 20
C .C V .0 5 0 P e rf o rm C o n v e rsi o n D a ta M a p p i n g (M a p C o n v e rsi o n D a ta ) 1 1 .3 %
C .C V .0 6 0 D e sig n M a n u a l C o n v e rsio n S tra te g y 0 .8 % 0
C .C V .0 7 0 D e sig n C o n v e rsio n P ro g ra m s 4 .8 %
C .C V .0 8 0 P re p a re C o n v e rsio n T e st P ro c e d u re s 2 .4 %
D o c u m e n ta tio n 1 4 .1 %
C .D O .0 6 0 P ro d u c e In itia l U s e r R e f e re n c e M a n u a l 6 .5 %
C .D O .0 7 0 P ro d u c e In itia l U s e r G u i d e 5 .2 % 20
C .D O .0 8 0 P ro d u c e In itia l T e c h n ic a l R e fe re n c e M a n u a l 1 .9 %
C .D O .0 9 0 P ro d u c e In itia l S y ste m M a n a g e m e n t G u id e 0 .5 %
B u s in e s s S y s te m T e s tin g 8 .9 %
C .T E .0 1 0 D e v e lo p T e st S ta te g y 0 .3 %
C .T E .0 2 0 D e v e lo p U n it T e st S c rip ts 1 .2 %
C .T E .0 3 0 D e v e lo p L i n k T e s t S c rip ts 3 .0 %
C .T E .0 4 0 D e v e lo p S y ste m T e s t S c rip ts 3 .5 % 60
C .T E .0 5 0 D e v e lo p S y ste m s In te g ra tio n T e s t S c rip ts 0 .9 % 20
P e r fo r m a n c e T e s tin g 3 .9 %
C .P T .0 5 0 C re a te P e rfo rm a n c e T e st S c rip ts 1 .3 % 30
C .P T .0 6 0 D e sig n P e rfo rm a n c e T e st T ra n sa c tio n P ro g ra m s 1 .9 %
C .P T .0 8 0 D e sig n P e rf o rm a n c e T e s t D a ta 0 .2 % 30
C .P T .0 9 0 D e sig n T e s t D a ta b a s e L o a d P ro g ra m s 0 .5 % 10
T r a in in g 6 .2 %
C .T R .0 7 0 D e v e lo p U s e r T ra in in g M a te ria l s 6 .2 % 45 0
P ro d u c tio n M ig ra tio n 2 .3 %
C .P M .0 2 0 D e sig n P ro d u c tio n S u p p o rt In f ra stru c tu re 0 .8 % 0 0
C .P M .0 3 0 D e v e lo p D e ta ile d T ra n sitio n & C o n ti n g e n c y P la n 1 .5 % 0 0 0 0
P ro je c t M a n a g e m e n t 1 3 .2 %
P JM M an ag e Ph ase 1 3 .2 %
CO NT C o n tin g e n c y 0 .0 %
1 0 0 .0 %

Table 4-6 Solution Design Phase Estimating

4 - 28 Solution Design AIM Method Handbook


0
0
0
IS Support Staff

Lead Tester

20
10 0
Module Designer

60
60
10
80
20
20
10
10
90
30
90
80
40
Network Adminstrator

20
10
10
Production Database Administrator

Oracle Method
Programmer

20
80
30
10
Project Database Administrator

30
Project Manager

75
0
Project Sponsor

Quality Auditor

Systems Administrator

20
40
40
20
35
10
10

System Architect

Team Leader-Architecture

25
Team Leader - BR

Table 4-6
Team Leader-Conversion

10
10
10
10
10
10
Team Leader-Customization

10
10
10
Team Leader - Documentation
5

Team Leader-Mapping
10
10

Team Leader-Performance Testing

10
20
20
10
Team Leader - Testing

5
Team Leader-Training

15
Technical Analyst

20
50
20
60
90
90
90
10
10

Technical Architect
10
50
50
45
20
30

Technical Expert

10 0
Technical Expert - Build
90

Technical Expert - Design


90

Technical Expert - Environment

Technical Expert - Existing Systems

Technical Writer

25
80
80
70
90

Tester

60
30
Trainer

25

Solution Design Phase Estimating (cont.)


0
0
0

User

10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0
10 0

Solution Design 4 - 29
Scheduling

The critical roles during Solution Design are the business analyst,
module designer, and technical analyst . By assigning additional
qualified individuals to perform these roles, you can shorten the critical
path.

Scheduling Suggestions
Scheduling suggestions for Solution Design follow:

Project Management
Project management review and sign-off meetings critical to Solution
Design should be reflected in the schedule.

Consistently applying the policies, procedures, standards, guidelines,


and tools provided to solution designers can have a positive impact on
the timeline. For example:

• Use an effective test database instance with sufficient test data to


explore different solution scenarios.
• Use design walkthroughs to identify integration problems that
could be time consuming if discovered during testing.
• Require unit test plans.
• Control design changes.

The information flow between the designers and other team members is
important; however, be sure to limit unnecessary interruptions.
Consider assigning designers to a physical location that is out of the
mainstream.

In addition to application customizations, solution designs for data


conversion, interfaces, technical architecture, performance testing, and
user training are produced during this phase. Emphasis on
customizations may detract from the importance of addressing these
other development areas. Thorough planning and tracking can prevent
schedule slippage due to last minute training material development or
an interface that was overlooked.

If a phased deployment approach will be used you may have both


legacy and new systems in production simultaneously. How will
consolidated reporting and queries be addressed? You may need

4 - 30 Solution Design AIM Method Handbook


temporary bridge systems to pass transactions from one system to the
other so that both the new and legacy system can access all data.

Issue management can have a major impact on the Solution Design


schedule. Emphasize the importance of identifying, documenting,
investigating, and resolving issues in a timely manner.

Module Design and Build


The primary scheduling factors associated with Module Design and
Build are:

• the number of available and qualified team members


• the availability of an appropriate work environment
• the accuracy and completeness of the information developed in
previous phases
• the extent to which tasks can be conducted in parallel

Data Conversion
Allow for changes to the conversion modules caused by the discovery
of new requirements during the performance of Module Design and
Build tasks.

Documentation
The time needed to develop documentation is frequently
underestimated. Consider using professionals (for example, technical
writers) to improve productivity.

The primary factors influencing schedule are the scope of the document
to be produced and the productivity of the team.

Business Systems Testing


Business System Testing requires carefully documented test scenarios
that include expected results. To adequately test a complex system you
need sufficient data to exercise application functionality. Inadequate
preparation can create the impression that the system has problems,
when in reality the testing process is at fault.

Performance Testing
Consult performance testing specialists to conduct practical
performance tests. There may be ways to ensure your system will be

Oracle Method Solution Design 4 - 31


able to handle the anticipated production load. For example, many
hardware vendors, in conjunction with Oracle, provide performance
testing services.

Performance testing may be complicated by multi-phase/multi-site


deployment approaches, resulting in a longer time requirement.

Training
Training approaches may impact the schedule, for example:

• Will standard Oracle training, custom training, or a combination


be used?
• Will internal or external instructors be used?
• Will internal instructors need specialized training on how to teach
the class?
• Will classes be conducted at multi-sites simultaneously? If so,
separate database instances may be needed for each site so
students can do the exercises.
• What is an acceptable class size? Multiple sessions of some
classes may be required to accommodate students.

Unless you use experienced curriculum developers, it is easy to


underestimate the resources and time required to develop custom
training materials.

In many cases, changes in user policies and procedures accompany an


applications implementation. Be sure that users are trained in system
functions, company policies, and job procedures.

Production Migration
Detailed plans are required for the production application setup, data
conversion, systems administration, and data administration tasks. It is
easy to underestimate the time required for this process.

For example, there are critical interdependencies for setup data and
data conversion steps among the Oracle Applications such as:

• Employees must be set up before you can enter project managers


into Project Accounting or Buyers into Purchasing.

4 - 32 Solution Design AIM Method Handbook


• Fixed Asset Categories must be entered before assets can be
converted, and key fixed asset account numbers must be in the
Chart of Accounts before the categories can be entered.

Operating system and Applications logons and passwords must be


established. Project team responsibilities must also be determined and
communicated to all users prior to production.

Oracle Method Solution Design 4 - 33


Staffing

This diagram illustrates a typical project organization for Solution


Design.

Solution Design Phase Organization

Project Management

Project Management Administrative Assistant/


Support Team Project Librarian

Business Function Custom Software Design


Specialists & Build

Business Function Team Leader


(A)

Functional Lead Team Members

Functional Analysts

Business Function
(B)

Functional Lead

Functional Analysts

Business Process
Integration

Technical Architecture & Data Conversion


Performance Testing

Team Lead Team Lead

Team Members Team Members

Training & Transition


Documentation

Team Lead

Team Members

Oracle Applications
Specialists

Figure 4-3 Staffing Chart for Solution Design

4 - 34 Solution Design AIM Method Handbook


Staffing Suggestions
This section provides advice and comments on project organization for
Solution Design.

Project Management
During Solution Design the primary staffing factor is the transition to a
more technical team; the functional requirements should be complete.
Your primary focus is addressing gaps between the organization’s
needs and the standard applications. This requires knowledge of the
standard application’s functionality and technical architecture in order
to design effective solutions.

In multi-phase/multi-site projects there may be impacts on the design of


training classes, technical architecture, interface modules, application
extensions, and data conversion custom software modules.

Business Requirements Mapping


Although staffing continuity maintains the project productivity level,
budget considerations may require that some team members be phased
out when their tasks are completed. Be sure that sufficient
documentation is transferred to the project before team members are
released from their responsibilities.

For multi-phase/multi-site deployments, try to select staff who have


experience with this approach. Experienced staff may identify key
requirements that otherwise might be missed.

Application and Technical Architecture


Participation by skilled technical architects is critical. The Information
Systems department may be reluctant to use external technical
architects if they believe their group expertise is sufficient. Whether the
technical architect is an employee or consultant is less important than
the qualifications they bring to the process. Verifying that the technical
architecture will support the future system load is a critical component
of a successful project.

Module Design and Build


Experienced staff should develop the functional design specifications.
Technical specifications may be developed by less experienced staff and
reviewed by functional design developers.

Oracle Method Solution Design 4 - 35


A good development lead on a medium to large project can manage the
schedule and provide technical leadership. On a small project the
project manager might perform this role. The development lead is
responsible for the creation of custom extensions, an expensive
corporate asset. Using a structured, systematic development approach
that emphasizes quality control is essential.

If multiple deployment phases are used, additional customizations may


be requested or required for each deployment. Determine if additional
interface development and data conversion tasks will be needed by a
specific deployment.

Data Conversion
To design data conversion solutions, both technical and functional
expertise and a good understanding of application integration data
considerations are needed.

Business System Testing


Business System Testing requires careful planning to thoroughly and
efficiently test the system.

If a phased deployment to different parts of your organization will


occur, determine the testing requirements that must be satisfied for each
user community. Their approval of the system is closely tied to the
Business System Testing results. Extensive or complicated testing may
require additional staff.

Performance Testing
Performance testing usually requires specialists. Hardware vendors
may provide performance testing services at their own sites. You may
be able to leverage their staff and facilities.

If you deploy in multiple phases, your system load will increase over
time. This potentially complicates performance testing but allows a cost
savings by phasing in additional computer and network capacity as
necessary.

Training
Training impacts the ongoing success of the implementation. Users
who understand the new system functionality will benefit from its
features. If you are choosing to create a custom course, select

4 - 36 Solution Design AIM Method Handbook


courseware developers who understand your need for a detailed class
covering the features and functions for each user role.

For multi-phase deployments, you may need to repeat user training for
each deployment. Do not assume the same instructors will be available
for each deployment. If deployments will occur every few months,
training should be packaged so it can be repeated at each site.

Production Migration
The complexity and importance of Production Migration requires
experienced staff during the planning stage. For multiple deployments
many production migration tasks will be repeated for each deployment.
It may be impractical for the same people to perform these tasks for
each deployment.

Oracle Method Solution Design 4 - 37


CHAPTER

5 Build

T his chapter describes the Build phase of AIM. The goal of Build is to
develop the solution designed during Solution Design.

Definition Operations Solution Build Transition Production


Analysis Design

Business Requirements Definition

Business Requirements Mapping

Application and Technical Architecture

Module Design and Build

Data Conversion

Documentation

Business System Testing

Performance Testing

Training

Production Migration

Figure 5-1 Context of AIM Build Phase

Oracle Method Build 5 - 1


Overview
This section provides an overview of Build.

Objectives

The objectives of Build follow:

• Prepare the development environment.


• Develop, test, and accept custom software including:
– application customizations
– 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
• Create, test, and accept database extension and installation
routines.
• Develop and accept all documentation deliverables including:
– User Reference Manual
– User Guide
– Technical Reference Manual
– Systems Management Guide
– Online help text
• Develop performance test components, execute performance
tests, and prepare a report.

Critical Success Factors

The critical success factors of Build follow:

5 - 2 Build AIM Method Handbook


• clear understanding of the business objectives being addressed by
the project
• effective participation by executive and user management
• sufficient time and resources
• accurate and complete design documentation
• a productive Build environment
• effective project management
• a productive team with appropriate skills

Overview Table

This table illustrates the prerequisites, processes, and key deliverables


for Build.

Process Prerequisites Key Deliverables

Module Design and Build Application Setup Document Custom Database Objects

Approve Designs Develop Environment

Build Standards Installation Routines

Database Extension Design Module Source Code

Link Test Scripts

Module Functional Design

Module Technical Design

Physical Resource Plan

Unit Test Scripts

Oracle Method Build 5 - 3


Process Prerequisites Key Deliverables

Data Conversion Conversion Data Mapping Business Object Tested Conversion


Programs
Conversion Environment
Conversion Programs
Conversion Program Design
Unit Tested Conversion Programs
Conversion Testing Plans
Validation Tested Conversion
Current Business Baseline Programs

Detailed Transition and


Contingency Plan

Documentation Design Standards Online Help Text

Document Prototypes and System Management Guide


Templates
Technical Reference Manual
Document Standards and
Procedures User Guide

Documentation Requirements User Reference Manual

Initial System Management Guide

Initial Technical Reference Manual

Initial User Guide

Initial User Reference Manual

5 - 4 Build AIM Method Handbook


Process Prerequisites Key Deliverables

Business System Testing Business Requirements Scenario Integration Test Systems

Process Narrative Link Test Modules

Production Support Infrastructure Performance Test Results

System Test Scripts Prepared Users

Systems Integrated Test Scripts System Test Applications

Testing Strategy Testing Environments

Test Install Routines

Unit Test Modules

Performance Testing Perform Test Data Design Performance Tested Database

Perform Test Transactions Models Performance Tested Environment

Perform Testing Strategy Performance Tested Report

Test Database Load Program Tested Database Load Programs


Designs
Tested Transaction Programs
Test Transaction Program Designs

Table 5-1 Build Phase Overview Table

Prerequisites

Prerequisites for Build follow. You should use these prerequisites, if


they exist, prior to beginning this phase. Otherwise, you may need to
create them during Build.

Prerequisite Source

Application Function Architecture Application and Technical


Architecture

Oracle Method Build 5 - 5


Prerequisite Source

Application Security Architecture Application and Technical


Architecture

Application Setup Document Business Requirements


Mapping

Approve Designs Module Design and Build

Build Standards Module Design and Build

Business Requirements Scenarios Business Requirements


Definition

Conversion Environment Data Conversion

Conversion Program Design Data Conversion

Conversion Testing Plans Data Conversion

Conversion Test Procedures Data Conversion

Conversion Data Mapping Data Conversion

Current Business Baseline Business Requirements


Definition

Database Extension Designs Module Design and Build

Design Standards Module Design and Build

Detailed Transition and Contingency Production Migration


Plan

Documentation Prototypes and Documentation


Templates

Documentation Standards and Documentation


Procedures

Documentation Requirements Documentation

5 - 6 Build AIM Method Handbook


Prerequisite Source

Hardware and Network Architecture Application and Technical


Architecture

Initial System Management Guide Documentation

Initial Technical Reference Manual Documentation

Initial User Guide Documentation

Initial User Reference Manual Documentation

Link Test Scripts Business System Testing

Logical Application and Database Application and Technical


Architecture Architecture

Module Function Designs Module Design and Build

Module Technical Designs Module Design and Build

Performance Risk Assessment Application and Technical


Architecture

Performance Test Data Designs Performance Testing

Performance Test Scripts Performance Testing

Performance Test Transaction Performance Testing


Models

Performance Test Strategy Performance Testing

Physical Database Architecture Application and Technical


Architecture

Physical Resource Plan Project Management

Process Narratives Business Requirements


Definition

Production Support Infrastructure Production Migration

Oracle Method Build 5 - 7


Prerequisite Source

Security Profiles Business Requirements


Definition

System Capacity Plan Application and Technical


Architecture

System Testing Scripts Business System Testing

Systems Integrated Test Scripts Business System Testing

Test Database Load Program Design Performance Testing

Test Transaction Program Design Performance Testing

Test Strategy Business System Testing

Unit Test Scripts Business System Testing

Table 5-2 Build Phase Prerequisites

Processes

The processes used in this phase follow:

Model Design and Build


Develop custom application extensions, interface programs, and custom
application subsystems to be integrated with Oracle Applications.

Data Conversion
Develop and test the conversion programs and perform conversion
business object and validation testing.

Documentation
Complete final updates to the documentation and prepare for transfer
of ownership to the user community. Create and install the online help
text.

5 - 8 Build AIM Method Handbook


Business System Testing
Prepare testing environment and perform testing tasks for the custom
extensions and total business solution. This includes the execution of
the test scripts, documentation and analysis of test results, and the
problem management process whereby identified errors are resolved
and re-tested.

Performance Testing
Develop the special database load and transaction programs, construct
the test database, create the test environment, and execute the
performance tests. Document the testing process and results in the final
performance test report.

Key Deliverables

The key deliverables of this phase follow:

Deliverable Description

Business Object Tested A record of information about the


Conversion Programs conversion programs that have been
tested.

Conversion Programs Conversion code needed for data


conversion.

Custom Database Objects New tables, indexes, views,


sequences, grants, and synonyms
required to support the custom
extensions. A component of this
deliverable is scripts to create the
new database objects in the
production environment.

Development Environment The environment to support custom


software development.

Oracle Method Build 5 - 9


Deliverable Description

Installation Routines Operating system shell scripts, SQL*


Loader, or terminal keystroke files to
install and configure custom
extensions in the production
environment. This may also include
documented manual procedures for
online setup that cannot be easily
scripted.

Integration Tested System A set of systems whose interfaces


have been tested.

Link Tested Modules Tested modules that interact with


each other.

Module Source Code Forms, Reports, SQL, PL/SQL, C and


other code for the new modules. For
non-coded modules such as
Flexfields and Alerts, this represents
the online implementation of these
solutions.

Online Help Text Online user reference (full-screen text


with suggestions regarding system
usage and error messages).

Performance Test Database The database(s) to be used for


executing the performance tests. It
should have a significantly greater
volume of data than is usual for
business system test databases. In
general, it will include both
application setup data and
transaction data. Depending on the
circumstances and timing of the
project, the database may be sparsely
populated, but will have all the data
needed to allow the test transaction
programs to execute flawlessly.

5 - 10 Build AIM Method Handbook


Deliverable Description

Performance Test A fully configured performance test


Environment is executed. The environment
includes hardware, networks, test
database(s), automated test execution
tools, and monitoring tools. All steps
should have been taken to allow the
performance test team to connect to
the system and start the execution of
the performance tests.

Performance Test Report Report summarizing the performance


test including the test approach, the
test models, test hardware and
software configuration, test results,
and conclusions.

Performance Test Results Performance test measurements.

Prepared Users Users trained in specific standard


and custom applications
functionality.

Regression Tested Execution Modules that have been tested to


Modules ensure defects have been corrected.

System Management Guide Procedures for managing the


application (for example, backup,
recovery, audit, security).

System Tested Applications Applications that have been system


tested.

Technical Reference Manual A manual providing technical


information for use during
application maintenance.

Test Database Load Coded and tested data load


Programs programs that will be used to
populate the performance test
database.

Oracle Method Build 5 - 11


Deliverable Description

Test Transaction Programs Coded and tested transaction


programs that will be used to execute
the performance test.

Tested Conversion Programs Data conversion programs that have


been tested.

Tested Installation Routines Validated installation routines for


custom modules.

Testing Environments The environment to be used for


testing custom software.

Unit Tested Modules Custom software modules that have


been tested.

User Guide Procedures needed to respond to all


supported business events using
standard and customized software.

User Reference Manual Manual to provide information to


users about system use during
production.

Valid Tested Conversion Data conversion programs that have


Programs been tested and accepted.

Table 5-3 Build Phase Key Deliverables

5 - 12 Build AIM Method Handbook


Approach
This section describes the approach for Build.

Tasks and Deliverables

This table lists the tasks executed and the deliverables produced during
Build.

ID Task Deliverable

Module Design and Build


MD.090 Prepare Development Environment Development Environment
MD.100 Implement Database Extensions Custom Database Objects
MD.110 Create Custom Modules Module Source Code
MD.120 Create Installation Routines Installation Routines
Data Conversion
CV.090 Develop Conversion Programs Conversion Programs
CV.100 Perform Conversion Unit Test Unit Tested Conversion Programs
CV.110 Perform Conversion Business Object Test Business Object Tested Conversion
Programs
CV.120 Perform Conversion Validation Test Validation Tested Conversion
Programs
Documentation
DO.100 Complete User Reference Manual User Reference Manual
DO.110 Complete User Guide User Guide
DO.120 Complete Technical Reference Manual Technical Reference Manual
DO.130 Complete System Management Guide System Management Guide
DO.140 Provide Online Help Text On-line Help Text
Business System Testing
TE.060 Prepare Testing Environments Testing Environments
TE.070 Perform Unit Test Unit Tested Modules
TE.080 Perform Link Tests Link Tested Modules
TE.090 Perform Installation Test Tested Installation Routines
TE.100 Prepare Key Users for Testing Prepared Users
TE.110 Perform System Testing System Tested Applications
TE.120 Perform Regression Testing Regression Tested Custom Modules

Oracle Method Build 5 - 13


ID Task Deliverable

TE.130 Perform Systems Integration Testing Integration Tested System


Performance Testing
PT.070 Develop Performance Test Transaction Test Transaction Programs
Programs
PT.100 Develop Test Database Load Programs Test Database Load Program Designs
PT.110 Construct Performance Test Database Performance Test Database
PT.120 Prepare Performance Test Environment Performance Test Environment
PT.130 Execute Performance Test Performance Test Results
PT.140 Create Performance Test Report Performance Test Report
Table 5-4 Build Phase Tasks and Deliverables

5 - 14 Build AIM Method Handbook


This page intentionally left blank.

Oracle Method Build 5 - 15


Task Dependencies

This diagram shows the dependencies between tasks in Build.

Build
CV.090 CV.100 CV.110
Perform CV.120
Develop Perform Conversion Perform
Conversion Conversion Unit Business Object Conversion
DATA Programs Test Test Validation Test
CONVERSION CV.090 CV.100 CV.110 CV.120

MD.090 MD.100 MD.110


M ODULE DESIGN Prepare Implement
Create Custom
AND BUILD Development Database
Modules
Environment Extensions
MD.110
MD.090 MD.100

DO.100
Complete User
Reference
DO.100
DOCUMENTATION
DO.110
Complete User
Guide
DO.110

TE.060 TE.070
Prepare Testing
Perform Unit Test
Environments
TE.070
TE.060

BUSINESS SYSTEM
TESTING
TE.080

Perform Link Test


TE.080

PT.070
Develop
Performance Test
Transaction
Programs
PERFORMANCE PT.070
TESTING PT.110 PT.100
Develop
Construct
Performance Test
Database Load Performance Test
Database
Program
PT.100
PT.110

Figure 5-2 Build Phase Task Dependencies

5 - 16 Build AIM Method Handbook


Build

DATA
CONVERSION

MD.120
MODULE DESIGN
Create Installation
Routines AND BUILD
MD.120

DO.140 DO.120
Complete
Provide Online
Technical
Help Text
Reference
DO.140 DO.120 DOCUMENTATION
DO.130
Complete System
Management
Guide
DO.130

TE.100 TE.130
Prepare Key Users Perform
for Testing Installation Test
TE.100 TE.130

BUSINESS SYSTEM
TESTING
TE.110 TE.130 TE.120
Perform System Perform Systems Perform
Test Integration Test Regression Test
TE.110 TE.130 TE.120

PERFORMANCE
TESTING
PT.120 PT.130 PT.140
Prepare Create
Execute
Performance Test Performance Test
Performance Test
Environment Report
PT.130
PT.120 PT.140

Figure 5-2 Build Phase Task Dependencies (cont.)

Oracle Method Build 5 - 17


Managing Risks

The areas of risk and mitigation for Build include the following:

Risk Mitigation

Inadequate testing of Begin test measurement executions


performance test transaction after performance test transaction
programs against the programs have been tested and
performance test database approved.
prior to starting test
measurement executions.

New hardware or disk Consider hardware or disk purchase


purchases do not arrive in lead times in scheduling the
time for the performance test performance testing.
environment preparation.

Underestimating time Realistically assess development time


needed to build and debug for a volume test database and/or
automated performance test automated testing tool transaction
tool programs as well as the programs and discuss development
test database. metrics with testing tool vendor.

Inadequately tested custom Perform rigorous unit and link tests


code that interferes with of custom modules.
effective system testing.

Ineffective conversion The conversion programmers verify


programs due to insufficient that the level of detail provided in the
conversion designs. Conversion Design is adequate.

Inadequate training of testers Train staff who will conduct


for conversion business conversion object tests on the
object and validation tests. functionality of the target
applications and testing procedures.

Insufficient test data. Ensure that sufficient time and


resources are provided for test data
development.

5 - 18 Build AIM Method Handbook


Risk Mitigation

Incomplete Business System Business Systems Test and Systems


and Systems Integration Integration Test scripts should be
Tests. executed and documented by
personnel who understand the
business processes and interfaces that
are being tested.

Inadequate testing Separate testing environments should


environment affecting control be configured to support each type of
over testing data and testing, if possible. At minimum, a
processes as well as the given testing environment can be
validity of test results. managed to support multiple types of
testing, but should not be used for
other non testing-related project
activities.

Fewer resources than needed Ensure that sufficient resources are


to execute system and planned for testing.
systems integration test
scripts and document test
results.

Inadequate defect The defect management process


management resulting in should be established in the Testing
defects that are identified but Strategy document, implemented
not resolved in a controlled, prior to custom development, and
reliable manner. describe the step-by-step process to
be followed in identifying, correcting,
and re-testing a defect.

Table 5-5 Risk Management Table for Build

Oracle Method Build 5 - 19


Tips and Techniques

This section provides tips and techniques for managing Build. In


addition, advice and comments on each process are included.

Module Design and Build


Module Design and Build and Business System Testing are two distinct
processes in AIM, but must be treated as a coordinated set of activities
to ensure success. In particular, Develop Custom Modules is tightly
integrated with Perform Unit Test and Perform Link Tests in Business
System Testing. Programmers and testers repeat these three tasks for
each custom module and related sets of custom modules until all
custom extensions are ready for the business system test.

The movement of custom modules and database extensions from the


development, unit, and link test environments to the business system
test environment must be carefully executed to ensure that all
components function properly. This can be a major issue when
customizations consist of a combination of different module types that
have different migration procedures. Some can be automated with
scripts while other steps must be completed by entering parameters
manually in Application Object Library forms. The Business System
Testing Strategy describes the number of testing environments and the
Build Standards define the migration procedures.

Data Conversion
During Build, the conversion programs are developed. If an automated
tool has been selected it may be used to build conversion templates that
map the legacy data to the Oracle Application tables and then load the
legacy data into the Oracle tables.

The conversion programs should be unit tested during this phase to


ensure that they function as intended. Once legacy data is loaded into
the Oracle Application, the integrity of the data should be tested within
each Oracle application. In addition, a conversion validation test should
be executed to test the performance of the legacy data within the entire
suite of installed Oracle Applications.

Documentation
Documentation should be continually updated as the applications and
extensions are being tested and revised. When the User Guide and User

5 - 20 Build AIM Method Handbook


Reference Manual are completed, the online help text can be developed
and installed. After the implementation is complete and the project
team disbanded, the documentation will be a major resource for every
area using the new system.

Business System Testing


Creating the testing environments needed to support each type of
testing can be done in the beginning of the phase, or each environment
can be created as needed during the testing process. The Testing
Strategy lists the number and type of environments needed to support
the testing tasks, including unit, link, system, systems integration,
regression, and acceptance testing.

You may choose to perform multiple types of testing in a single testing


environment. However, it is not recommended that testing be
performed in an environment that is concurrently supporting other
project activities such as training or conversion testing. This practice
can cause corruption of test data or programs, inaccurate test results,
and frustration for testers and the other users of the shared
environment.

The emphasis during Build involves testing each custom module as it


moves through development (unit and link testing) and testing the
applications and their integration with external systems (system testing
and systems integration testing).

For each type of testing it is preferable that test scripts be executed more
than once for each testing target (module, linked modules, business
process, integrated system). In the case of unit and link testing,
developers generally test each other’s code in an iterative process until
the module or linked module is ready for system testing.

System testing and system integration testing should reflect actual


business flows and be executed in cycles. Each test specification is
tested multiple times with different data profiles, within the context of
different occurrences of each business transaction.

Performance Testing
System and Database Administrators construct the performance test
environment during Build. This includes:

• preparing the hardware and network connections


• migrating the fully populated test database

Oracle Method Build 5 - 21


• migrating the special test transaction programs
• installing the applications
• installing performance monitoring tools

Administrators should perform as much environment testing as


possible before formally starting the test execution. The technical
analysts and administrators should also perform testing of the
transaction programs, the test scripts, and the test database in the test
environment.

The execution of a complex performance test rarely proceeds without


initial problems. Each iteration or test cycle may need to correct
problems in the environment found during a prior cycle or may test the
effects of a system re-tuning. There is a good deal of tuning and re-
tuning necessary during the execution of a large-scale, multiple
transaction performance test. To collect system measurements for a
particular set of test parameters or a test configuration may require
multiple cycles before the system and the test programs are tuned
properly to give realistic or useful results.

At the end of the formal performance test process, a performance test


report summarizes the work performed by the team during the process,
the results obtained, and conclusions and recommendations. The
creation of a formal report is optional and may not be necessary if the
performance test process is relatively limited in scale and is not making
strategic or critical project recommendations. The project manger
responsible for the performance test project will decide whether a
formal report is warranted.

At the end of the formal testing process, the programs and scripts may
be useful for performance regression testing in a continuing
performance quality management system. Before making changes to
the production technical configuration, or the applying of software
patches or upgrades, the business can use the performance test suite to
assess the performance impact of changes.

5 - 22 Build AIM Method Handbook


This page intentionally left blank.

Oracle Method Build 5 - 23


Estimating

The following table indicates the typical percentage of effort required by


each task by role.

Application Administrator

Business Line Manager

Database Administrator
Client Project Manager
Configuration Manager
Applications Architect

Applications Expert

Database Designer
Business Analyst
Phase Effort

IS Manager
Facilitator
Analyst
Build
ID Task
Module Design & Build 17.0%
D.MD.090 Prepare Development Environment 0.9% 15
D.MD.100 Implement Database Extensions 0.6% 20
D.MD.110 Create Custom Modules 14.2%
D.MD.120 Create Installation Routines 1.2%
Data Conversion 14.4%
D.CV.090 Develop Conversion Programs 5.0%
D.CV.100 Perform Conversion Unit Test 2.0%
D.CV.110 Perform Conversion Business Object Test 6.0%
D.CV.120 Perform Conversion Validation Test 1.5% 30
Documentation 5.8%
D.DO.100 Complete User Reference Manual 2.0%
D.DO.110 Complete User Guide 1.6%
D.DO.120 Complete Technical Reference Manual 0.6%
D.DO.130 Complete System Management Guide 0.2%
D.DO.140 Provide Online Help Text 1.4%
Business System Testing 32.1%
D.TE.060 Prepare Testing Environments 1.1% 20
D.TE.070 Perform Unit Testing 6.1%
D.TE.080 Perform Link Testing 7.9%
D.TE.090 Perform Installation Test 0.7%
D.TE.100 Prepare Key Users for Testing 0.7% 0
D.TE.110 Perform System Testing 9.8% 0
D.TE.120 Perform Regression Testing 2.5%
D.TE.130 Perform Systems Integration Testing 3.3%
Performance Testing 17.4%
D.PT.070 Develop Performance Test Transaction Programs 3.4% 5
D.PT.100 Develop Test Database Load Programs 1.6% 5
D.PT.110 Construct Performance Test Database 4.7%
D.PT.120 Prepare Performance Test Environment 2.6% 20 10
D.PT.130 Execute Performance Test 4.0% 20
D.PT.140 Create Performance Test Report 1.1% 5 10 0
Project Management 13.2%
PJM Manage Phase 13.2%
CONT Contingency 0.0%
100.0%

Table 5-6 Build Phase Estimating

5 - 24 Build AIM Method Handbook


0
IS Operations Staff

0
0
0
IS Support Staff

Lead Tester

10
10
10
75
10
Module Designer

10
10
10
10
20
10

Oracle Method
Network Adminstrator

10
10
10
Production Database Administrator

Programmer

85
85
20
20
20
20
20
50
40
10
90

100
100
100
Project Database Administrator

25
30
80
25
Project Manager

0
Project Sponsor

Quality Auditor

Systems Administrator

10
30
40
80
40
15
35

System Architect

Table 5-6
15
Team Leader - Architecture

Team Leader - BR

Team Leader-Conversion

10
10
Team Leader-Customization
10

Team Leader-Documentation

40
Team Leader - Mapping

5
5
Team Leader-Performance Testing

45
20
10
10
Team Leader-Testing

25
Team Leader - Training

Technical Analyst

20
20
15
70

Build Phase Estimating (cont.)


Technical Architect

Technical Expert

Technical Expert - Build

Technical Expert - Design

Technical Expert-Environment
15

Technical Expert - Existing Systems

Technical Writer
60
70
80
60
80

Tester
60
60
60
80
50
60
90

0 Trainer
0

User

Build 5 - 25
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
Scheduling

The critical roles during Build are that of the developer and the tester.
By assigning more programmers and testers, you may shorten the
critical path. Executing tasks on the critical path in parallel may
compress the timeline.

Scheduling Suggestions
Scheduling suggestions for Build follow:

Project Management
During multi-phase/multi-site deployment you may need to maintain
team development capability throughout the deployment phases.

Team size can affect the Build schedule. Maximize parallel activities by
having as large a team as possible, but avoid going beyond the size
where incremental administration and communication needs can
decrease productivity.

Module Design and Build


Make every effort to ensure the development environment is ready on
time. To be productive a development team needs:

• computer resources and workstations


• test database instance with sufficient test data
• design, coding, and testing standards and procedures
• various tools (for example, automated tools to facilitate
producing design documents)
• administrative procedures for issue resolution, registering
modules, getting deliverables approved, and obtaining answers
to questions

Data Conversion
For multi-phase/multi-site deployments, data conversions may be
scheduled at different times according to site requirements.

5 - 26 Build AIM Method Handbook


Business Systems Testing
For smaller projects with good user participation you may consider
combining System Testing and the Acceptance Test. Combining the two
tasks requires careful planning and extensive user participation but can
significantly reduce the timeline.

If you choose to combine the tests, the usual errors detected during
Systems Testing can be misinterpreted by users, resulting in a credibility
issue for project management.

Performance Testing
If Performance Testing needs to be repeated because previous test
results were inaccurate or insufficient computer resources have been
allocated, the schedule may change accordingly.

Oracle Method Build 5 - 27


Staffing

This diagram illustrates a typical project organization for Build.

Build Organization

Project Management

Project Management Administrative Assistant/


Support Team Project Librarian

Business Function Oracle Applications


Specialists Specialists

Custom Software Design Technical Architecture &


& Build Performance Testing

Team Lead Team Lead

Team Members Team Members

Data Conversion Training

Team Lead Team Lead

Team Members Team Members

Transition Documentation

Team Lead

Team Members

Testing

Team Lead

Team Members

Figure 5-3 Staffing Chart for Build

5 - 28 Build AIM Method Handbook


Staffing Suggestions
This section provides advice and comments on project organization for
Build.

Project Management
The most important staffing factor in Build is having a strong
development lead. This individual needs knowledge of Oracle
Applications technical architecture and the custom development tools to
be used. They must motivate developers to meet deadlines and to
follow project policies and procedures.

The development environment can have an impact on the morale and


productivity of developers. Custom software developers are very
dependent on their environment to perform fundamental tasks.

Fewer team members with functional skills will be required during


Build so some may be released from the team. At the same time,
developers may be added to enhance the technical staff.

Module Design and Build


Focus on the following key elements to help ensure a productive
development team:

• strong development lead


• productive work environment
• committed developers willing to follow project policies and
procedures
• planned knowledge transfer method during project team
personnel changes for multi-phase/multi-site projects
• effective issue management

Data Conversion
Using commercially available software can significantly affect the
development time during this phase and reduce staffing requirements.

If your data conversions will be audited, you should begin to assemble


the appropriate documents and statistics. If a phased conversion
approach is being used, the conversion process could span several site
deployments. The conversion of a given business object may need to be
repeated multiple times. Multi-phased conversion deployment will
have a significant impact on staffing requirements.

Oracle Method Build 5 - 29


Documentation
The documentation completed in this phase will impact the success of
the project after the system has gone into production. Staff this final
documentation effort with team members who have exceptional writing
skills and are detail oriented.

Business System Testing


The system test relies heavily on the participation of the user
community. Sufficient users must be available for the test and be
adequately trained in the new system functionality. Their approval of
the system test results determine if the project continues to the next
phase.

Performance Testing
The last Performance Testing steps analyze test results and develop
conclusions. The performance testing team can be deployed elsewhere
at this time unless follow up performance testing projects will be
undertaken.

5 - 30 Build AIM Method Handbook


CHAPTER

6 Transition

T his chapter describes the Transition phase of AIM. The goal of


Transition is to install the new application system, prepare client
personnel, establish the system administration function, and then cut
over to the new system.

Definition Operations Solution Build Transition Production


Analysis Design

Business Requirements Definition

Business Requirements Mapping

Application and Technical Architecture

Module Design and Build

Data Conversion

Documentation

Business System Testing

Performance Testing

Training

Production Migration

Figure 6-1 Context of AIM Transition Phase

Oracle Method Transition 6 - 1


Overview
This section provides an overview of Transition.

Objectives

The objectives of Transition follow:

• Install data conversion software.


• Convert and verify legacy data.
• Prepare personnel to support the system.
• Verify that the system meets all acceptance criteria.
• Begin to use the production system.
• Support acceptance testing.
• Train user personnel.
• Set up the applications.

Critical Success Factors

The critical success factors of Transition follow:

• clear understanding of the business objectives


• effective participation by business management
• sufficient time and resources
• sufficient technical and application architecture
• available and committed support staff to implement the new
solutions
• committed user involvement and ownership
• successful performance acceptance testing
• successful completion of production readiness plan
• effective training

6 - 2 Transition AIM Method Handbook


Overview Table

This table illustrates the prerequisites, processes, and key deliverables


for Transition.

Process Prerequisites Key Deliverables

Data Conversion Conversion Program Design Converted and Verified Data

Detailed Transaction and Installed Conversion Software


Contingency Plan

Conversion Environment

Performance Testing Results

Validation Tested Conversion


Programs

Training Application Setup Document Trained Users

Education and Training Plan User Training Environment

User Training Materials

Oracle Method Transition 6 - 3


Process Prerequisites Key Deliverables

Production Migration Hardware and Network Configured Applications


Architecture
Documented Support Procedures
Installation Routines
Production Environment
Integrated Tested Systems
Production System
Logical Application and
Database Architecture Production-Ready System

Online Help Text

Physical Database Architecture

Prepared Users

Production Support
Infrastructure

Security Profiles

System Management
Procedures

Technical Reference Manual

User Reference Manual

Business System Testing Acceptance Test Results

Table 6-1 Transition Phase Overview Table

6 - 4 Transition AIM Method Handbook


Prerequisites

Prerequisites for Transition follow. You should use these prerequisites,


if they exist, prior to beginning this phase. Otherwise, you may need to
create them during Transition.

Prerequisite Source

Acceptance Test Plan Client

Application Setup Document Business Requirements


Mapping

Conversion Environment Data Conversion

Validation Tested Conversion Data Conversion


Program Design

Detailed Transaction and Production Migration


Contingency Plan

Education and Training Plan Training

Hardware and Network Architecture Application and Technical


Architecture

Installation Routines Application and Technical


Architecture

Logic Application and Database Application and Technical


Architecture Architecture

Online Help Text Application and Technical


Architecture

Performance Testing Results Performance Testing

Physical Database Architecture Application and Technical


Architecture

Prepared Users Application and Technical


Architecture

Oracle Method Transition 6 - 5


Prerequisite Source

Production Support Infrastructure Production Migration

Security Profiles Business Requirements


Mapping

System Management Procedures Application and Technical


Architecture

Technical Reference Manual Documentation

User Reference Manual Documentation

User Training Materials Training

Validation Tested Conversion Data Conversion


Programs

Table 6-2 Transition Phase Prerequisites

Processes

The processes used in this phase follow:

Data Conversion
Install the data conversion software in the production environment,
convert the legacy data to the Oracle Applications, and verify data
accuracy.

Business System Testing


During Transition, this process can include creating and supporting the
testing environment, providing test scripts and testing support staff,
training testers on the system prior to testing, coordinating the
acceptance testing, and managing the issue resolution process.

Training
Train users and support staff in preparation for going live on the new
system.

6 - 6 Transition AIM Method Handbook


Production Migration
Prepare the production environment, including entering application
setups. Implement the support infrastructure, assess production
readiness, and execute production cutover.

Key Deliverables

The key deliverables of this phase follow:

Deliverable Description

Configured Applications Application ready for production


use.

Converted and Verified Data Converted data in the production


database that has been reviewed
and verified.

Documented Support Procedures for supporting the new


Procedures system in documentation form.

Installed Conversion Installed conversion software and


Software automated conversion tools used in
converting legacy data.

Production Environment Installed production environment


ready to receive final configured
applications.

Production Readiness Detailed production readiness


Checklist verification checklist.

Production Ready System New system ready to be installed in


the production environment.

Production System New system installed in the


production environment ready for
production use.

Trained Users Users who have attended user


training.

Oracle Method Transition 6 - 7


Deliverable Description

Configured Applications Application ready for production


use.

User Training Environment Environment to be used in training


users.

Table 6-3 Transition Phase Key Deliverables

6 - 8 Transition AIM Method Handbook


Approach
This section describes the approach for Transition.

Tasks and Deliverables

This table lists the tasks executed and the deliverables produced during
Transition.

ID Task Deliverable

Data Conversion
CV.130 Install Conversion Software Installed Conversion Software
CV.140 Convert and Verify Data Converted and Verified Data
Business Systems Testing
TE.140 Support Acceptance Test Acceptance Test Results
Training
TR.080 Prepare User Training Environment User Training Environment
TR.090 Train Users Trained Users
Production Migration
PM.040 Prepare Production Environment Production Environment
PM.050 Setup Applications Configured Applications
PM.060 Implement Support Infrastructure Documented Support Procedure
PM.070 Verify Production Readiness Production-Ready System
PM.080 Commence Production Production System
Table 6-4 Transition Phase Tasks and Deliverables

Oracle Method Transition 6 - 9


Task Dependencies

This diagram shows the dependencies between tasks in Transition.

Transition

CV.130 CV.140
DATA Install Conversion Convert and Verify
CONVERSION Software Data
CV.130 CV.140

BUSINESS SYSTEM
TESTING

TR.080 TR.090
Prepare User
TRAINING Training Train Users
Environment TR.090
TR.080

PM.060
Implement
PRODUCTION Support
Infrastructure
MIGRATION PM.060

PM.040 PM.050
Prepare
Production Setup Applications
Environment PM.050
PM.040

Figure 6-2 Transition Phase Task Dependencies

6 - 10 Transition AIM Method Handbook


Transition

DATA
CONVERSION

TE.140
Support BUSINESS SYSTEM
Acceptance Test TESTING
TE.140

TRAINING

PM.070 PM.080
Verify Production Commence
Readiness Production PRODUCTION
PM.070 PM.080 MIGRATION

Figure 6-2 Transition Phase Task Dependencies (cont.)

Oracle Method Transition 6 - 11


Managing Risks

The areas of risk and mitigation for Transition include the following:

Risk Mitigation

Malfunctioning or inefficient Design programs with performance


custom software. in mind and include custom
programs in Performance Testing.

Obtain formal and independent


quality signoff of all testing activities.

Inadequate production Verify in Build that the production


environment for conversion environment will be prepared in time
software. to install the conversion software.

Ensure that qualified and effective


staff review and approve
deliverables.

Users who are unprepared to use Establish a user certification or


the production system. readiness program that provides
incentives for system skill mastery,
and prevents system use by people
who have not demonstrated the
proper level of qualification.

Inadequate communication of Integrate support procedures into


support procedures to end users end-user training and system testing
prior to production cutover. processes.

Changes made to application Establish a procedure for migrating


setups in the testing environment changes to application setups into the
not documented in the production environment.
production setup documents or
implemented in the production
environment.

Table 6-5 Risk Management Table for Transition

6 - 12 Transition AIM Method Handbook


Tips and Techniques

This section provides tips and techniques for managing Transition. In


addition, advice and comments on each process are included.

Module Design and Build


If you have built custom extensions, you may need developers during
cutover to address any problems encountered with custom code.

Data Conversion
The conversion software should be installed in the production
environment. Assuming the prerequisite testing tasks are complete, the
legacy data should be converted to the Oracle Application production
environment and verified for accuracy and audit requirements.

Business System Testing


The final testing task involves supporting trained end users in the
execution of the Acceptance Test. The system’s functionality will be
measured in general against business requirements, and specifically
against Acceptance Test Criteria.

If users have been involved throughout the implementation, there


should be no surprises during the final system acceptance test. Prior to
the test, users must be trained for appropriate system skills to enable
their successful participation in the testing effort. A procedure should
be implemented to address any issues or problems that are identified
during testing, and all resolutions must be communicated to the
acceptance test team.

Training
User training should be delivered prior to the new system going into
production; however, timing is critical. If training is delivered too soon,
users will not be able to retain their knowledge; if delivered too late,
some users may be unprepared for their new responsibilities. The best
approach is to conduct a program of user certification or readiness
testing.

To retain the students’ attention and avoid overwhelming them with


information, it is important to break training sessions into manageable
sections that focus on clear objectives. Providing hands-on interaction

Oracle Method Transition 6 - 13


with the application will encourage confidence in their ability to use the
system.

Production Migration
The Business System Testing and Training tasks during Transition
provide opportunities to test the support procedures that have been
developed and documented. Distribute support materials throughout
the company, and review them during user training and testing
preparation. Practice logging technical assistance requests (TARs)
during testing and training to familiarize users with the support
procedures and to highlight any areas lacking sufficient coverage.

Notify external vendor support groups of the production cutover


schedule. You may want to request additional support coverage during
this period.

The typical transition time period is one month for small to moderate
projects with one deployment phase and includes the execution of all
training, support infrastructure, data conversion, and the setup of the
production environment.

A meeting with the entire organization will allow management to


answer any concerns and review contingency plans. In addition, key
managers should be notified of the impending transition so they can be
prepared to deal with any issues, potential delays in service, or
organizational changes.

6 - 14 Transition AIM Method Handbook


This page intentionally left blank.

Oracle Method Transition 6 - 15


Estimating

The following table indicates the typical percentage of effort required by


each task by role.

Production Database Administrator


Applications Administrator

Business Line Manager

Database Administrator
Client Project Manager

Network Adminstrator
IS Operations Staff
Business Analyst

Module Designer
IS Support Staff
Phase Effort

Programmer
IS Manager
Analyst
Transition
ID TASK %
Module Design and Build 30%
TR.080 Prepare User Training Environment 5.0% 20 0 10
TR.090 Train Users 25.0% 0 0 0
Data Conversion 30%
CV.130 Install Conversion Software 5.0% 0
CV.140 Convert and Verify Data 25.0% 0 15
Business Systems Testing 10%
TE.140 Support Acceptance Test 10.0% 0 0 25 10 25
Production Migration 30%
PM.040 Prepare Production Environment 5.0% 15 0 15
PM.050 Setup Applications 10.0% 20 70 5
PM.060 Implement Support Infrastructure 5.0% 0 0 0
PM.070 Verify Production Readiness 5.0% 0 0 0
PM.080 Commence Production 5.0% 20 20 20 20

Table 6-6 Transition Phase Estimating

6 - 16 Transition AIM Method Handbook


5
4
Project Database Administrator

25
25

5
0
Project Manager

20
20
Quality Auditor

45

Oracle Method
System Architect

5
5
Systems Administrator

35
10
30
15

5
Team Leader-Architecture

5
Team Leader-Conversion

25
15

5
0
Team Leader-Customization

5
Team Leader-Mapping

5
Team Leader-Performance Testing

Table 6-6
5
Team Leader-Testing

30

5
Team Leader-Training
11
15

Technical Analyst
50
50

Technical Architect

10
Trainer
85
15

0
0
0
0

User

100
100
100
100
100
100
100
100
100

Transition Phase Estimating (cont.)

Transition 6 - 17
Scheduling

Migrating the business to a new production environment requires a


high degree of planning and coordination. Scheduling is driven by the
operational concerns of the business, the effort and timing of data
conversion, and the number of users and sites to be migrated.

Scheduling Suggestions
Scheduling suggestions for Transition follow:

Project Management
Pay particular attention to the dependencies associated with entering
setup data and data conversion tasks. For example:

• Fixed assets account codes must be entered into the general


ledger before asset categories can be entered into fixed assets.
• Categories must be established before assets can be converted.

Cutoff dates for production transactions to the legacy system and the
dates that transactions can be entered into the Oracle Applications must
be determined and communicated to the user community with
adequate lead time. For example, the data conversion approach may
call for closing all open purchase orders before going live. This means
that all invoices for those purchase orders must be entered and
matched. To allow calendar time for invoices to be processed before
cut-over, you may decide that no new purchase orders or invoices can
be entered into the legacy system for two weeks before cutover to the
new applications. Purchasing and Payables would need to hold new
requisitions and invoices until they can be entered into the new
purchasing and accounts payable systems. Similar cutoff requirements
may exist for other applications.

The focus during Transition is the transfer of knowledge about the


application system to the user staff. This phase requires substantial user
involvement and possibly third party vendor participation or
networking and hardware support.

A multi-phase/multi-site deployment approach can create several


Transition challenges. You will need to repeat most, if not all,
Transition tasks for each deployment.

6 - 18 Transition AIM Method Handbook


Data Conversion
Data Conversion tasks require careful scheduling due to complex
dependencies among conversion steps and the entry of setup data. For
multi-phase/multi-site deployments, you will probably have to repeat
data conversions for each deployment.

Business System Testing


Acceptance Testing occurs during the first part of Transition. For multi-
site/multi-phase deployments, decide whether separate Acceptance
Tests will occur for each deployment or if you will rely on one initial
Acceptance Test.

Training
Multi-phase/multi-site deployment approaches may require training to
be repeated for each deployment.

The following factors may affect scheduling:

• site availability
• classroom hardware, software, audio/visual equipment
• instructors
• training materials
• separate database instances may be required for each class
conducted simultaneously with other classes
• development of training data to support class exercises
• identification and distribution of class operating system and
application logon IDs, passwords, and application responsibilities
• development and distribution of user manuals to classes and user
sites prior to cutover
• availability of technical support personnel to deal with problems
during classes

Production Migration
The production migration process will be repeated for each deployment
in a project with multiple deployment phases.

Oracle Method Transition 6 - 19


Staffing

This diagram illustrates a typical project organization for Transition.

Transition Organization

Project Management

Project Management Administrative Assistant/


Support Team Project Librarian

Technical Support Training

Applications Team Lead

Data Conversion
Team Members

Data Base

Technical Architecture &


Performance Testing

Documentation Transition

Team Lead Team Lead

Team Members Team Members

Figure 6-3 Staffing Chart for Transition

6 - 20 Transition AIM Method Handbook


Staffing Suggestions
This section provides advice and comments on project organization for
Transition.

Project Management
In addition to standard functionality testing, the Acceptance Test may
include:

• a test to simulate cutover and a day of production use; this is


performed in conjunction with an iteration of data conversion
• a parallel test that consists of running both the new application
and the legacy system in parallel and performing the same
operations with both; the results are verified to ensure that the
new system has the same functionality as the legacy system

Once Transition is complete, the client staff should be able to support


and maintain the application without outside assistance. Users should
be confident in their ability to use the new system.

Data Conversion
User management is responsible for the final data conversion results.
Insist that key users participate in the data conversion validation and
signoff.

For multi-phase/multi-site deployments, data conversion team


members may be needed over a long time period. Enable new team
members to be productive quickly by carefully documenting conversion
activities.

Business Systems Testing


Sufficient user participation in testing will enable user management to
sign-off on the system. For multiple deployments, decide if user testing
will occur for each deployment or only for the first deployment. Testing
for subsequent deployments may trigger new requests for
customizations and other changes.

Training
There are no significant staffing issues for this process in this phase.

Oracle Method Transition 6 - 21


Production Migration
Do not release specialists from their team responsibilities too soon.
There are usually unexpected issues near and during production
cutover that may require their assistance.

6 - 22 Transition AIM Method Handbook


CHAPTER

7 Production

T his chapter describes the Production phase of AIM. The goal of


Production is to monitor and ensure that the application is
performing adequately, and to plan for future functional enhancements.

Definition Operations Solution Build Transition Production


Analysis Design

Business Requirements Definition

Business Requirements Mapping

Application and Technical Architecture

Module Design and Build

Data Conversion

Documentation

Business System Testing

Performance Testing

Training

Production Migration

Figure 7-1 Context of AIM Production Phase

Oracle Method Production 7 - 1


Overview
This section provides an overview of Production.

Objectives

The objectives of Production follow:

• Monitor application performance and make corrections.


• Provide agreed upon levels of user support.
• Propose and plan future application enhancements.
• Propose and plan future business and technical direction.
• Audit the production system.
• Maintain the production system.
• Decommission the former system.

Critical Success Factors

The critical success factors for Production follow:

• effective change control tools and procedures


• accurate compilation of volumes, transaction histories, and other
performance drivers
• sufficient time and resources
• adequate staff and expertise
• effective participation by business management and users
• effective technical and application architecture

7 - 2 Production AIM Method Handbook


Overview Table

This table illustrates the prerequisites, processes, and key deliverables


for Production.

Process Prerequisites Key Deliverables

Production Migration Application Functional Business Direction


Architecture Recommendations

Application Security Architecture Decommissioned Former System

Architectural Strategy Maintained Production


Environment
Architecture Scope and Objectives
Post Implementation Production
Conversion Scope and Objectives System

Data Conversion Strategy Refined Production Environment

Detailed Transaction and System Performance Assessment


Contingency Plan
Technical Direction
Performance Risk Assessment Recommendations

performance Testing Strategy

Process Narrative

Production System

System Capacity Plan

System Management Guide

Transition Strategy

Table 7-1 Production Phase Overview Table

Production begins after the application system has gone into


production. During this phase the application implementation project is
brought to completion. The remaining development team reviews the

Oracle Method Production 7 - 3


application under actual usage conditions. Problems are logged and
analyzed, performance exceptions are found, and tuning is performed.
The business takes over maintenance of the application and plans are
made for future improvements.

Prerequisites

Prerequisites for Production follow. You should use these prerequisites,


if they exist, prior to beginning this phase. Otherwise, you may need to
create them during Production.

Prerequisite Source

Application Functional Architecture Application and Technical


Architecture

Application Security Architecture Application and Technical


Architecture

Architectural Strategy Application and Technical


Architecture

Architecture Scope and Objectives Application and Technical


Architecture

Conversion Scope and Objectives Data Conversion

Data Conversion Strategy Data Conversion

Detailed Transition and Contingency Production Migration


Plan

Performance Risk Assessment Application and Technical


Architecture

Performance Testing Strategy Performance Testing

Process Narrative Business Requirements


Mapping

Production System Production Migration

7 - 4 Production AIM Method Handbook


Prerequisite Source

System Capacity Plan Application and Technical


Architecture

System Management Guide Documentation

Transition Strategy Production Migration

Table 7-2 Production Phase Prerequisites

Processes

The processes used in this phase follow:

Production Migration
Audit, refine, and maintain the production system, propose the future
business and technical direction for the company, and decommission
the former system.

Key Deliverables

The key deliverables of this phase follow:

Deliverable Description

Business Direction The functional project team, along


Recommendations with senior management, begins
planning for future improvement
opportunities.

Decommission Former System Archive historical data and software.


If necessary, delete system
components.

Maintained Production The production environment that will


Environment be maintained.

Oracle Method Production 7 - 5


Deliverable Description

Post-implementation The production environment is


Production System carefully maintained using procedures
and techniques documented in the
System Management Guide.

Refined Production The production system will be refined


Environment through tuning, application setup
changes, and other performance
adjustments.

System Performance System transaction and reporting


Assessment performance is quantified. Metrics are
defined and applied to determine how
well the system supports the technical
needs of the business.

Technical Direction The technical project team, the


Recommendations Information Systems staff, and senior
management begin planning for using
new technologies.

Table 7-3 Production Phase Key Deliverables

7 - 6 Production AIM Method Handbook


Approach
This section describes the approach for Production.

Tasks and Deliverables

This table lists the tasks executed and the deliverables produced during
Production.

ID Task Deliverable

Production Migration
PM.090 Audit Production System Post-Implementation Production
System
PM.100 Measure System Performance System Performance Assessment
PM.110 Maintain System Maintained Production Environment
PM.120 Refine Production System Refined Production Environment
PM.130 Decommission Former System Decommissioned Former System
PM.140 Propose Future Business Direction Business Direction Recommendations
PM.150 Propose Future Technical Direction Technical Direction Recommendations
Table 7-4 Production Phase Tasks and Deliverables

Oracle Method Production 7 - 7


Task Dependencies

This diagram shows the dependencies between tasks in Production.

Production Production

PM.090 PM.130
Audit Production Propose Future
System Business Direction
PM.090 PM.140

PM.100 PM.100 PM.140


Propose Future
Measure System Refine Production
Technical
Performance System
Direction
PM.100 PM.120
PM.150

PRODUCTION PRODUCTION
MIGRATION PM.110

Maintain System
1 Line MIGRATION

PM.110
( 6 5/16 tall X 6 1/4 wide)
PM.120
Decommission
Former System
PM.130

Figure 7-2 Production Phase Task Dependencies

7 - 8 Production AIM Method Handbook


Managing Risks

The areas of risk and mitigation for Production include the following:

Risk Mitigation

Ongoing production support Retain contractors to provide support


staff does not possess during the critical period.
adequate system knowledge.

Ensure ongoing support staff are


adequately trained and
documentation is effective.

System performance cannot Refine the production system setup


adequately support and configuration based on user
production level transaction feedback regarding system
volumes. performance, reporting, and system
functionality.

Additional exception case Establish an ongoing application


business requirements are support business function with
discovered as users perform policies, procedures, organization,
job duties following and staff to address new and
production cutover. changed requirements.

Table 7-5 Risk Management Table for Production

Tips and Techniques

This section provides tips and techniques for managing Production. In


addition, advice and comments on each process are included.

Module Design and Build


After production cutover, new system maintenance and enhancement
begins. Some related considerations are:

• New technologies that were not available or out of scope at the


beginning of the implementation may now be considered.
• New products and applications may be investigated.

Oracle Method Production 7 - 9


• Requested customizations that were out of scope for the initial
implementation may be addressed.
• Planning for the next release of Oracle Applications may begin.

Adapt the Module Design and Build and Business System Testing
processes to support the design, development, and testing of
enhancements to the production system. Incorporate the updated
information into the Customization Strategy, Design Standards, and
Build Standards so that they represent the standards for future
enhancements. Define additional standards for tools that you may use
for future enhancements.

Production Migration
System maintenance falls into three major categories: routine, on-
demand, and upgrade:

• Routine maintenance includes setting up and executing hot and


cold backups, monitoring system performance, managing
tablespace, archiving and purging data, and database tuning. It
also involves tracking updates to the production configuration,
application setup, and application of patches.
• On-demand maintenance usually occurs in response to a user
request and includes setting up users, maintaining user access,
and correcting user and interface table data errors.
• Upgrade maintenance involves both minor and major upgrades.
It may need to be evaluated in terms of organizational and
structural impact, particularly in the case of major upgrades.
Minor upgrades are typically small changes or corrections to
system functionality, or performance enhancements for a specific
process.

System refinement involves soliciting user feedback and acting on


requests relative to the implementation, production system, or support.
These requests may involve adjusting application setups or profile
options, tuning a report or form, or major programming enhancements.
All enhancement requests should be logged, evaluated in terms of
impact to the system and/or organization, and tested thoroughly prior
to implementing the changes in the production environment.

It is strongly recommended that a separate shadow instance be created


and refreshed from the production instance to provide an environment
that resembles the production configuration but is safe for testing
patches, upgrades, and system refinements.

7 - 10 Production AIM Method Handbook


This page intentionally left blank.

Oracle Method Production 7 - 11


Estimating

The following table indicates the typical percentage of effort required by


each task by role.

Application Administrator

Business Line Manager

Database Administrator
Client Project Manager
Configuration Manager
Applications Architect
Applications Expert

Database Designer

IS Operations Staff
Business Analyst
Phase Effort

IS Manager
Facilitator
Analyst
Production
ID Task
Production Migration 77.8%
F.PM.090 Audit Production System 11.7% 50 0 0
F.PM.100 Measure System Performance 2.6% 40
F.PM.110 Maintain System 38.0% 20 0
F.PM.120 Refine Production System 11.4% 10 20 0
F.PM.130 Decommission Former System 5.3% 0 0
F.PM.140 Propose Future Business Direction 4.8% 75 0
F.PM.150 Propose Future Technical Direction 4.0% 0
Project Management 22.2%
PJM Manage Phase 22.2%
CONT Contingency 0.0%
100.0%

Table 7-6 Production Phase Estimating

7 - 12 Production AIM Method Handbook


0
0
IS Support Staff

Lead Tester
Module Designer
Network Adminstrator

15
20

Oracle Method
Production Database Administrat

Programmer
Project Database Administrator

50
20
Project Manager

50
Project Sponsor
Quality Auditor
Systems Administrator

10
40

15
System Architect
Team Leader - Architecture
Team Leader - BR

Table 7-6
Team Leader - Conversion
Team Leader - Customization
Team Leader - Documentation

Team Leader - Mapping


Team Leader - Performance Test
Team Leader - Testing

Team Leader - Training


50
25
20
20

Technical Analyst
Technical Architect
50

Technical Expert
Technical Expert - Build
Technical Expert - Design
Technical Expert Environment

Technical Expert - Existing Syste


Production Phase Estimating (cont.)

Technical Writer
Tester

Trainer
0

User
100

100
100

100
100
100

Production 7 - 13
Scheduling

The project changes its focus to providing initial support for the
production environment as well as transferring knowledge and
responsibilities to the ongoing applications support infrastructure.

Scheduling Suggestions
Scheduling suggestions for Production follow:

Project Management
Although budgetary concerns may be an issue, retain sufficient
resources to complete the project in a quality manner.

Verify that you have completed the following activities:

• prepared the organization’s application support group to deal


with questions and initial system problems
• provided the appropriate applications and technical architecture
to support the system load
• facilitated preparation of support infrastructure mechanisms
• developed appropriate documentation for support organizations
• trained the users and provided them with effective
documentation

Multiple deployments require multiple iterations of Production tasks


which may differ in significant ways. This will have a scheduling
impact.

Complexities that can affect scheduling are:

• “Mini” AIM phases and processes may be needed for each


deployment unless the business functions operate exactly the
same at all sites.
• Procedural workarounds that address gaps may vary according
to specific site requirements and could require adjustments to the
user training classes and user documentation.

7 - 14 Production AIM Method Handbook


• New interface and data conversion requirements could exist for
specific deployments if legacy systems are not available
throughout the company.
• Oracle Applications upgrades may be necessary during the
rollout period.

The implementation development project does not end when the team
installs the application system into production; auditors must perform
the system evaluation, and users may have questions or issues to be
resolved. Production prepares for these situations in an organized and
systematic way. There is also an opportunity for the client and
consultants to plan future development efforts.

Oracle Method Production 7 - 15


Staffing

This diagram illustrates a typical project organization for Production.

Production Organization

Project Management

Administrative Assistant/
Project Librarian

Technical Support Training and


Transition Support

Team Lead Team Lead

Team Members Team Members

Figure 7-3 Staffing Chart for Production

Staffing Suggestions
This section provides advice and comments on project organization for
Production.

Project Management
In addition to support and maintenance responsibilities, Production
requires other client involvement. Users must be prepared to provide
input into the system audit and may need to provide data on
transaction volumes and response times. In addition, users may be
asked to search for and report as many problems as possible during the
warranty period.

During Production, the project team is usually limited to developers


and support personnel. Each team member has to maintain or support
a broad functional area and must be cross-trained appropriately for this
responsibility.

All of the tasks in Production can be performed by the project team,


with the exception of the system audit (which is performed by the client
or a third party auditor). Use this time to transfer the ongoing jobs of
support and maintenance to the user.

7 - 16 Production AIM Method Handbook


The primary staffing challenges in Production are:

• retaining an appropriate number of team members to complete


the project
• transferring responsibilities to user groups
• managing staff during the rollout of a multi-phased deployment
when key personnel may not be available for the project duration

Oracle Method Production 7 - 17


APPENDIX

A AIM Work
Breakdown
Structure

T his appendix provides a list of the full AIM work breakdown


structure (WBS).

Oracle Method AIM Work Breakdown Structure A - 1


AIM Classic Approach Work Breakdown Structure
The following is a list of the AIM Classic approach work breakdown
structure.

ID Task Name Deliverable

A DEFINITION
A.PL Project Planning
A.PL.BEG Begin Definition Phase Planning
A.CR.010 Establish Scope, Objectives, and Approach Scope, Obj & Approach
A.CR.020 Define Control and Reporting Strategies, CR Strats, Stds & Procs
Standards, and Procedures
A.CR.030 Establish Management Plans Quality Plan
A.WM.010 Define Work Management Strategies, WFM Strats, Stds & Procs
Standards, and Procedures
A.WM.020 Establish Workplan Project Workplan
A.WM.030 Establish Finance Plan Finance Plan
A.RM.010 Define Resource Management Strategies, RM Strats, Stds & Procs
Standards, and Procedures
A.RM.020 Establish Staffing and Organization Plan Staffing Plan
A.RM.030 Implement Organization Project Organization
A.RM.040 Establish Physical Resource Plan Physical Resource Plan
A.RM.050 Establish Infrastructure Project Infrastructure
A.QM.010 Define Quality Management Strategies, QM Strats, Stds & Procs
Standards, and Procedures
A.CM.010 Define Configuration Management CM Strats, Stds & Procs
Strategies, Standards, and Procedures
A.PL.END End Definition Phase Planning
A.EX.BEG Start Definition Phase Execution
A.RD Business Requirements Definition
A.RD.010 Identify Financial and Operating Structure Financial & Op Struct
A.RD.020 Conduct Current Business Baseline Current Business Baseline
A.RD.030 Develop Future Process Model Future Process Model
A.RD.040 Develop Future Business Function Model Future Bus Func Model
A.RD.050 Establish Process and Mapping Summary Process & Mapping Sum
A.RD.060 Gather Business Volumes Bus Volume Requirements
A.TA Application and Technical Architecture
A.TA.010 Define Architecture Scope, Objectives, Arch Scope, Obj & App
and Approach

A - 2 AIM Work Breakdown Structure AIM Method Handbook


ID Task Name Deliverable

A.TA.020 Prepare Architecture Strategy Architectural Strategy


A.TA.030 Establish Architecture Requirements Architectural Reqs
A.TA.040 Develop Conceptual Architecture Conceptual Architecture
A.TA.050 Conduct Technical Architecture Baseline Technical Arch Baseline
A.MD Module Design and Build
A.MD.010 Prepare Customization Strategy Customization Strategy
A.CV Data Conversion
A.CV.010 Define Conversion Scope, Objectives, Conv Scope, Obj & App
and Approach
A.CV.020 Prepare Conversion Strategy Conversion Strategy
A.DO Documentation
A.DO.010 Prepare Glossary Glossary
A.DO.020 Specify Documentation Requirements Documentation Reqs
A.DO.030 Determine Documentation Standards Doc Stds & Procs
and Procedures
A.PT Performance Testing
A.PT.010 Define Performance Testing Scope, Perf Test Scop, Obj & App
Objectives, and Approach
A.PT.020 Prepare Performance Testing Strategy Perf Testing Strategy
A.EX.END End Definition Phase Execution
A.TR Training
A.TR.010 Prepare Training Strategy Performance Testing Strat
A.TR.030 Conduct General Education Classes Trained Project Team
A.TR.040 Conduct High-level Overview of Trained Project Team
Application Features
A.CT.CTR Phase Control
A.CT.BEG Begin Phase Control
A.CT.SUM Phase Control
A.CT.RES Unallocated Reserve
A.CT.END End Phase Control
A.CO.COMP Phase Completion
A.CO.BEG Begin Phase Completion
A.CR.080 Secure Client Phase Acceptance Client Phase Acceptance
A.RM.080 Release Staff Released Staff
A.RM.090 Release Physical Resources Released Physical
Resources
A.QM.050 Perform Quality Assessment Quality Report
A.CM.060 Audit Key Deliverables Audited Phase Baseline
A.CO.END End Phase Completion

Oracle Method AIM Work Breakdown Structure A - 3


ID Task Name Deliverable

B OPERATIONS ANALYSIS
B.PL.PLAN Phase Planning
B.PL.BEG Begin Phase Planning
B.PL.SUM Review and Revise Project Plans
B.PL.END End Phase Planning
B.EX.BEG Begin Operations Analysis Execution
B.RD Business Requirements Definition
B.RD.070 Create Business Requirements Scenarios Bus Reqs Scenario
B.RD.080 Determine Audit and Control Requirements Audit & Control Reqs
B.RD.090 Identify Business Availability Requirements Bus Availability Reqs
B.RD.100 Develop Reporting Requirements Master Rpt Tracking List
B.BR Business Requirements Mapping
B.BR.010 Prepare Mapping Environment Conf Mapping Environ
B.BR.020 Map Business Requirements Bus Reqs Mapping Form
B.BR.030 Map Business Data Bus Data Mapping
B.BR.040 Conduct Integration Fit Analysis Integration Fit Analysis
B.BR.050 Develop Information Flow Model Information Flow Model
B.BR.060 Develop Information Access Model Information Access Model
B.BR.070 Conduct Reporting Fit Analysis Master Rpt Tracking List
B.BR.080 Test Business Solutions Mapping Scenario
B.BR.090 Confirm Integrated Business Solutions Acceptance Certificate
B.TA Application and Technical Architecture
B.TA.060 Develop System Availability Strategy System Availability Strat
B.TA.070 Define Future Application Deployment Future Applic Deployment
B.TA.080 Develop Reporting Strategy Reporting Strategy
B.TA.090 Revise Conceptual Architecture Conceptual Architecture
B.TA.100 Define Architecture Subsystems Architecture Subsystems
B.TA.110 Propose Architecture Subprojects Arch Subproject Proposals
B.MD Module Design and Build
B.MD.020 Define and Estimate Custom Extensions Solution Document
B.CV Data Conversion
B.CV.030 Prepare Conversion Standards Conversion Standards
B.DO Documentation
B.DO.040 Prepare Documentation Environment Documentation Environ
B.DO.050 Produce Documentation Prototypes Doc Prototypes &
Templates Templates
B.PT Performance Testing
B.PT.030 Identify Performance Test Scenarios Perf Test Scenarios
B.PT.040 Identify Performance Test Transaction Perf Test Trans Models
Models
B.TR Training
B.TR.020 Prepare Project Team Training Environment Proj Team Train Environ

A - 4 AIM Work Breakdown Structure AIM Method Handbook


ID Task Name Deliverable

B.TR.050 Prepare Project Team Training Train Prep Checklist


B.TR.060 Train Project Team Trained Project Team
B.PM Production Migration
B.PM.010 Prepare Transition Strategy Transition Strategy
B.EX.END End Operations Analysis Execution
B.CT.CTR Phase Control
B.CT.BEG Begin Phase Control
B.CT.SUM Phase Control
B.CT.RES Unallocated Reserve
B.CT.END End Phase Control
B.CO.COMP Phase Completion
B.CO.BEG Begin Phase Completion
B.CR.080 Secure Client Phase Acceptance Client Phase Acceptance
B.RM.080 Release Staff Released Staff
B.RM.090 Release Physical Resources Released Physical Res
B.QM.050 Perform Quality Assessment Quality Report
B.CM.060 Audit Key Deliverables Audited Phase Baseline
B.CO.END End Phase Completion

C SOLUTION DESIGN
C.PL.PLAN Phase Planning
C.PL.BEG Begin Phase Planning
C.PL.SUM Review and Revise Project Plans
C.PL.END End Phase Planning
C.EX.BEG Begin Solution Design Execution
C.BR Business Requirements Mapping
C.BR.100 Create Process Narratives Process Narrative
C.BR.110 Define Application Setups App Setup Document
C.BR.120 Design Security Profiles Security Profiles
C.TA Application and Technical Architecture
C.TA.120 Design Application Security Architecture Application Security Arch
C.TA.130 Design Application Functional Architecture Application Func Arch
C.TA.140 Design Logical Application and Log Applic and Database
Database Architecture Architecture
C.TA.150 Design Physical Database Architecture Physical Database Arch
C.TA.160 Design Hardware and Network Hardware & Network
Architecture Architecture
C.TA.170 Develop System Capacity Plan System Capacity Plan
C.TA.180 Assess Performance Risks Perf Risk Assessment
C.TA.190 Design System Management Procedures System Mgmt Procs
C.MD Module Design and Build
C.MD.030 Define Design Standards Design Standards

Oracle Method AIM Work Breakdown Structure A - 5


ID Task Name Deliverable

C.MD.040 Define Build Standards Build Standards


C.MD.050 Design Database Extensions Database Exten Design
C.MD.060 Produce Module Functional Design Module Func Design
C.MD.070 Produce Module Technical Design Module Tech Design
C.MD.080 Review Detailed Designs Acceptance Certificate
C.CV Data Conversion
C.CV.040 Prepare Conversion Environment Conversion Environment
C.CV.050 Perform Conversion Data Mapping Conversion Data Mapping
(Map Conversion Data)
C.CV.060 Design Manual Conversion Strategy Manual Conversion Strat
C.CV.070 Design Conversion Programs Conv Program Design
C.CV.080 Prepare Conversion Test Plans Conv Test Plans
C.DO Documentation
C.DO.060 Produce Initial User Reference Manual Initial User Ref Manual
C.DO.070 Produce Initial User Guide Initial User Guide
C.DO.080 Produce Initial Technical Reference Manual Initial Tech Ref Manual
C.DO.090 Produce Initial System Management Guide Initial System Mgmt Guide
C.TE Testing
C.TE.010 Develop Test Strategy Testing Strategy
C.TE.020 Develop Unit Test Scripts Unit Test Scripts
C.TE.030 Develop Link Test Scripts Link Test Scripts
C.TE.040 Develop System Test Scripts System Test Scripts
C.TE.050 Develop Systems Integration Test Scripts Systems Int Test Scripts
C.PT Performance Testing
C.PT.050 Create Performance Test Scripts Performance Test Scripts
C.PT.060 Design Performance Test Transaction Test Transac Prog Design
Programs
C.PT.080 Design Performance Test Data Perf Test Data Design
C.PT.090 Design Test Database Load Programs Test Dbase Ld Prog Design
C.TR Training
C.TR.070 Develop User Training Materials User Training Manuals
C.PM Production Migration
C.PM.020 Design Production Support Infrastructure Prod Support Infrastructure
C.PM.030 Develop Detailed Transition & Detailed Trans & Cont Plan
Contingency Plan
C.EX.END End Solution Design Execution
C.CT.CTR Phase Control
C.CT.BEG Begin Phase Control
C.CT.SUM Phase Control
C.CT.RES Unallocated Reserve
C.CT.END End Phase Control
C.CO.COMP Phase Completion

A - 6 AIM Work Breakdown Structure AIM Method Handbook


ID Task Name Deliverable

C.CO.BEG Begin Phase Completion


C.CR.080 Secure Client Phase Acceptance Client Phase Acceptance
C.RM.080 Release Staff Released Staff
C.RM.090 Release Physical Resources Released Physical Res
C.QM.050 Perform Quality Assessment Quality Report
C.CM.060 Audit Key Deliverables Audited Phase Baseline
C.CO.END End Phase Completion

D BUILD
D.PL.PLAN Phase Planning
D.PL.BEG Begin Phase Planning
D.PL.SUM Review and Revise Project Plans
D.PL.END End Phase Planning
D.EX.BEG Begin Build Execution
D.MD Module Design and Build
D.MD.090 Prepare Development Environment Development Environment
D.MD.100 Implement Database Extensions Custom Database Objects
D.MD.110 Create Custom Modules Module Source Code
D.MD.120 Create Installation Routines Installation Routines
D.CV Data Conversion
D.CV.090 Develop Conversion Programs Conversion Programs
D.CV.100 Perform Conversion Unit Test Unit Tested Conv Progs
D.CV.110 Perform Conversion Business Object Test Bus Obj Tested Conv Progs
D.CV.120 Perform Conversion Validation Test Valid Tested Conv Progs
D.DO Documentation
D.DO.100 Complete User Reference Manual User Reference Manual
D.DO.110 Complete User Guide User Guide
D.DO.120 Complete Technical Reference Manual Tech Reference Manual
D.DO.130 Complete System Management Guide System Mgmt Guide
D.DO.140 Provide Online Help Text Online Help Text
D.TE Business System Testing
D.TE.060 Prepare Testing Environments Testing Environments
D.TE.070 Perform Unit Testing Unit Tested Modules
D.TE.080 Perform Link Testing Link Tested Modules
D.TE.090 Perform Installation Test Tested Install Routines
D.TE.100 Prepare Key Users for Testing Prepared Users
D.TE.110 Perform System Testing Sys Tested Applications
D.TE.120 Perform Regression Testing Regression Test Exec Mod
D.TE.130 Perform Systems Integration Testing Integration Tested Systems
D.PT Performance Testing
D.PT.070 Develop Performance Test Transaction Test Transaction Programs
Programs

Oracle Method AIM Work Breakdown Structure A - 7


ID Task Name Deliverable

D.PT.100 Develop Test Database Load Programs Test Database Load Progs
D.PT.110 Construct Performance Test Database Perf Test Database
D.PT.120 Prepare Performance Test Environment Perf Test Environ
D.PT.130 Execute Performance Test Perf Test Results
D.PT.140 Create Performance Test Report Perf Test Report
D.EX.END End Build Execution
D.CT.CTR Phase Control
D.CT.BEG Begin Phase Control
D.CT.SUM Phase Control
D.CT.RES Unallocated Reserve
D.CT.END End Phase Control
D.CO.COMP Phase Completion
D.CO.BEG Begin Phase Completion
D.CR.080 Secure Client Phase Acceptance Client Phase Acceptance
D.RM.080 Release Staff Released Staff
D.RM.090 Release Physical Resources Released Physical Res
D.QM.050 Perform Quality Assessment Quality Report
D.CM.060 Audit Key Deliverables Audited Phase Baseline
D.CO.END End Phase Completion

E TRANSITION
E.PL.PLAN Phase Planning
E.PL.BEG Begin Phase Planning
E.PL.SUM Review and Revise Project Plans
E.PL.END End Phase Planning
E.EX.BEG Begin Transition Execution
E.CV Data Conversion
E.CV.130 Install Conversion Software Installed Conv Software
E.CV.140 Convert and Verify Data Converted & Verified Data
E.TE Business System Testing
E.TE.140 Support Acceptance Test Acceptance Results
E.TR Training
E.TR.080 Prepare User Training Environment User Training Environ
E.TR.090 Train Users Trained Users
E.PM Production Migration
E.PM.040 Prepare Production Environment Production Environment
E.PM.050 Setup Applications Configured Applications
E.PM.060 Implement Support Infrastructure Doc Support Procs
E.PM.070 Verify Production Readiness Prod-Ready System
E.PM.080 Commence Production Production System
E.EX.END End Transition Execution
E.CT.CTR Phase Control

A - 8 AIM Work Breakdown Structure AIM Method Handbook


ID Task Name Deliverable

E.CT.BEG Begin Phase Control


E.CT.SUM Phase Control
E.CT.RES Unallocated Reserve
E.CT.END End Phase Control
E.CO.COMP Phase Completion
E.CO.BEG Begin Phase Completion
E.CR.080 Secure Client Phase Acceptance Client Phase Acceptance
E.RM.080 Release Staff Released Staff
E.RM.090 Release Physical Resources Released Physical Res
E.QM.050 Perform Quality Assessment Quality Report
E.CM.060 Audit Key Deliverables Audited Phase Baseline
E.CO.END End Phase Completion

F. PRODUCTION
F.PL.PLAN Phase Planning
F.PL.BEG Begin Phase Planning
F.PL.SUM Review and Revise Project Plans
F.PL.END End Phase Planning
F.EX.BEG Begin Production Execution
F.PM Production Migration
F.PM.090 Audit Production System Post-Implement Prod Sys
F.PM.100 Measure System Performance System Perf Assessment
F.PM.110 Maintain System Maintained Prod Environ
F.PM.120 Refine Production System Refined Prod Environ
F.PM.130 Decommission Former System Decomm Former Sys
F.PM.140 Propose Future Business Direction Bus Direction Recom
F.PM.150 Propose Future Technical Direction Tech Direction Recom
F.EX.END End Production Execution
F.CT.CTR Phase Control
F.CT.BEG Begin Phase Control
F.CT.SUM Phase Control
F.CT.RES Unallocated Reserve
F.CT.END End Phase Control
F.CO.COMP Phase Completion
F.CO.BEG Begin Phase Completion
F.CR.080 Secure Client Phase Acceptance Client Phase Acceptance
F.RM.080 Release Staff Released Staff
F.RM.090 Release Physical Resources Released Physical Res
F.QM.050 Perform Quality Assessment Quality Report
F.CM.060 Audit Key Deliverables Audited Phase Baseline
F.CO.END End Phase Completion

Oracle Method AIM Work Breakdown Structure A - 9


APPENDIX

B AIM Roles

T his appendix gives a brief description of each role and highlights its
main responsibilities.

Oracle Method AIM Roles B - 1


Role Descriptions

Application Administrator
The application administrator is responsible for code table maintenance
and production control. This person ensures the data content of the
shared code tables, for example, application setup values, lookup tables,
and system calendar is correct prior to and during production.
Scheduling the production batch processes is an optional additional
responsibility.

The application administrator may also be responsible for administering


the data that determines which data and functions users or groups of
users may access.

Application Architect
The application architect establishes the application architecture of a
newly implemented system. To accomplish this, the application
architect translates the future vision of the business into an application
and data deployment strategy. This strategy includes decisions about
centralizing or decentralizing business data and processing,
identification of interface points and specific requirements for data
transfer and synchronization across the business, critical setup of
applications to support the business process mapping, strategies to
support the reporting needs of the business, and other less general
requirements that may impact the architecture (such as multilingual
requirements). To ensure compatibility with the overall applications
architecture, the application architect provides input to more detailed
technical design efforts such as interfaces and custom components,

The application architect works closely with the technical architect to


ensure the physical layers of the architecture are consistent with and
fully support, the business and information systems vision for the
corporation. This synergism may extend all the way from scoping and
planning the project through to the final architecture deliverables and
client review.

Application Expert
The application expert provides knowledge and guidance regarding
application functionality. This person also supports and provides
interpretation for tools, templates, and methods.

B - 2 AIM Roles AIM Method Handbook


Business Analyst
The business analyst conducts interviews and working sessions. This
person also identifies detailed business requirements and creates
business requirement scenarios.

Business Line Manager


The business line manager participates in interviews and working
sessions by providing information about business objectives and ways
in which the units operate and respond to events to achieve those
objectives. Also, this person describes problems the business unit faces
and requirements for the computer system. The business line manager
hosts site visits by staff to collect the information. The business line
manager should review the content of the analysis documentation to
ensure it accurately describes the business and requirements.
Additionally, this person is responsible for allocating staff time to
provide detailed information about the day-to-day business.

The role of the business line manager should be filled by a person who
will manage one of the business units that will use the system.

Client Project Manager


The client project manager is responsible for the day-to-day
management of the client’s contractual commitments to the project.
This person must understand the client’s business objectives for the
project so that these can form the basis for resolving problems, conflicts
of interest, and making compromises.

The client project manager obtains physical resources such as


accommodation space, office equipment, computer equipment, and
materials. Additionally, this person ensures the client allocates time to
the project. The client project manager introduces the consulting staff to
the other client staff. This person is responsible for monitoring the
project’s performance, progress against milestones, appropriateness of
work, quality of work, and seeks to resolve any problems with work or
relationships between development and business staff. The client
project manager usually performs intermediate and phase-end signoffs.

The client project manager ensures availability of users, reviews


contents of models, and ensures user commitment, review, and signoff
of deliverables.

Oracle Method AIM Roles B - 3


Configuration Manager
The configuration manager plans, establishes, and controls the PJM
Configuration Management process on the project, with the following
responsibilities:

• develops, documents, and implements PJM Configuration


Management plans and procedures
• establishes project baselines and determines the content of project
releases
• ensures that no unauthorized changes are made to a project
baseline
• enforces Configuration Management procedures across all project
processes
• establishes and ensures that the PJM Configuration Management
Repository is adequately maintained and protected against
damage or loss

Database Administrator
The database administrator is required on large projects when there are
a number of teams of analysts or designers working on different
business areas or subsystems. During analysis, the database
administrator ensures data shared by business areas is modeled by a
common data structure that satisfies the functional requirements of
those areas. During design of the system architecture, the database
administrator performs a similar function for the system data model.
The database administrator can also identify common areas of
functionality.

This person should quickly understand the functional and data


requirements of the various areas, have strong analytical skills, and
have the ability to resolve conflicting requirements.

Database Designer
The database designer is responsible for producing the logical and
physical database designs. This person reviews the module designs to
ensure efficient access to the database.

The database designer must have a thorough understanding of the


system data model. Additionally, an understanding of the technical
architecture and functionality of the system is required so that

B - 4 AIM Roles AIM Method Handbook


compromises in the design can be made when different functions place
conflicting requirements on the database.

Facilitator
The facilitator runs mapping and process design sessions and keeps
momentum going.

IS Manager
The IS manager directs the client information systems organization
within a business. The IS manager acts as a business line manager for
the staff in the IS organization. This person is responsible for the
technical infrastructure of a business, including decisions about
purchases, in-house development, and operational maintenance and
support. The following information systems staff report directly or
indirectly to the IS manager:

• applications and technical architect


• technical analyst
• designer
• technical (database, network, system) administrator
• operations staff
• support staff

The IS manager defines the information systems strategy for a


corporation and puts the strategy into practice through standards,
policies, practices, and information systems selection processes.

IS Operations Staff
The IS operations staff is responsible for operating the existing
computer systems and new systems. The IS operations staff provides
information on operational requirements. This person acts as a
consumer of the training program.

IS Support Staff
The IS support staff is responsible for technical support of the client’s
systems. This person provides information about any IS standards with
which the project must comply, supports the business’ software
systems, and takes over support of the system during production. The

Oracle Method AIM Roles B - 5


IS support staff participates in any training program for the system
initially as consumers and later, possibly as providers. Finally, the IS
support staff provides information about existing systems the new
system will interface with or replace.

Lead Tester
The lead tester oversees the test script planning, development, and
execution activities. The lead tester reviews and approves the test
scripts. This person manages the test execution, monitors the progress
of testing activities, and ensures that the test results and problems are
logged. The lead tester also helps prioritize problem log entries.

Module Designer
The module designer is responsible for production of application and
module designs. This person communicates closely with the database
designer to ensure the database design meets the data requirements of
the module functionality and module access data efficiently. The
module designer also produces module and link test plans. During the
various testing activities and the production phase, this person
diagnoses faults and determines corrections.

The module designer must understand requirements from the business


analysis and how to meet these requirements using the technical and
system architectures and system data model.

Network Administrator
The Network Administrator is responsible for administering the
network. This includes ensuring that the network is correctly
configured, configuring and maintaining the network environment, and
performance monitoring the network.

Production Database Administrator


The production database administrator installs and configures the
production database and maintains database access controls. This
person provides consultation on performance, is responsible for
monitoring growth and fragmentation of the production database, and
ensures database backup and recovery.

B - 6 AIM Roles AIM Method Handbook


Programmer
The programmer produces working code that meets the module
specifications. The programmer diagnoses and corrects faults found by
tests. During production the programmer executes regression tests on
the corrections.

The programmer must have a thorough understanding of the


specifications for the modules to produce code. This person should also
understand how those modules fit in the system architecture and
business and technical requirements that they implement.

Project Database Administrator


The project administrator supports the project manager and project
coordinator by performing routine or repetitive tasks. The project
administrator prepares or maintains reports, records, logs and other
written communications, collects progress data from project leaders,
and distributes project calendars, meeting agendas, and meeting
minutes. The project administrator:

• organizes the Project Library, assigns documents into the library,


and maintains control of documents in the library
• orients new project members to the project environment, policies,
and procedures
• coordinates with administrators in client and subcontractor
organizations
• prepares project progress reports
• records and distributes minutes, decisions, and actions from
management meetings
• generates routine status information from project records
• maintains information on project staff such as grade,
qualifications, training, parent business unit or subcontractor,
telephone and address, project assignment history, and so on

For application implementations, the project administrator also


performs deliverable and template version management, gathers and
checks out deliverables, assigns document names and records new
documents into the library. This person also provides deliverable status
and advice regarding process integration.

Oracle Method AIM Roles B - 7


Project Manager
The project manager is ultimately responsible for the success or failure
of the project. This person must understand the project business
objectives of both the client and consultant, and have a clear vision of
how to achieve those objectives. The project manager agrees on the
scope of the project with the client and resolves any conflicts among the
various objectives of its stakeholders.

The project manager is responsible for the project planning, resourcing,


monitoring, and reporting the progress against the plan. This person
obtains any physical resources required for the project, recruits staff,
and, if necessary, dismisses staff. The project manager is responsible for
ensuring that activities are performed in accordance with the Quality
Plan.

Internal responsibilities of the project manager role should be delegated


to subordinate team leaders, as documented in the project organization
plan.

Project Sponsor
The project sponsor controls the budget and finances the project. This
person is usually a member of senior management. On large, cross-
functional projects the project sponsor may be a board member. This
person must have a clear understanding of the project objectives,
particularly concerning delivery of the business benefits. The project
sponsor is the ultimate arbiter on conflicting business requirements and
scope changes. The project sponsor ensures the project is delivered on
time and within budget.

The project sponsor is responsible for ensuring other members of the


management share commitment to the project. This person may
provide the resources, particularly staff time, required to make the
project a success. The project sponsor usually performs the final sign-
off.

Quality Auditor
The quality auditor conducts quality audits of the project. This position
should be filled by a person independent of the project staff in the
consulting organization. The quality auditor needs training in the audit
process. The quality auditor prepares for, conducts, reports on, and
follows up on any actions raised by the quality audit(s).

B - 8 AIM Roles AIM Method Handbook


System Administrator
The system administrator is responsible for administering the
development system. This person’s responsibilities include ensuring
hardware is correctly configured; installing, configuring, and
maintaining operating and development software; and ensuring that
daily backups of the system are performed. The system administrator
also designs and maintains the system’s security (for example,
establishing system accounts).

The system administrator provides first-line support for problems with


the development system and ensures faults are quickly rectified. This
person may perform the set up and initial maintenance of the
production system or advise the client’s operational staff on these tasks.
The system administrator works with the project team to optimize
system performance.

The system administrator installs packaged applications environments


and converts data.

Team Leader
The team leader plans, directs, and monitors the day-to-day work of the
team. This person assigns work packages to the team members and
ensures that they understand the requirements. The team leader is
responsible for building team cohesion, motivating the teams, and
providing assistance and encouragement to the team members.

Each team leader performs the final quality control and quality
assurance for the team by reviewing all deliverables. This person also
signs off team work completion and quality. Work that is not up to
quality standards is returned. Team leaders review deliverables from
other teams when these deliverables may impact aspects of the system.
This person reports the team’s progress to the project manager.

Larger projects may include team leaders in the area of analysis,


architecture, design, build, conversion, documentation, testing, training,
and transition. On small projects the roles of team leader and project
manager may be performed by the same individual.

Technical Analyst
The technical analyst proposes solutions and technical assumptions and
develops data profiles in support of testing.

Oracle Method AIM Roles B - 9


Technical Architect
The technical architect is responsible for architecting the physical
components of the database, hardware, and network in support of the
application architecture. To accomplish this, the technical architect
needs to design the detailed database, hardware, and network
architecture to support the application architecture and deployment
strategy. This includes decisions about the physical distribution of
processing across client and server machines, capacity planning of the
technical infrastructure, detailed design of the layout of databases, and
identification and advisement of performance risks. The technical
architect oversees detailed technical work on interface and system
design to ensure the detailed work is consistent with the overall
technical architecture.

The technical architect works closely with the application architect to


achieve an integrated overall architecture supporting the business and
information systems vision.

Technical Expert
The technical expert is a generic role covering the provision of high
expertise in the use and application of the various technologies used to
construct the system where these are not specifically covered by other
roles (such as database designer). On the project there will be a role for
each technology; for example, C++ programming, Oracle Forms, and
SQL Connect. There may also be experts needed in the areas of user
interface, standards, data conversion, and performance measurement.

The technical expert provides for the provision of standards for use of
the technology (for example, C programming and GUI standards)
provision of consultancy on the technology to other team members, and
participation in reviews of the use of the technology.

Technical Writer
The technical writer becomes familiar with the business and technical
requirements of the system and how the architecture, design, and
modules achieve those objectives. The technical writer specifies and
produces the user, technical, and operational documentation.

Tester
The testers develop and execute test script. Testers ensure test scripts
are reviewed by the appropriate business analysts prior to test

B - 10 AIM Roles AIM Method Handbook


execution. This person records test results during testing activities and
documents test faults in the problem log. Testers update test scripts to
reflect approved change requests or software faults that were not
anticipated in the original development. When problems are resolved
after retesting, testers update the problem log.

Trainer
The trainer is responsible for defining the training requirements,
preparing a training plan, producing training material, and delivering
courses.

User
The user is a member of the client’s staff who actually uses the
production system. The user’s responsibility is to be a consumer of the
training program and report problems with the production system.

Oracle Method AIM Roles B - 11


APPENDIX

C Role Usages

T his appendix provides a general alphabetical index of the roles used


in AIM. The following table lists each role and the AIM task(s) that
requires its participation.

Oracle Method Role Usages C - 1


Role Usages
Time not included in estimate is indicated by an asterisk (*).

Role Name ID Task Name %


Application Administrator B.BR.010 Prepare Mapping Environment 20
B.TR.020 Prepare Project Team Training 20
Environment
C.CV.040 Prepare Conversion Environment 20
D.MD.090 Prepare Development Environment 15
D.PT.120 Prepare Performance Test 20
Environment
D.TE.060 Prepare Testing Environments 20
E.PM.040 Prepare Production Environment 15
E.PM.050 Setup Applications 20
E.TR.080 Prepare User Training Environment 20
F.PM.110 Maintain System 20
F.PM.120 Refine Production System 10
Application Architect A.TA.010 Define Architecture Scope, Objectives, 10
and Approach
A.TA.020 Prepare Architecture Strategy 10
A.TA.030 Establish Architecture Requirements 45
A.TA.040 Develop Conceptual Architecture 40
B.BR.020 Map Business Requirements 5
B.BR.070 Conduct Reporting Fit Analysis 5
B.TA.070 Define Future Application Deployment 85
B.TA.080 Develop Reporting Strategy 50
B.TA.090 Revise Conceptual Architecture 35
B.TA.100 Define Architecture Subsystems 30
C.TA.130 Design Application Functional 60
Architecture
C.TA.140 Design Logical Application and 40
Database Architecture
C.TA.180 Assess Performance Risks 25
C.TA.190 Design System Management 10
Procedures
C.TE.050 Develop Systems Integration Test 20
Scripts
Application Expert B.BR.020 Map Business Requirements 25
B.BR.030 Map Business Data 30
B.BR.070 Conduct Reporting Fit Analysis 20

C - 2 Role Usages AIM Method Handbook


Role Name ID Task Name %

B.BR.080 Test Business Solutions 30


B.BR.090 Confirm Integrated Business Solutions 25
B.RD.070 Create Business Requirements 30
Scenarios
C.TA.120 Design Application Security 60
Architecture
Business Analyst A.DO.010 Prepare Glossary 95
A.DO.020 Specify Documentation Requirements 85
A.RD.010 Identify Financial and Operating 100
Structure
A.RD.020 Conduct Current Business Baseline 90
A.RD.030 Develop Future Process Model 90
A.RD.040 Develop Future Business Function 100
Model
A.RD.050 Establish Process and Mapping 100
Summary
A.RD.060 Gather Business Volumes 100
A.TA.030 Establish Architecture Requirements 10
A.TA.040 Develop Conceptual Architecture 20
A.TA.050 Conduct Technical Architecture 20
Baseline
B.BR.020 Map Business Requirements 35
B.BR.030 Map Business Data 50
B.BR.060 Develop Information Access Model 75
B.BR.070 Conduct Reporting Fit Analysis 35
B.BR.080 Test Business Solutions 60
B.BR.090 Confirm Integrated Business Solutions 25
B.MD.020 Define and Estimate Custom 10
Extensions
B.PT.030 Identify Performance Test Scenarios 35
B.PT.040 Identify Performance Test Transaction 10
Models
B.RD.070 Create Business Requirements 50
Scenarios
B.RD.080 Determine Audit and Control 100
Requirements
B.RD.090 Identify Business Availability 95
Requirements
B.RD.100 Develop Reporting Requirements 100
B.TA.070 Define Future Application Deployment 15
B.TA.080 Develop Reporting Strategy 20
B.TA.090 Revise Conceptual Architecture 20

Oracle Method Role Usages C - 3


Role Name ID Task Name %

B.TR.050 Prepare Project Team Training 45


C.BR.100 Create Process Narratives 95
C.BR.110 Define Application Setups 80
C.BR.120 Design Security Profiles 80
C.DO.070 Produce Initial User Guide 20
C.MD.060 Produce Module Functional Design 20
C.MD.080 Review Detailed Designs 30
C.PT.050 Create Performance Test Scripts 30
C.PT.080 Design Performance Test Data 30
C.PT.090 Design Test Database Load Programs 10
C.TA.120 Design Application Security 30
Architecture
C.TA.130 Design Application Functional 40
Architecture
C.TE.040 Develop System Test Scripts 60
C.TR.070 Develop User Training Materials 45
D.CV.120 Perform Conversion Validation Test 30
D.PT.070 Develop Performance Test Transaction 5
Programs
D.PT.100 Develop Test Database Load Programs 5
D.PT.140 Create Performance Test Report 5
E.PM.050 Setup Applications 70
E.PM.080 Commence Production 20
F.PM.090 Audit Production System 50
F.PM.120 Refine Production System 20
F.PM.140 Propose Future Business Direction 75
Business Line Manager A.DO.020 Specify Documentation Requirements *
A.DO.030 Determine Documentation Standards *
and Procedures
A.RD.010 Identify Financial and Operating *
Structure
A.RD.020 Conduct Current Business Baseline *
A.RD.030 Develop Future Process Model *
A.RD.050 Establish Process and Mapping *
Summary
A.RD.060 Gather Business Volumes *
A.TR.010 Prepare Training Strategy *
B.BR.020 Map Business Requirements *
B.BR.030 Map Business Data *
B.BR.060 Develop Information Access Model *
B.BR.080 Test Business Solutions *

C - 4 Role Usages AIM Method Handbook


Role Name ID Task Name %

B.BR.090 Confirm Integrated Business Solutions *


B.BR.100 Create Process Narratives *
B.MD.020 Define and Estimate Custom *
Extensions
B.RD.080 Determine Audit and Control *
Requirements
B.RD.090 Identify Business Availability *
Requirements
B.RD.100 Develop Reporting Requirements *
B.TA.080 Develop Reporting Strategy *
C.BR.100 Create Process Narratives *
C.MD.080 Review Detailed Designs *
C.PM.030 Develop Detailed Transition and *
Contingency Plan
C.TR.070 Develop User Training Materials *
D.TE.100 Prepare Key Users for Testing *
D.TE.110 Perform System Testing *
D.TE.130 Perform Systems Integration Testing *
E.PM.080 Commence Production 20
F.PM.090 Audit Production System *
F.PM.140 Propose Future Business Direction *
Client Project Manager A.TR.010 Prepare Training Strategy *
A.TR.030 Conduct General Education Classes *
A.TR.040 Conduct High-level Overview of *
Application Features
B.BR.010 Prepare Mapping Environment *
B.BR.090 Confirm Integrated Business Solutions *
B.PM.010 Prepare Transition Strategy *
B.TR.020 Prepare Project Team Training *
Environment
C.CV.060 Design Manual Conversion Strategy *
C.PM.030 Develop Detailed Transition and *
Contingency Plan
E.PM.060 Implement Support Infrastructure *
E.PM.070 Verify Production Readiness *
E.PM.080 Commence Production 20
E.TE.140 Support Acceptance Test *
E.TR.080 Prepare User Training Environment *
E.TR.090 Train Users *
F.PM.090 Audit Production System *
Configuration Manager B.BR.020 Map Business Requirements 5

Oracle Method Role Usages C - 5


Role Name ID Task Name %

B.BR.070 Conduct Reporting Fit Analysis 10


B.RD.070 Create Business Requirements 10
Scenarios
Database Administrator B.TA.060 Develop System Availability Strategy 10
C.TA.140 Design Logical Application and 10
Database Architecture
C.TA.150 Design Physical Database Architecture 80
C.TA.160 Design Hardware and Network 10
Architecture
C.TA.170 Develop System Capacity Plan 20
C.TA.190 Design System Management 20
Procedures
D.PT.120 Prepare Performance Test 10
Environment
D.PT.130 Execute Performance Test 20
D.PT.140 Create Performance Test Report 10
E.PM.050 Setup Applications 5
F.PM.100 Measure System Performance 40
Database Designer C.MD.050 Design Database Extensions 60
C.TA.140 Design Logical Application and 10
Database Architecture
D.MD.100 Implement Database Extensions 20
Facilitator A.RD.020 Conduct Current Business Baseline 10
A.RD.030 Develop Future Process Model 10
B.BR.020 Map Business Requirements 5
B.BR.070 Conduct Reporting Fit Analysis 5
B.RD.070 Create Business Requirements 5
Scenarios
IS Manager A.PT.010 Define Performance Testing Scope, *
Objectives, and Approach
A.PT.020 Prepare Performance Testing Strategy *
A.TA.010 Define Architecture Scope, Objectives, *
and Approach
A.TA.020 Prepare Architecture Strategy *
A.TA.030 Establish Architecture Requirements *
A.TA.040 Develop Conceptual Architecture *
A.TA.050 Conduct Technical Architecture *
Baseline
B.PT.030 Identify Performance Test Scenarios *
B.PT.040 Identify Performance Test Transaction *
Models
B.TA.060 Develop System Availability Strategy *

C - 6 Role Usages AIM Method Handbook


Role Name ID Task Name %

B.TA.070 Define Future Application Deployment *


B.TA.080 Develop Reporting Strategy *
B.TA.090 Revise Conceptual Architecture *
B.TA.100 Define Architecture Subsystems *
B.TA.110 Propose Architecture Subprojects *
C.PM.020 Design Production Support *
Infrastructure
C.PM.030 Develop Detailed Transition and *
Contingency Plan
C.TA.160 Design Hardware and Network *
Architecture
C.TA.170 Develop System Capacity Plan *
C.TA.180 Assess Performance Risks *
C.TA.190 Design System Management *
Procedures
D.PT.140 Create Performance Test Report *
E.PM.060 Implement Support Infrastructure *
E.PM.070 Verify Production Readiness *
F.PM.130 Decommission Former System *
F.PM.150 Propose Future Technical Direction *
IS Operations Staff A.CV.010 Define Conversion Scope, Objectives, *
and Approach
A.CV.020 Prepare Conversion Strategy *
A.TA.040 Develop Conceptual Architecture *
A.TA.050 Conduct Technical Architecture *
Baseline
B.DO.040 Prepare Documentation Environment *
B.TA.060 Develop System Availability Strategy *
B.TA.090 Revise Conceptual Architecture *
C.PM.020 Design Production Support *
Infrastructure
C.PM.030 Develop Detailed Transition and *
Contingency Plan
C.TA.150 Design Physical Database Architecture *
C.TA.160 Design Hardware and Network *
Architecture
C.TA.170 Develop System Capacity Plan *
C.TA.190 Design System Management *
Procedures
D.MD.090 Prepare Development Environment *
E.CV.130 Install Conversion Software *
E.CV.140 Convert and Verify Data *

Oracle Method Role Usages C - 7


Role Name ID Task Name %

E.PM.040 Prepare Production Environment *


F.PM.090 Audit Production System *
F.PM.110 Maintain System *
F.PM.120 Refine Production System *
F.PM.130 Decommission Former System *
IS Support Staff A.TR.040 Conduct High-level Overview of *
Application Features
B.TR.050 Prepare Project Team Training *
B.TR.060 Train Project Team *
C.CV.050 Perform Conversion Data Mapping *
C.PM.030 Develop Detailed Transition and *
Contingency Plan
C.TR.070 Develop User Training Materials *
D.CV.090 Develop Conversion Programs *
D.DO.130 Complete System Management Guide *
D.TE.100 Prepare Key Users for Testing *
E.CV.130 Install Conversion Software *
E.PM.060 Implement Support Infrastructure *
E.PM.070 Verify Production Readiness *
E.PM.080 Commence Production 20
E.TE.140 Support Acceptance Test *
E.TR.090 Train Users *
F.PM.110 Maintain System *
Lead Tester C.TE.010 Develop Test Strategy 100
C.TE.050 Develop Systems Integration Test 20
Scripts
D.TE.060 Prepare Testing Environments 10
D.TE.100 Prepare Key Users for Testing 75
D.TE.110 Perform System Testing 10
D.TE.120 Perform Regression Testing 10
D.TE.130 Perform Systems Integration Testing 10
Module Designer B.MD.020 Define and Estimate Custom 70
Extensions
C.CV.070 Design Conversion Programs 90
C.DO.060 Produce Initial User Reference Manual 10
C.DO.070 Produce Initial User Guide 10
C.DO.080 Produce Initial Technical Reference 20
Manual
C.MD.050 Design Database Extensions 40
C.MD.060 Produce Module Functional Design 80
C.MD.070 Produce Module Technical Design 90

C - 8 Role Usages AIM Method Handbook


Role Name ID Task Name %

C.MD.080 Review Detailed Designs 30


C.PT.060 Design Performance Test Transaction 60
Programs
C.PT.090 Design Test Database Load Programs 60
C.TE.020 Develop Unit Test Scripts 20
C.TE.030 Develop Link Test Scripts 80
C.TE.040 Develop System Test Scripts 10
D.DO.100 Complete User Reference Manual 20
D.DO.120 Complete Technical Reference Manual 10
D.MD.110 Create Custom Modules 10
D.TE.110 Perform System Testing 10
D.TE.120 Perform Regression Testing 10
D.TE.130 Perform Systems Integration Testing 0
E.TE.140 Support Acceptance Test 25
Network Administrator A.PT.010 Define Performance Testing Scope, 5
Objectives, and Approach
B.TA.060 Develop System Availability Strategy 10
C.TA.160 Design Hardware and Network 10
Architecture
C.TA.170 Develop System Capacity Plan 10
C.TA.190 Design System Management 20
Procedures
D.PT.120 Prepare Performance Test 10
Environment
D.PT.130 Execute Performance Test 20
D.PT.140 Create Performance Test Report 10
E.PM.040 Prepare Production Environment 15
F.PM.110 Maintain System 20
F.PM.120 Refine Production System 15
Production Database E.CV.140 Convert and Verify Data 20
Administrator
E.PM.040 Prepare Production Environment 25
E.TE.140 Support Acceptance Test 10
F.PM.110 Maintain System 50
F.PM.120 Refine Production System 20
Programmer C.MD.070 Produce Module Technical Design 10
C.MD.080 Review Detailed Designs 30
C.TE.020 Develop Unit Test Scripts 80
C.TE.030 Develop Link Test Scripts 20
D.CV.090 Develop Conversion Programs 100
D.CV.100 Perform Conversion Unit Test 100

Oracle Method Role Usages C - 9


Role Name ID Task Name %

D.DO.120 Complete Technical Reference Manual 10


D.DO.140 Provide Online Help Text 40
D.MD.110 Create Custom Modules 90
D.MD.120 Create Installation Routines 100
D.PT.070 Develop Performance Test Transaction 85
Programs
D.PT.100 Develop Test Database Load Programs 85
D.TE.070 Perform Unit Testing 50
D.TE.080 Perform Link Testing 20
D.TE.090 Perform Installation Test 20
D.TE.110 Perform System Testing 20
D.TE.120 Perform Regression Testing 20
D.TE.130 Perform Systems Integration Testing 20
E.TE.140 Support Acceptance Test 25
Project Database Administrator A.PT.010 Define Performance Testing Scope, 5
Objectives, and Approach
B.BR.010 Prepare Mapping Environment 30
B.TR.020 Prepare Project Team Training 25
Environment
B.TR.060 Train Project Team 2
C.CV.040 Prepare Conversion Environment 30
D.MD.090 Prepare Development Environment 25
D.MD.100 Implement Database Extensions 80
D.PT.110 Construct Performance Test Database 25
D.TE.060 Prepare Testing Environments 30
E.TR.080 Prepare User Training Environment 25
E.TR.090 Train Users 2
Project Manager A.CV.010 Define Conversion Scope, Objectives, 10
and Approach
A.DO.020 Specify Documentation Requirements 5
A.PT.010 Define Performance Testing Scope, 30
Objectives, and Approach
A.PT.020 Prepare Performance Testing 15
A.TA.010 Define Architecture Scope, Objectives, 30
and Approach
A.TA.020 Prepare Architecture Strategy 30
A.TR.010 Prepare Training Strategy 60
B.PM.010 Prepare Transition Strategy 90
B.TA.090 Revise Conceptual Architecture 10
B.TA.100 Define Architecture Subsystems 20
B.TA.110 Propose Architecture Subprojects 20

C - 10 Role Usages AIM Method Handbook


Role Name ID Task Name %

C.PM.030 Develop Detailed Transition and 75


Contingency Plan
E.CV.140 Convert and Verify Data 5
E.PM.070 Verify Production Readiness 20
E.PM.080 Commence Production 20
F.PM.090 Audit Production System 50
Project Sponsor A.MD.010 Prepare Customization Strategy *
A.RD.020 Conduct Current Business Baseline *
A.RD.030 Develop Future Process Model *
A.RD.040 Develop Future Business Function *
Model
A.TA.040 Develop Conceptual Architecture *
B.MD.020 Define and Estimate Custom *
Extensions
B.TA.090 Revise Conceptual Architecture *
C.TA.180 Assess Performance Risks *
D.PT.140 Create Performance Test Report *
Quality Auditor E.PM.070 Verify Production Readiness 45
System Administrator A.PT.010 Define Performance Testing Scope, 5
Objectives, and Approach
B.BR.010 Prepare Mapping Environment 40
B.DO.040 Prepare Documentation Environment 80
B.TA.060 Develop System Availability Strategy 10
B.TR.020 Prepare Project Team Training 35
Environment
B.TR.060 Train Project Team 2
C.BR.110 Define Application Setups 10
C.BR.120 Design Security Profiles 10
C.CV.040 Prepare Conversion Environment 40
C.DO.090 Produce Initial System Management 20
Guide
C.TA.160 Design Hardware and Network 35
Architecture
C.TA.170 Develop System Capacity Plan 20
C.TA.190 Design System Management 40
Procedures
D.DO.130 Complete System Management Guide 15
D.MD.090 Prepare Development Environment 35
D.PT.120 Prepare Performance Test 40
Environment
D.PT.130 Execute Performance Test 30
D.PT.140 Create Performance Test Report 10

Oracle Method Role Usages C - 11


Role Name ID Task Name %

D.TE.060 Prepare Testing Environments 40


D.TE.090 Perform Installation Test 80
E.CV.130 Install Conversion Software 90
E.CV.140 Convert and Verify Data 5
E.PM.040 Prepare Production Environment 35
E.PM.050 Setup Applications 5
E.TE.140 Support Acceptance Test 10
E.TR.080 Prepare User Training Environment 35
E.TR.090 Train Users 2
F.PM.100 Measure System Performance 40
F.PM.110 Maintain System 10
F.PM.120 Refine Production System 15
System Architect D.DO.130 Complete System Management Guide 15
Team Leader-Architecture A.TA.010 Define Architecture Scope, Objectives, 50
and Approach
A.TA.020 Prepare Architecture Strategy 50
B.TA.100 Define Architecture Subsystems 20
B.TA.110 Propose Architecture Subprojects 80
C.TA.180 Assess Performance Risks 25
E.PM.070 Verify Production Readiness 5
Team Leader-Business B.RD.070 Create Business Requirements 5
Requirements Scenarios
Team Leader-Conversion A.CV.010 Define Conversion Scope, Objectives, *
and Approach
A.CV.020 Prepare Conversion Strategy 20
C.CV.040 Prepare Conversion Environment 10
C.CV.050 Perform Conversion Data Mapping 10
(Map Conversion Data)
C.CV.060 Design Manual Conversion Strategy 10
C.CV.070 Design Conversion Programs 10
C.CV.080 Prepare Conversion Test Plans 10
C.PM.030 Develop Detailed Transition and 10
Contingency Plan
D.CV.110 Perform Conversion Business Object 10
Test
D.CV.120 Perform Conversion Validation Test 10
E.CV.130 Install Conversion Software 10
E.CV.140 Convert and Verify Data 15
E.PM.070 Verify Production Readiness 5
Team Leader-Customization A.MD.010 Prepare Customization Strategy 25
C.MD.030 Define Design Standards 10

C - 12 Role Usages AIM Method Handbook


Role Name ID Task Name %

C.MD.040 Define Build Standards 10


C.MD.080 Review Detailed Designs 10
D.MD.090 Prepare Development Environment 10
E.PM.070 Verify Production Readiness 5
Team Leader-Documentation A.DO.020 Specify Documentation Requirements 10
A.DO.030 Determine Documentation Standards 30
and Procedures
B.DO.040 Prepare Documentation Environment 5
D.DO.110 Complete User Guide 40
Team Leader-Mapping B.BR.010 Prepare Mapping Environment 10
B.BR.020 Map Business Requirements 5
B.BR.040 Conduct Integration Fit Analysis 5
B.BR.050 Develop Information Flow Model 5
B.BR.070 Conduct Reporting Fit Analysis 5
B.BR.080 Test Business Solutions 5
B.BR.090 Confirm Integrated Business Solutions 25
C.BR.100 Create Process Narratives 5
C.BR.110 Define Application Setups 10
C.BR.120 Design Security Profiles 10
E.PM.070 Verify Production Readiness 5
Team Leader-Performance A.PT.010 Define Performance Testing Scope, 55
Testing Objectives, and Approach
A.PT.020 Prepare Performance Testing Strategy 70
B.PT.030 Identify Performance Test Scenarios 65
B.PT.040 Identify Performance Test Transaction 65
Models
C.PT.050 Create Performance Test Scripts 10
C.PT.060 Design Performance Test Transaction 20
Programs
C.PT.080 Design Performance Test Data 20
C.PT.090 Design Test Database Load Programs 10
D.PT.070 Develop Performance Test Transaction 10
Programs
D.PT.100 Develop Test Database Load Programs 10
D.PT.110 Construct Performance Test Database 5
D.PT.120 Prepare Performance Test 5
Environment
D.PT.130 Execute Performance Test 20
D.PT.140 Create Performance Test Report 45
E.PM.070 Verify Production Readiness 5
Team Leader-Testing D.TE.100 Prepare Key Users for Testing 25

Oracle Method Role Usages C - 13


Role Name ID Task Name %

E.PM.070 Verify Production Readiness 5


E.TE.140 Support Acceptance Test 30
Team Leader-Training A.TR.010 Prepare Training Strategy 30
A.TR.030 Conduct General Education Classes 5
A.TR.040 Conduct High-level Overview of 5
Application Features
B.TR.020 Prepare Project Team Training 10
Environment
B.TR.050 Prepare Project Team Training 5
B.TR.060 Train Project Team 6
C.PM.030 Develop Detailed Transition and 15
Contingency Plan
C.TR.070 Develop User Training Materials 5
E.PM.070 Verify Production Readiness 5
E.TR.080 Prepare User Training Environment 10
E.TR.090 Train Users 6
Technical Analyst A.CV.010 Define Conversion Scope, Objectives, 90
and Approach
A.CV.020 Prepare Conversion Strategy 80
A.PT.020 Prepare Performance Testing Strategy 15
B.BR.020 Map Business Requirements 20
B.BR.030 Map Business Data 20
B.BR.040 Conduct Integration Fit Analysis 95
B.BR.050 Develop Information Flow Model 95
B.BR.060 Develop Information Access Model 25
B.BR.070 Conduct Reporting Fit Analysis 20
B.BR.080 Test Business Solutions 5
B.BR.090 Confirm Integrated Business Solutions 25
B.CV.030 Prepare Conversion Standards 100
B.PT.040 Identify Performance Test Transaction 25
Models
B.RD.090 Identify Business Availability 5
Requirements
C.CV.050 Perform Conversion Data Mapping 90
(Map Conversion Data)
C.CV.060 Design Manual Conversion Strategy 90
C.CV.080 Prepare Conversion Test Plans 90
C.PT.050 Create Performance Test Scripts 60
C.PT.060 Design Performance Test Transaction 20
Programs
C.PT.080 Design Performance Test Data 50

C - 14 Role Usages AIM Method Handbook


Role Name ID Task Name %

C.PT.090 Design Test Database Load Programs 20


C.TA.120 Design Application Security 10
Architecture
C.TA.140 Design Logical Application and 10
Database Architecture
D.PT.110 Construct Performance Test Database 70
D.PT.120 Prepare Performance Test 15
Environment
D.PT.130 Execute Performance Test 20
D.PT.140 Create Performance Test Report 20
E.CV.140 Convert and Verify Data 55
F.PM.100 Measure System Performance 20
F.PM.120 Refine Production System 20
F.PM.140 Propose Future Business Direction 25
F.PM.150 Propose Future Technical Direction 50
Technical Architect A.TA.010 Define Architecture Scope, Objectives, 10
and Approach
A.TA.020 Prepare Architecture Strategy 10
A.TA.030 Establish Architecture Requirements 45
A.TA.040 Develop Conceptual Architecture 40
A.TA.050 Conduct Technical Architecture 80
Baseline
B.PM.010 Prepare Transition Strategy 10
B.TA.060 Develop System Availability Strategy 70
B.TA.080 Develop Reporting Strategy 30
B.TA.090 Revise Conceptual Architecture 35
B.TA.100 Define Architecture Subsystems 30
C.TA.140 Design Logical Application and 30
Database Architecture
C.TA.150 Design Physical Database Architecture 20
C.TA.160 Design Hardware and Network 45
Architecture
C.TA.170 Develop System Capacity Plan 50
C.TA.180 Assess Performance Risks 50
C.TA.190 Design System Management 10
Procedures
E.PM.040 Prepare Production Environment 10
F.PM.150 Propose Future Technical Direction 50
Technical Expert A.MD.010 Prepare Customization Strategy 75
B.MD.020 Define and Estimate Custom 20
Extensions

Oracle Method Role Usages C - 15


Role Name ID Task Name %

C.PM.020 Design Production Support 100


Infrastructure
Technical Expert-Build C.MD.040 Define Build Standards 90
C.MD.030 Define Design Standards 90
D.MD.090 Prepare Development Environment 15
Technical Expert-Existing A.DO.010 Prepare Glossary 5
Systems
Technical Writer A.DO.030 Determine Documentation Standards 70
and Procedures
B.DO.040 Prepare Documentation Environment 15
B.DO.050 Produce Documentation Prototypes 100
and Templates
B.TR.050 Prepare Project Team Training 25
C.DO.060 Produce Initial User Reference Manual 90
C.DO.070 Produce Initial User Guide 70
C.DO.080 Produce Initial Technical Reference 80
Manual
C.DO.090 Produce Initial System Management 80
Guide
C.TR.070 Develop User Training Materials 25
D.DO.100 Complete User Reference Manual 80
D.DO.110 Complete User Guide 60
D.DO.120 Complete Technical Reference Manual 80
D.DO.130 Complete System Management Guide 70
D.DO.140 Provide Online Help Text 60
Tester C.TE.040 Develop System Test Scripts 30
C.TE.050 Develop Systems Integration Test 60
Scripts
D.CV.110 Perform Conversion Business Object 90
Test
D.CV.120 Perform Conversion Validation Test 60
D.TE.070 Perform Unit Testing 50
D.TE.080 Perform Link Testing 80
D.TE.110 Perform System Testing 60
D.TE.120 Perform Regression Testing 60
D.TE.130 Perform Systems Integration Testing 60
Trainer A.TR.010 Prepare Training Strategy 10
A.TR.020 Prepare Project Training Environment 10
A.TR.030 Conduct General Education Classes 95
A.TR.040 Conduct High-level Overview of 95
Application Features

C - 16 Role Usages AIM Method Handbook


Role Name ID Task Name %

A.TR.050 Prepare Project Team Training 25


B.TR.060 Train Project Team 90
C.TR.070 Develop User Training Materials 25
E.TR.080 Prepare User Training Environment 10
E.TR.090 Train Users 90
User A.CV.010 Define Conversion Scope, Objectives, *
and Approach
A.CV.020 Prepare Conversion Strategy *
A.DO.010 Prepare Glossary *
A.RD.020 Conduct Current Business Baseline *
A.RD.030 Develop Future Process Model *
A.RD.040 Develop Future Business Function *
Model
A.RD.060 Gather Business Volumes *
B.BR.040 Conduct Integration Fit Analysis *
B.BR.050 Develop Information Flow Model *
B.BR.060 Develop Information Access Model *
B.BR.070 Conduct Reporting Fit Analysis *
B.DO.050 Produce Documentation Prototypes *
and Templates
B.PT.030 Identify Performance Test Scenarios *
B.RD.070 Create Business Requirements *
Scenarios
B.RD.080 Determine Audit and Control *
Requirements
B.RD.090 Identify Business Availability *
Requirements
B.RD.100 Develop Reporting Requirements *
B.TR.050 Prepare Project Team Training *
C.MD.060 Produce Module Functional Design *
C.MD.080 Review Detailed Designs *
C.PT.050 Create Performance Test Scripts *
D.PT.130 Execute Performance Test *
D.TE.080 Perform Link Testing *
E.PM.050 Setup Applications *
E.PM.070 Verify Production Readiness *
E.PM.080 Commence Production *
E.TE.140 Support Acceptance Test *
F.PM.090 Audit Production System *

Oracle Method Role Usages C - 17


APPENDIX

D AIM 2 Data Model

T his appendix provides a general description of the AIM 2 Data


Model.

Oracle Method AIM 2.0 Data Model D - 1


Purpose and Objective of the Data Model
A sound method should be based on well-defined, related building
blocks that can be used to develop and execute a project plan by
utilizing resources, producing deliverables, and meeting business
objectives. The AIM Data Model represents these building blocks and
their relationships as Data Objects and Relationships.

The purpose of the Data Model is to help ensure quality, promote ease
of use, and facilitate integration within Oracle methods like CDM or
PJM. It provides a framework that ensures consistency among the
various AIM elements by:

• defining standard names for the building blocks


• communicating relationships among the various building blocks

For example, a project can have multiple deployments. This is depicted


by the line connecting project and deployment.

D - 2 AIM 2.0 Data Model AIM Method Handbook


Program

Organizer
of
Governed
by AIM 2.0
Data Model
Project

Initiator of
Controled
by

Deployment Revision 4 May 18, 1997

Compose
d of
Parent Within
of
Activated
Business Unit during At Site
Child of Activation Go live during
Affect
Require Conversion
Performed during Execution
Facilitated delivered
by by
Class Class Session
Created to An Execution of
support instance
of Attended
by
Activation
of Trained
Sub-
during
function of
Subject
of
Person
Function

Decomposed
Event Triggerd During High-level Business into Perform
Domain of Function Assgned
to

Trigger for
Performed by Role
Elementary Business Performer of
Function

Supported
by Application
Capable of supporting
Executed by
Source of
User Composed of
of
Accessed
by Executed during

Business Object Migrated via Conversion


Migration method for
Decompose
d into Source of Composed of
Instance of Within
Response to

Described by Application
Process Step
Process Function
Detail of
Sub-
process Executed during
of Associated Associated
Performed by
with with
following

Source of
Requirement
Associated
with
Executed A uniqe Source of
via response the
result of
path for

Gap

Requirements
Scenario Catalyst
for Closure
of Performed using

Supported Instructions for


by Impemented with Carried
An alternate
Solution Procedure out with Procedure Step
approach to
New steps to Details
support of

Mapping Scenario

Implemented
with Policy
required
to enable
Part of

Implemented
with Customization Composed of Module
created to Part of
provide

Figure D-1 AIM Data Model Diagram

Oracle Method AIM 2.0 Data Model D - 3


AIM Data Object Definitions
These descriptions correspond to the labeled boxes in Figure D-1 —
AIM Data Model Diagram. Each description defines the data object and
its relationships with other objects.

Relationship to AIM Processes, Tasks, and Deliverables

The data objects in the Data Model represent the information that is
analyzed, documented or is the subject of work on an AIM project.
Processes and tasks operate on data objects that are then included in
deliverables. In some cases there is no deliverable for a data object. In
other cases a data object may correspond to a section in an AIM
deliverable.

Relationship to the AIM Glossary

Definitions for all data objects are included in the AIM Glossary.

Data Object Definitions

Activation
Definition
A logical event corresponding to the enabling of one High-level business
function at one site for one business unit. For example, a single
deployment will have many Activations in the process of going live,
with multiple Business Units using multiple High-level Business
Functions at one or more sites. Each Activation represents a discrete
unit of work that can be predicted and measured.

Relationships
There can be one or more Activation for a Deployment. One or more
Business Units may be associated with an Activation. You may go live
with Accounts Payable and Purchasing at a single site at the same time;
however, an Activation is only associated with one Site.

D - 4 AIM 2.0 Data Model AIM Method Handbook


A site can be associated with one or more Activation. For example,
Order Entry and Inventory might go live at a specific site on one date;
later Accounts Payable and Purchasing might go live at the same site.

One or more Classes may be held for an Activation. If Purchasing and


Accounts Payable are going live at a specific site at the same time you
may want to conduct training classes for the users. An Activation may
have Classes; you may decide to train users from Site A at Site B, or
you may choose not to train users at specific sites.

Application
Definition
An Application is a collection of program modules that work together
to support a set of related business functions. Order Entry, Inventory,
Projects, Work In Process, General Ledger, and so on are Oracle
Applications.

Relationships
An Application may support one or more Business Functions. For
example, General Ledger supports all of the Business Functions that
provide journal entries. The Purchasing System may support the
Project Accounting Business Function as well as the Purchasing and
Inventory Business Functions.

Application Function
Definition
An Application function is a portion of an Application that supports a
subset of the Business Functions supported by the overall Application.
The Journal Entry Function of the General Ledger System is an example.

Relationships
An Application Function must relate to only one Application and an
Application must have one or more Application Functions.

Oracle Method AIM 2.0 Data Model D - 5


Business Function
Definition
A Business Function is what an enterprise does, or needs to do, to
achieve its objectives. Manufacturing, purchasing, accounting,
engineering, and sales are Functions.

There are two special kinds of Functions in AIM: High-level and


Elementary Business Functions. They are represented in the diagram as
boxes inside of the box labeled Business Function.

A High-level Business Function is a Business Function that is at the top


of the Business Hierarchy Diagram (an AIM deliverable). An
Elementary Business Function is the lowest level in this diagram.

If Purchasing is a High-level Business Function, an Elementary Business


Function within Purchasing might be Approving Contracts. A typical
part of a Business Function hierarchy would be Approving Contracts
rolling up to a mid-level Business Functions Contract Management that in
turn rolls up to Purchasing, the High-level Business Function.

Relationships
The dotted circle on the upper right hand corner of the Business
Function box indicates that one Business Function may relate to another
in the hierarchical fashion described above.

At least one Event must relate to a High-level Business Function. For


example, receiving an invoice is an Event that may be associated with
the High-level Business Function Accounts Payable.

A High-level Business Function may be related to one or more Events.


It is possible that because the scope of an implementation project, the
team will not be analyzing Events associated with some High- Level
Business Functions. However, to understand the organizational
context, such a High-level Business Function might still be included in
the Business Function Hierarchy diagram.

An Event may be related to only one High-level Business Function. It is


possible to design a Business Function Hierarchy poorly so that an
Event appears to be related to more than one High-level Business
Functions, however, this is a sign that the function hierarchy is
ambiguous and should be revised. Sales order might be related to the
Order Entry High-level Business Function.

D - 6 AIM 2.0 Data Model AIM Method Handbook


A Business Function may relate or one or more Requirements. There
are generally many Requirements for a Business Function. Examples of
Requirements associated with the Buyer Business Function are:

• ability to group like requisitions


• ability to automatically route requisitions to buyers by vendor or
item category

An Elementary Business Function may relate to one or more Process


Steps but a Process Step must relate to at least one Elementary Business
Function.

Business Object
Definition
A Business Object is a physical or logical object of significance to a
business (for example, a sales order, department, assembly, item,
balance, or invoice). A Business Object is analogous to a class in object
oriented terminology.

Relationships
A Business Object may be related to one or more Conversions. Fixed
Assets are Business Objects that may need to be converted from a legacy
system to Oracle’s Fixed Asset System.

Business Objects must relate to at least one Business Function. If a


Business Function for a Business Object to be converted does not appear
to be identified there is a deficiency in your Business Function
Hierarchy diagram.

Business Unit
Definition
A business unit is part of an organization treated as a separate entity
within the parent organization. Examples include a department or
distribution center.

Relationships
A Business Unit may be related to itself since there may be a hierarchy
of Business Units. For example, A Procurement Department may be
comprised of Purchasing, Inventory, and Contracts departments.

Oracle Method AIM 2.0 Data Model D - 7


A Business Unit may also be associated with one or more Activations.
Certain applications may go live at different times for a Business Unit.

One Activation might affect one or more Business Units. Purchasing


and Accounts Payable may go live in several Business Units at the same
time. For example, a company may have regions with central
Purchasing and Accounts Payable Business Units in each region.

Class
Definition
A Class refers to the training of students on specific topics. Usually
training is provided for Oracle Applications such as Bill of Materials,
Work In Process, and so on. Training may also be provided for job
policy and procedures, Help Desk operations, and so on.

Relationships
One or more Classes may be held for each Activation. If Accounts
Payable is going live at a specific site on a specific date you may want to
hold a class for that Activation. Depending on the number of students,
you may need to have multiple classes. However, students from a
particular site may be trained elsewhere, therefore, you would not
necessarily have a Class for every Activation.

A Class must have at least one Class Session. If there are more students
than can be accommodated in one class you may need multiple Class
Sessions.

Class Session
Definition
A Class Session consists of delivering a Class to a specific set of students
at a particular place and time.

Relationships
There may be one or more Class Sessions for a Class. One or more
people may attend a Class Session.

D - 8 AIM 2.0 Data Model AIM Method Handbook


Conversion
Definition
Conversion includes the total set of activities converting Business
Objects from legacy systems to the newly installed Oracle applications.

For example, the Fixed Assets Conversion would refer to all processes,
tasks, and deliverables associated with converting Fixed Assets data
from the old system to the Oracle Fixed Assets system.

Relationships
A Conversion may be associated with one or more Conversion
Executions. For example, a project that has multiple deployments by
region may require a separate Fixed Assets data conversion for each
region.

A Conversion must be associated with at least one Business Object. For


example, an Inventory Conversion might at least migrate Inventory
Items from the old system to new systems.

A Business Object may be associated with one or more Conversions.


For example, you may want to convert open Projects for Oracle Projects.
Open Projects may be related to open Purchase Orders in Oracle’s
Purchasing System that is how Commitments are shown in Oracle
Projects. In this case you would also be converting Open Purchase
Orders to get them into Oracle Purchasing; therefore, the Business
Object Open Purchase Orders is actually part of both the Oracle Projects
and Purchasing Conversions.

Conversion Execution
Definition
An example of a Conversion Execution would be the conversion of open
orders from a legacy system to Oracle Order Entry in one region on a
given date. Other regions may go live with Order Entry on a different
date requiring other order entry Conversion Executions.

Relationships
There must be at least one Conversion Execution associated with a
Conversion. A Conversion Execution must always be associated with
only one Conversion.

Oracle Method AIM 2.0 Data Model D - 9


In a project with a phased deployment by region, the Accounts Payable
Conversion of open invoices may need to occur once for each region.

Customization
Definition
A customization is a change made to the standard Oracle software that
implements a Solution to a Gap.

Relationships
A Customization must be related to only one Solution. A Solution may
relate to one or more Customizations.

Deployment
Definition
A deployment is the total set of activities associated with the production
implementation of a set of applications in specific location(s) at a
specific time.

For example, going live with Oracle’s General Ledger, Purchasing, and
Accounts Payable systems in Region 1 on 1-MAY-98 is a deployment;
going live in Region 2-OCT-98 would be another Deployment.

Relationships
A Deployment is always associated with one Project. A Deployment
may contain one or more Activations.

Gap
Definition
A Gap is a relationship between a Requirement and an Application
Function where the standard Application Function will not meet the
Requirement.

Relationships
A Gap must be related to one or more Requirements and one or more
Application Functions; it may relate to only one Solution. A Solution
must relate to one or more Gaps, therefore, the inability to drill down
from General Ledger to Accounts Receivable may have been identified
as a Gap for that a Solution was developed.

D - 10 AIM 2.0 Data Model AIM Method Handbook


Mapping Scenario
Definition
A Mapping Scenario is a detailed step by step description of how you
want team members to test the standard Oracle software to see if it will
meet the needs of a Business Requirements Scenario.

Relationships
A Mapping Scenario must be related to only one Business Requirements
Scenario. A Business Requirements Scenario may be related to one or
more Mapping Scenarios.

Module
Definition
A module is a logical program unit. Examples include forms, reports,
user exits, C programs, PL/SQL procedures, and database triggers.

Relationships
A Module must either relate to a Customization or a Conversion.

One or more Modules may be required to implement a Customization.


One or more modules may also be required to provide the custom
software to convert Business Objects from legacy systems to the new
Oracle systems.

Policy
Definition
A policy is a documented directive from enterprise management that
specifies how some aspect of the business is to be conducted.

For example, a policy might be that any expenditure over fifty dollars
must be transacted using a Purchase Requisition instead of petty cash.

Relationships
A Policy may be related to only one Solution. One or more Policies
could be related to a Solution.

Oracle Method AIM 2.0 Data Model D - 11


A solution to a Gap may be to disallow separate costs for the same item
in different warehouses. This would be documented in a policy
requiring that all items have the same cost across all warehouses.

Procedure
Definition
A Procedure is a written set of steps that specifies how to carry out a
business function.

An example would be a Procedure for uploading journal entry data in


spreadsheet form to Oracle General Ledger.

Relationships
A Procedure may relate to only one Solution. It must relate to at least
one Procedure Step.

Process
Definition
A Process is a grouping of tasks based on common functions or
disciplines that lead to one or more key deliverables. Examples of
Processes in an enterprise include: Invoice Entry, Requisitioning,
Creating Purchase Orders, Running Material Requirements Planning,
and so on.

Relationships
A Process may relate to another Process. There may be a hierarchy of
processes in an enterprise. For example, you might define a process
called Replenish Inventory. This could be comprised of lower level
processes such as Analyze Stock Shortages, Create Requisitions, and so on.

Processes must be related to at least one Event. Several Events could be


related to one Process. The Invoice Entry Process is related to the Receipt
of an Invoice Event.

A process must have at least one Process Step. The Invoice Processing
Process might include steps such as:

• date and time stamp invoice


• sort invoices by type

D - 12 AIM 2.0 Data Model AIM Method Handbook


• distribute invoices to Invoice Entry Clerks
• form invoice batches
• enter invoices
• check batch totals

A Process may have one or more Business Requirements Scenarios.


Business Requirements Scenarios are different paths through the
process that you want to ensure the application can handle. For invoice
processing you may have the following Business Requirements
Scenarios:

• standard invoice with existing vendor and no sales tax proration


• invoice with no existing vendor master record
• invoice requiring sales tax proration

There may be one or more Process Steps for a Process.

Process Step
Definition
Processes are comprised of individual Process Steps that represent
actions required to complete a Process.

Relationships
A Process Step must be associated with only one Process. A Process
Step must also be associated with an Elementary Business Function. A
Process Step must be associated with only one Procedure.

The Enter Invoice Process Step may be part of the Invoice Processing
Process. It must relate to an Elementary Business Function (that might
be Process Invoices). There may be a user Procedure describing how to
enter an invoice.

Program
Definition
A Program is an interrelated group of projects either run concurrently
or sequentially, that share a system goal. Individual projects may have
different goals; however, the combined set of projects will have a
program goal.

Oracle Method AIM 2.0 Data Model D - 13


Relationships
Each program must have two or more projects.

Project
Definition
A project is a set of work processes, tasks with associated deliverables,
and resources executed over a specific period of time with
predetermined budget and business objectives.

Relationships
A project may be part of a Program that always has at least two
projects. A project will always have at least one Deployment.

Requirement
Definition
A Requirement is a specific, detailed business need compared with
Application functionality to determine if the need can be met with
standard Oracle software.

Relationships
A Requirement must be associated with a Business Function, a Process,
or a Conversion. Examples of Requirements include:

• ability to handle different item costs for the same item in different
warehouses
• ability to drill down from General Ledger account balances to
subledger detail (such as Accounts Payable, Accounts Receivable,
or Fixed Assets)
• ability to automatically track Engineering Change Orders
• ability to automatically assign new Asset categories and
associated account codes to fixed asset records being converted
from legacy systems

A Requirement must only be associated with one of the three objects


mentioned above. This AIM requirement facilitates cross referencing
and maintaining an audit trail.

D - 14 AIM 2.0 Data Model AIM Method Handbook


A Requirement may be associated with only one Gap; however, a Gap
may be associated with one or more Requirements. For example, the
vanilla software may meet the drill down requirement from the General
Ledger to detailed Account Payable records, but it does not address all
the needs for drill down to Accounts Receivable detail. This would be
documented in AIM as a Gap related to this requirement.

Business Requirements Scenario


Definition
A Business Requirements Scenario is a formal statement of detailed
business requirements for a Process, the source of the Requirements,
how these requirements will be satisfied (either the application, manual
Procedure, Workarounds, or other application solutions), and what
prototyping steps must be taken to prove the design.

Relationships
A Business Requirements Scenario must be associated with a Process.
A Process may be associated with one or more Business Requirements
Scenarios.

A Business Requirements Scenario must be associated with one or more


Mapping Scenarios.

For example, Invoice Processing is an Accounts Payable Process. A


related Business Requirements Scenario would describe in narrative
form how the enterprise wishes to process invoices.

If the invoice processing Process has different possible paths because of


decision points, there may be multiple Business Requirements
Scenarios. One Business Requirements Scenario might deal with one
line invoices where there is no need to prorate tax lines to other invoice
lines. Another scenario would address the more complex case.

When you want to test the application to see if the standard software
will handle a given Business Requirements Scenario, you will develop
one or more Business Mapping Scenarios.

Why might you have more than one Business Mapping Scenario? There
might be different ways to use an Oracle Application to meet a given
Business Requirements Scenario. For example, assume that you can set
up Oracle Accounts Payable to handle automatic proration of tax lines
to other invoice lines in different ways; in this case you might want to
try it for each different setup option. You would create Business

Oracle Method AIM 2.0 Data Model D - 15


Mapping Scenarios to document how team members should test the
system.

Role
Definition
A role is a generic set of activities that may be assigned to people (for
example, Buyer, Requisitioner, Fixed Asset Accountant, Planner,
Invoice Entry Clerk, and so on).

Relationships
A Role may be assigned to one or more people and a person may be
assigned a role.

Site
Definition
A site is a uniquely identifiable geographic location or place from that
one or more business organizations may be wholly or partly operating.

Relationships
A Site may be associated with one or more Activations. Some
applications may go live in a Site on one date, and other applications
may go live later at the same Site. An Activation is associated with only
one Site.

Solution
Definition
A Solution is the resolution of the discrepancy between one or more
Gaps and one or more standard Application Functions.

A Solution may take the form of a Procedure, Policy, or Customization.

An example would be the decision to build a Customization that


enhances the standard Application Function by changing or adding
software to the base Oracle Application. With the example of
insufficient drill down capability from the General Ledger to detailed
Accounts Receivable records, fields that resolve the Gap could be added
to a General Ledger form.

D - 16 AIM 2.0 Data Model AIM Method Handbook


Relationships
A Solution must be related to one or more Gaps. It may relate to one or
more Procedures, Policies, or Customizations.

For example, assume that a Gap is an automated tax proration feature in


Oracle Accounts Payable that does not work exactly the way an
enterprise wants. One Solution might be to establish a policy that tax
proration will be done manually. An associated Procedure might be
developed indicating how to do the manual proration. A different
Solution would be to customize the Accounts Payable System by
altering the way it handles tax proration.

Oracle Method AIM 2.0 Data Model D - 17


Glossary

24x7 A period or window of service Activation A logical event corresponding


availability that covers 24 hours day, to the enabling of one high level
seven days a week. business function at one site for one
business unit. Each activation
3GL see THIRD-GENERATION PROGRAMMING represents a discrete unit of work that
LANGUAGE we can predict and measure.

4GL see FOURTH-GENERATION Actuals Information gathered during a


PROGRAMMING LANGUAGE project concerning the actual amount of
time, finances or resources expended
A on a task.

ABT see APPLIED BUSINESS TECHNOLOGY. Advocate An individual who supports the
project within the client environment,
Acceptance The approval, typically by a without being involved in the project’s
client or user, of a project deliverable. implementation. An advocate may be a
formal or informal leader within the
Access Control The ability to manage organization.
which users or groups of users may
have the privilege to retrieve, create,
update, or delete data held in a
repository, such as a relational
database.

Oracle Method Glossary G - 1


Agent A generic term for a party which is (Oracle) Application Functional
responsible for the execution and Configuration The definition of key
completion of a process step. An agent architectural setup parameters in an
may be an organizational unit, a application instance or product group
functional unit, a business system, an to reflect the financial and operating
employee role, an external system, or environment of the business
an external party such as a customer or organizations that transact within that
supplier. application instance or product group.

Agent Channel A horizontal division on a Application Gap A recorded variance


process flow diagram that indicates between some aspect of a business
which agent performs which particular requirement and the capability or
functions within the process being features of the application system that
modeled. are necessary to satisfy the
requirement.
AIM see APPLICATION IMPLEMENTATION
METHOD. Application Implementation Method
(AIM) A method that comprises a
Application A collection of program flexible approach for implementing
modules that work together to support Oracle Applications.
a set of related business functions; see
also MODULE. Application Instance A unique set of
application tables and processes. Note
(Oracle) Application Environment A that two instances of the same version
complete application installation along of an application may share one set of
with other utilities used for business program modules but they may not
mapping, design, build, testing, or share the same set of application tables.
training. Usually, an application
environment includes setups and test Application Interface A mechanism used
data to support business modeling, and to transfer data between applications.
procedures exist to recover to A data flow between applications is
controlled starting points after sessions always implemented as a set of one or
are complete. more application interfaces; see also
NEAR REAL-TIME INTERFACE and REAL-
Application Fit A recorded match TIME INTERFACE.
between some aspect of a business
requirement and the capability or Application Process An indication of the
features of the application system that sequential execution of a series of
satisfies the requirement. system functions, possibly including
manual functions as well; see also
Application Function A portion of an MANUAL FUNCTION, SYSTEM FUNCTION,
Application which supports a subset of and SYSTEM PROCESS.
the business functions supported by the
overall Application.

G - 2 Glossary AIM Method Handbook


Application System An automated Arm’s Length Transaction An inter-
collection of business functions, company transaction that is treated as a
entities, modules, technology third party transaction.
platforms, and documentation that
performs a specified set of business Attribute Any detail that serves to
functions; see also BUSINESS SYSTEM, qualify, identify, classify, quantify, or
MODULE, PLANNED RESPONSE SYSTEM, express the state of an entity; any
and SYSTEM FUNCTION. description of a thing of significance.

(Oracle) Applications Distributed AutoText Entry Microsoft Word allows


Interface An interface between similar you to store frequently used text,
or dissimilar Oracle Applications graphics, and other items and quickly
products that have data stored in insert them into documents. These
multiple separate databases. The stored items are referred to as
databases may or may not be resident AutoText entries. If you store text and
at multiple sites (data centers). The graphics as AutoText entries, you can
corollary of this is that Applications retrieve them by clicking a button,
distributed interfaces may exist at a typing a few keystrokes, or choosing a
single site. command. Components of the
Deliverable Templates are stored as
(Oracle) Applications Interface An AutoText entries in global templates
interface between similar or dissimilar used to store boilerplate text; see also
Oracle Applications products that have BOILERPLATE TEXT.
data stored in the same database. The
interface may or may not be supported B
within the standard package products.
Backup and Recovery Strategy A storage
Applied Business Technology (ABT) A
and recovery strategy that protects
company that manufactures tools to
against business information loss
profile, estimate, and plan projects.
resulting from hardware, software, or
Oracle Services has a global licensing
network faults.
agreement with ABT. Oracle Method
makes use of Project Workbench, Baseline 1. A starting point or condition
Methods Architect, and Project Bridge against which future changes are
Modeler as its worldwide methods and measured. 2. A named set of object
project management software standard; versions which fixes a configuration at
see also PROJECT BRIDGE MODELER and a particular point in time. A baseline
PROJECT WORKBENCH. normally represents a milestone or key
deliverable of a project; see also
Approach A particular way of putting a
CURRENT BUSINESS BASELINE.
method or task to use, including risk
factors, tips from experience,
recommendations, and additional
advice; see also TECHNIQUE.

Oracle Method Glossary G - 3


Bid and Proposal Management (BPM) Business An enterprise, commercial
Specifies the process, tasks, entity, or firm in either the private or
responsibilities, and deliverables public sector, concerned with
regarding how business opportunities providing products or services to
are qualified and responded to, satisfy customer requirements.
eventually leading to the issue of an
authorized bid to a client. Business Aim A statement of business
intent measured subjectively; for
Billable Project Expenses The project example, to move up market, or to
expenses that are billable to a client; see develop a sustainable level of growth;
also PROJECT EXPENSES. usually strategic or tactical with a 3-5
year horizon.
Billable Utilization The utilization that is
billable to a client; see also UTILIZATION. Business Area The set of business
processes within the scope of a project.
Black Box Test A test of all or part of an
application system based upon Business Constraint Any external,
fulfilling business requirements or management, or other factor that
meeting functional specifications. A restricts a business or system
black box test does not require an development in terms of resource
understanding of the actual code under availability, dependencies, timescales,
test. A system test is usually a black or some other factor.
box test.
Business Data Mapping Verification that
Boilerplate Text Pre-written collection of the underlying table structures and
words, sentences, headings, and attributes will support business
formatting in a template that you can processes.
modify to suit a specific need; see also
AUTOTEXT ENTRY. Business Function Something an
enterprise does, or needs to do, in
Bottom-up Estimate A task-level estimate order to achieve its objectives; see also
derived by calculating the estimating APPLICATION SYSTEM, BUSINESS PROCESS,
factors critical to completion of each MANUAL FUNCTION, and SYSTEM
task; see also ESTIMATING FACTOR. FUNCTION.

BPM see BID AND PROPOSAL Business Function Model A


MANAGEMENT. representation of all the business
functions within a defined scope. A
BPR see BUSINESS PROCESS REENGINEERING. wide range of techniques is available
for modeling business functions.; see
Budget A plan for determining, in also FUNCTION DECOMPOSITION and
advance, the expenditure of time, FUNCTION HIERARCHY.
money, etc.
Business Goal A statement of business
intent.

G - 4 Glossary AIM Method Handbook


Business Location A uniquely identifiable Business Organization Type A
geographic location, site, or place from classification of a business organization
which one or more business units may into one of several functional
wholly or partly operate. categories. Each business organization
type has a distinct set of business
Business Model A model or collection of requirements. All the business
models representing the definition of organizations of a certain type will
key components of a business. typically require similar applications
Components may include models of and system capabilities. A given site
processes, objectives, functions, and may house one or more business
information; see also BUSINESS PROCESS organization types. Since business
MODEL, ENTITY RELATIONSHIP DIAGRAM, organizations may be related in a
and FUNCTION HIERARCHY. hierarchy, a high level business
organization may be composed of
Business Object A physical or logical several business organizations of
object of significance to a business; for different types. For the purposes of
example, a sales order, department, application architecture analysis and
assembly, item, balance, or invoice. A design, it is generally useful to
business object is analogous to a class decompose the hierarchy of business
in object-oriented terminology. organizations until it is composed of
atomic organization types; see also
Business Objective Business conditions CUSTOMER SERVICE, DISTRIBUTION,
which, if met, will solve the business FINANCE, HUMAN RESOURCES,
problem statement. Well-defined INFORMATION SYSTEMS,
objectives are measurable and often MANUFACTURING, MARKETING,
relate directly to business processes PLANNING, RESEARCH AND
and deliverables; see PROBLEM DEVELOPMENT, and SALES.
STATEMENT.
Business Priority A statement of the level
Business Organization Any part of a or urgency of important business
business treated for any purpose as a needs.
separate unit within the parent
business organization; for example, a
department, division, or subsidiary; see
also BUSINESS UNIT.

Oracle Method Glossary G - 5


Business Process The complete response Business Requirements Mapping An
that a business makes to an event. A activity that describes the business
business process entails the execution requirements for a business process in
of a sequence of one or more process business language, optionally compares
steps. It has a clearly defined the current solution for a business
deliverable or outcome. A Business requirement to a proposed solution and
Process is defined by the business event specifies details for the type and nature
that triggers the process, the inputs and of the solution in a descriptive format.
outputs, all the operational steps The deliverable can also be used as a
required to produce the output, the record of key decisions, or as a
sequential relationship between the placeholder in anticipation of
process steps, the business decisions additional detailed design
that are part of the event response, and documentation.
the flow of material and/or
information between process steps; see Business Requirements Scenario A
also BUSINESS FUNCTION, BUSINESS formal statement of the detailed
PROCESS MODEL, and EVENT RESPONSE. business requirements for a business
process, the source of these
Business Process Model The collection of requirements, how these requirements
process flow diagrams that comprise will be satisfied (either by the
the complete set of business processes application, manual process steps,
within the application scope; see also workarounds or other application
PROCESS FLOW DIAGRAM. solutions), and what prototyping steps
must be taken to prove the designs.
Business Process Reengineering (BPR) Known as a BRS.
The activity by which an enterprise
reexamines its goals and how it Business Rule A rule under which an
achieves them, followed by a organization operates. A policy or
disciplined approach of business decision that influences the process
process redesign. A method that step
supports this activity.
Business Solution Testing A technique
Business Requirement A formal by which management agrees that
statement that describes application business requirements will be satisfied
features necessary to support a if the application and other tools
business process step. perform as specified by process
designs.

Business System A combination of


people and automated applications
organized to meet a particular set of
business objectives; see also
APPLICATION SYSTEM and PLANNED
RESPONSE SYSTEM.

G - 6 Glossary AIM Method Handbook


Business Unit Part of an organization Change Effort Any activity consciously
treated for any purpose as a separate undertaken by an enterprise, business
entity within the parent organization. unit, or individual, that will result in
Examples include a department or critical change in one or more areas of
distribution center; see also BUSINESS the organization, e.g. new technology
ORGANIZATION. implementation; see also
ORGANIZATIONAL EFFORT.
Business View A frequently used subset
of information, readily intelligible to Change Management 1. The complete set
users and defined in business terms, of processes employed on a project to
derived from definitions held in an ensure that changes are implemented in
entity model. It is based on one entity a visible, controlled and orderly
and can encompass renamed attributes fashion. 2. The activity, or set of
from the base entity or any other entity. activities, undertaken to govern
systematically the effects of
C organizational change.

Change Management Repository A


CASE see COMPUTER-AIDED SYSTEMS
system for maintaining configuration
ENGINEERING.
items. It provides other services such
CASE Tools A set of integrated as version control, access control and
Computer-Aided Systems Engineering information storage and retrieval which
(CASE) and application development support the configuration management
tools that assist in software process.
development, for example, analyzing
Change Readiness A measure of an
business requirements, designing
organization’s state of readiness to
applications, generating application
realize change successfully; involves a
code, etc.
consideration of an organization’s high-
CDM see CUSTOM DEVELOPMENT METHOD. impact leverage points for change, as
well as any change impediments.
Corporate Repository Location of a
collection of documentation, Change Request 1. A request for a change
customizations, modifications, or to the required behavior of a system,
enhancements designed to alleviate the usually from a user as a result of
recreation of successfully completed reviewing current behavior. 2. The
work. mechanism by which a change is
requested, investigated, resolved and
Change A deviation from a currently approved; see also IMPACT ANALYSIS.
established baseline.

Oracle Method Glossary G - 7


Class..A class refers to the delivery Company Baseline The Company
training to students on a certain Baseline is the supported configuration
topic(s). Usually, training is provided of hardware, software, bug patches,
regarding Oracle applicaitons such as modifications, operating systems, etc.
Bill of Materials, Work in Process, etc. that is part of a common set of business
Training may ablso be provided systems for the entire enterprise. There
regarding job policy and procedures, may be lower level of Company
Help Desk operations, etc. Baselines such as a Latin America
Baseline that is a subset of the
Client/Server A type of technical Company Baseline.
architecture that links many personal
computers or workstations (clients) to Completion Criteria Standards or rules
one or more large processors (servers). which determine completion of a task
Clients generally manage the user to an acceptable level of quality.
interface, possibly with some local
data. Servers usually manage multiple- Computer-Aided Systems Engineering
access databases, including ensuring (CASE) The combination of graphical,
data integrity and other invariants; see dictionary, generator, project
also INVARIANT. management, and other software tools
to assist computer development staff
Class Session..A class session consists of engineer and maintain high-quality
delivering a class to a specific set of systems, within the framework of a
students at a particular place and time. structured method.

Column A means of implementing an Computer Network An interconnected


item of data within a table. It can be in group of computers.
character, date, or number format, and
be optional or mandatory. Conceptual Architecture A high level
model of an enterprise’s business
Common Business Function A business application that identifies the
function that appears in more than one organizational and geographical
place in a hierarchy. deployment of the most critical
application systems and the technology
Company A commercial business; see also components required to support them..
BUSINESS. This model provides the direction for
the detailed enterprise technical
Company Base Hardware Configuration architecture analysis. It should reflect
The actual hardware configuration that the vision of the client senior executive
supports the company base management for the future direction of
configuration; see also COMPANY the information systems in the
BASELINE. enterprise.

Conference Room Pilot A system test in


an en