Aim - Oracle Application Implementation

ORACLE METHODSM

APPLICATION

IMPLEMENTATION

METHOD HANDBOOK

Release 2.0.0July, 1997

®

Enabling the Information Age™

Application Implementation Method (AIM) Method Handbook, Release 2.0.0Part 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, orother inherently dangerous applications. It shall be licensee’s responsibility to take allappropriate fail-safe, back up, redundancy and other measures to ensure the safe use ofsuch applications if the Programs are used for such purposes, and Oracle disclaimsliability for any damages caused by such use of the Programs.

This software/documentation contains proprietary information of Oracle Corporation; it isprovided under a license agreement containing restrictions on use and disclosure and isalso protected by copyright law. Reverse engineering of the software is prohibited.

If this software/documentation is delivered to a U.S. Government Agency of theDepartment of Defense, then it is delivered with Restricted Rights and the following legendis applicable:

Restricted Rights Legend Programs delivered subject to the DOD FAR Supplementare ‘commercial computer software’ and use, duplication and disclosure of thePrograms shall be subject to the licensing restrictions set forth in the applicable Oraclelicense agreement. Otherwise, Programs delivered subject to the Federal AcquisitionRegulations are ‘restricted computer software’ and use, duplication and disclosure ofthe 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 findany problems in the documentation, please report them to us in writing. OracleCorporation 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 registeredtrademarks 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 ofMaterial, Oracle Engineering, Oracle Capacity, Oracle Commissions, Oracle MasterScheduling, Oracle MRP, Oracle Work in Process, Oracle General Ledger, Oracle Assets,Oracle Order Entry, Oracle Cost Management, Oracle Payables, Oracle Receivables, OraclePersonnel, 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 isa trademark of Visio Corporation. Project Workbench and Project Bridge Modeler areregistered trademarks of Applied Business Technology. All other company or productnames mentioned are used for identification purposes only and may be trademarks of theirrespective owners.

Oracle Method Preface i

Preface

he Application Implementation Method Handbook provides an overviewof 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 applicationimplementation effort and to plan and execute AIM projects.

This handbook, and the Application Implementation Method itself, arepart of Oracle MethodSM —Oracle’s integrated approach to solutiondelivery.

T

ii Preface AIM Method Handbook

Audience

The Application Implementation Method Handbook is a high-leveldescription of how AIM can be used to facilitate implementationprojects. Project managers will use this handbook for project planningand scheduling. Team members can use this book to gain a broadunderstanding of AIM. It also provides a context for the detailedinformation in the Process and Task Reference manual.

How the Manual is Organized

This handbook consists of an overview of AIM, chapters on each AIMphase, and several appendices.

Introduction: This chapter presents an overview of AIM and how todetermine a project approach. It provides guidance in estimatingresources and discusses how AIM incorporates Oracle’s ProjectManagement Method (PJM).

Phase Chapters: Each phase chapter consists of a phase overview and asection on the approach to completing that phase. The chapters providethe 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 keydeliverables

• 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 thephase

Oracle Method Preface iii

Approach:

• Tasks and Deliverables – lists the tasks executed and thedeliverables produced

• Task Dependencies – illustrates the dependencies between tasks

• Managing Risks – provides assistance in reducing the risksassociated with this phase

• Tips and Techniques – discusses helpful tips and techniques

• Estimating – illustrates the relative effort of tasks within thephase 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 forthe Classic approach.

Appendix B: Appendix B provides a description of the roles used inAIM.

Appendix C: Appendix C lists the roles used in AIM, the tasksperformed by each role, and the percentage of task time assigned to therole.

Appendix D: Appendix D provides the AIM data model, includingentities and their relationships, as well as definitions and entityexamples.

Glossary: The Glossary contains definitions of terms, abbreviations,and acronyms used in AIM.

How to Use this Manual

The Application Implementation Method Handbook contains generalinformation about using AIM for application implementation projects.Use this handbook in conjunction with the Application ImplementationProcess and Task Reference, which provides detailed information onprocesses and tasks. Together, the handbook and reference provide acomplete guide for planning and executing applicationimplementations.

iv Preface AIM Method Handbook

Conventions Used in this Manual

Several notational conventions are used to make this handbook easy toread.

Capitalization

Names of tasks, deliverables, processes, and phases are given initialcapitals. For example, Gather Business Volumes task, Business VolumeRequirements deliverable, Business Requirements Definition process,and Design phase.

Abbreviations and Acronyms

Occasionally, it is necessary to use abbreviations and acronyms whenadequate space is not available. The Glossary lists definitions of allacronyms and abbreviations.

Suggestions

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

Suggestion: Verify your backup and recovery plan with yourhardware and software vendors.

Attention

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

Attention: Since project team training occurs simultaneouslywith this task, some recommendations (or decisions) fromtraining may be implemented in the mapping environment.In this case, these training inputs become predecessors to thistask.

For More Information

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

Oracle Method Preface v

Reference: Hickman, Linda and Longman, Cliff Case*MethodBusiness Interviewing. Addison-Wesley. 1994ISBN 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 inA 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

vi Preface AIM Method Handbook

Your Comments are Welcome

Oracle Corporation values and appreciates your comments as an OracleAIM practitioner and reader of the handbook. As we write, revise, andevaluate our documentation, your comments are the most valuableinput we receive. If you would like to contact us regarding thisreference or any other AIM or Oracle Method manuals, please use thefollowing address:

Oracle Method - Application Implementation GroupOracle Corporation500 Oracle ParkwayMailstop 30P16Redwood Shores, CA 94065

For email inquiries use the following Internet address:

[email protected]

Please provide the following information:

• AIM user name

• company name

• company address

• telephone number

Please use these channels to send comments only. Contact your localOracle Consulting Services office for technical questions about using thesoftware tools.

Oracle Method Contents vii

CONTENTS

C H A P T E R 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-15Selecting an AIM Implementation Approach................................. 1-18Multiple Deployment Phase Considerations .................................. 1-21Level of Process/Requirements Analysis ....................................... 1-22Acceleration Techniques .................................................................. 1-23

Estimating AIM Projects ......................................................................... 1-28

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

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

C H A P T E R 2 Definition ..................................................................................................2-1

Overview....................................................................................................2-2

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

viii Contents AIM Method Handbook

Key Deliverables ................................................................................. 2-7

Approach.................................................................................................. 2-10

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

C H A P T E R 3 Operations Analysis................................................................................. 3-1

Overview.................................................................................................... 3-2

Objectives ............................................................................................ 3-2Critical Success Factors ...................................................................... 3-2Overview Table................................................................................... 3-3Prerequisites........................................................................................ 3-5Processes.............................................................................................. 3-6Key Deliverables ................................................................................. 3-8

Approach.................................................................................................. 3-13


C H A P T E R 4 Solution Design........................................................................................ 4-1

Overview.................................................................................................... 4-2


Approach.................................................................................................. 4-13

Tasks and Deliverables..................................................................... 4-13Task Dependencies ........................................................................... 4-16Managing Risks................................................................................. 4-20

Oracle Method Contents ix

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

C H A P T E R 5 Build ...........................................................................................................5-1

Overview....................................................................................................5-2

Objectives ............................................................................................5-2Critical Success Factors ......................................................................5-2Overview Table...................................................................................5-3Prerequisites ........................................................................................5-5Processes..............................................................................................5-8Key Deliverables .................................................................................5-9

Approach.................................................................................................. 5-13


C H A P T E R 6 Transition...................................................................................................6-1

Overview....................................................................................................6-2

Objectives ............................................................................................6-2Critical Success Factors ......................................................................6-2Overview Table...................................................................................6-3Prerequisites ........................................................................................6-5Processes..............................................................................................6-6Key Deliverables .................................................................................6-7

Approach....................................................................................................6-9

Tasks and Deliverables.......................................................................6-9Task Dependencies ........................................................................... 6-10Managing Risks................................................................................. 6-12Tips and Techniques......................................................................... 6-13Estimating.......................................................................................... 6-16Scheduling ......................................................................................... 6-18Staffing............................................................................................... 6-20

x Contents AIM Method Handbook

C H A P T E R 7 Production ................................................................................................. 7-1

Overview.................................................................................................... 7-2


Approach.................................................................................................... 7-7

Tasks and Deliverables....................................................................... 7-7Task Dependencies ............................................................................. 7-8Managing Risks................................................................................... 7-9Tips and Techniques........................................................................... 7-9Estimating.......................................................................................... 7-12Scheduling ......................................................................................... 7-14Staffing............................................................................................... 7-16

A P P E N D I X A AIM Work Breakdown Structure ..........................................................A-1

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

A P P E N D I X B AIM Roles................................................................................................. B-1

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

A P P E N D I X C Role Usages .............................................................................................. C-1

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

A P P E N D I X 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-4Relationship to the AIM Glossary ....................................................D-4Data Object Definitions .....................................................................D-4

GLOSSARY

Oracle Method Introduction to AIM 1 - 1

C H A P T E R

1 Introduction to AIM

his chapter discusses the content and structure of Oracle’sApplication Implementation Method (AIM).

Business Requirements Definition

Business Requirements Mapping

Application and Technical Architecture

Module Design and Build

Documentation

Performance Testing

Training

Production Migration

Business System Testing

Data Conversion

Figure 1-1 Application Implementation Process Overview Diagram

T

1 - 2 Introduction to AIM AIM Method Handbook

What is AIM?

Oracle’s Application Implementation Method (AIM) is a provenapproach for implementing packaged applications. It is comprised ofwell-defined processes that can be managed in several ways to guideyou through an application implementation project. AIM provides thetools needed to effectively and efficiently plan, conduct, and controlproject steps to successfully implement business solutions.

AIM defines business needs at the beginning of the project andmaintains their visibility throughout the implementation. It definesinternal, external, and time-sensitive business events and maps eachevent to the responding business and system processes. Using thismethod, the business community gains an accurate understanding ofthe 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 beused in Oracle Applications projects, with minor changes in technique,AIM can be applied to other technologies and appropriate products aswell.

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


Processes in AIM

AIM tasks are organized into processes. Each process represents arelated set of objectives, resource skill requirements, inputs, anddeliverable outputs. A task can belong to only one process. Projectteam members are usually assigned to a process according to theirspecialization and background.

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





Documentation

Performance Testing

Training



Data Conversion

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


• Training

• Production Migration


Business Requirements Definition defines the business needs that mustbe met by the implementation project. You document businessprocesses by identifying business events and describing the steps thatrespond to these events. You then organize processes into scenariosthat reflect the business requirements. The project team conducts aCurrent Business Baseline to ensure requirements are considered, thenconstructs future business process and function models to portrayfuture business requirements.

As part of Business Requirements Definition, the company’s financialand operating structure is identified, business transactions volumes aredocumented, and storage requirements are determined. Audit andcontrol considerations for financial and system administration furtherdefine security and operating requirements.


Business Requirements Mapping compares the business requirements tostandard application software functionality and identifies gaps thatmust be addressed to fully meet business needs. Mapping teams areassigned groups of future business processes, usually related bybusiness function. Business Requirements Scenarios are then mapped toapplication functionality.

As gaps between requirements and functionality emerge, they areresolved by documenting workarounds, alternative solutions,application extensions, or by changing the underlying business process.

After business processes have been mapped to the application and gapsresolved, the project team documents how the business will operateusing the new system.


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

• Oracle, third-party, and custom applications


• supporting application databases

• critical enterprise interfaces and data distribution mechanismsbetween applications, servers, and data centers

• computing hardware including servers and client desktopmachines

• networks and the data communications infrastructure

A coherent and well-designed information systems architecture is acritical success factor for any implementation project. The informationsystems architecture design should be:

• derived from balanced input of business and technicalrequirements

• consistent with the corporate business vision and provide theinformation technology framework to achieve it

• realistic about the capabilities and limitations of the technologyon which it is based

The first bullet above is especially important because the architecturepart of an implementation project is often considered to be purelytechnical in nature, with the resulting risk that the businessrequirements are treated as subservient to the technology. A well-managed architecture project uses the business requirements andfunctional mapping as drivers for:

• optimal configuration of the applications being implemented

• hardware and network infrastructure providing the applicationsprocessing

• tools and procedures needed to manage the complete system

To arrive at an architecture for the newly implemented systems, thearchitecture team may need to consider the following types of complexissues:

• the best deployment strategy for the applications across one ormore data centers, business organizations, and business functions

• the high-level configuration of the applications to supportfinancial, administration, manufacturing, and distributionbusiness units

• interface points between the applications and/or remote sites,including specifications, dataflows, and mechanisms


• the deployment and capacity planning for the hardware andnetwork infrastructure that will support the applicationsprocessing

• management tools and procedures that will enable the system tocontinue to operate as intended

Relative to other processes, the architecture process occurs early in animplementation project. While the formal process is active only duringDefinition, Operations Analysis, and Solution Design, architecturedeliverables are required and used throughout the entireimplementation project. This is because the architecture process definesthe framework for the technical aspects of the future system and also forthe project that is defining and creating the new system.

Both application and technical architecture designs become moredetailed and concrete as they progress from Definition throughOperations Analysis to Solution Design. It is important to consider bothaspects of architecture throughout the process so that a top-to-bottomview of the future system architecture is created early. Any issues thataffect the technical architecture can then be assessed in the context ofthe application architecture design, and vice versa.


Module Design and Build produces custom software solutions to gapsin functionality identified during Business Requirements Mapping.Custom software solutions include program modules (forms, reports,zooms, alerts, database triggers) that must be designed, built, and testedbefore they can be incorporated into the system. Module Design andBuild 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 thespecific custom extensions needed to support the requirements and thenestimate the work effort required to design and build the extensions.Module designers write functional and technical specifications for eachmodule that together comprise the detailed design. Programmers codenew modules or modify existing modules based on the detailed designdocuments.

Data Conversion

Data Conversion defines the tasks and deliverables required to convertlegacy data to the Oracle Applications tables. The first step of thisprocess explicitly defines the business objects that are required forconversion and the legacy source systems that store these objects. The


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

An overall strategy determines how the conversion requirements will bemet. Both automated and manual methods should be considered aspossible solutions. The conversion process includes designing, building,and testing the required conversion programs as well as the actualconversion of the legacy data.

Documentation

Documentation begins with materials created early in the project. Usingdetailed documents from the project, the writing staff develops user andtechnical material that is tailored to the implementation.

A complete documentation set includes a System Management Guide,User Guide, User Reference Manual, Technical Reference Manual andonline help text. Producing prototypes for each document encouragesearly consensus on documentation design, format, and content.


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

Business System Testing provides a formal integrated approach totesting. 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 aperformance test. It does not assume a particular scope for theperformance test. You can use the same process to define a complextest on an entire system, or a simpler test on a component or subset ofthe system. You may also initiate the process more than once on aproject with differing scope and objectives to test the performance ofdifferent aspects of your system. The specific goals of each process andthe relative timing within a project may be different, but the methodyou use can be the same.

As a primary benefit, this process provides a powerful and direct meansof assessing the performance quality of your system. Use the results to


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

The performance testing team defines the scope of testing and relates itto point-in-time snapshots of the transactions expected in the realproduction system. Technical analysts create or set up transactionprograms to simulate system processing within the scope of the test andpopulate a volume test database against which to execute thetransactions. Once the system and database administrators havecreated the test environment, the test is executed by the project teamand the final results are documented.

Training

Training prepares both users and administrators to take on the task ofrunning the new application system. It includes development ofmaterials and methods, as well as administration. Instructors andcourseware developers orient their material toward roles and jobs, andnot toward application modules.

AIM distinguishes between education and training. Education providesan understanding of the fundamentals of how the business operates in acertain type of environment; training refers to the Oracle products andskills courses.


Production Migration moves the company, system, and people to thenew enterprise system. Following production cutover, it monitors andrefines the production system and plans for the future. The ProductionMigration process encompasses transition to production readiness,production cutover, and post-production support.

During Production Migration, the project team deploys the finishedsolution into the organization. This transition depends on BusinessRequirements Mapping, Module Design and Build, Data Conversion,Business System Testing, Training, and Documentation for fully testedbusiness solutions, custom extensions, conversion programs,documentation, and training materials. Transition is complete whendata has been converted and verified and users have started using the


new system. When the system is stabilized, regular maintenance andsystem refinement begins. In addition, management begins preliminaryplanning of the company’s future business and technical direction as itrelates to the new systems.


AIM Project Phases

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

Definition OperationsAnalysis

SolutionDesign

Build ProductionTransition





Documentation

Performance Testing

Training



Data Conversion

Figure 1-3 AIM Context Diagram

Following is a description of each AIM phase:

Definition

During Definition you plan the project, review the organization’sbusiness objectives, and evaluate the feasibility of meeting thoseobjectives under time, resource, and budget constraints. The emphasisis on building an achievable workplan and introducing it withguidelines on how the organization will work to achieve commonobjectives. Establishing scope early in the implementation gives theteam a common reference point and an effective way to communicate.Strategies, objectives, and approaches are determined for each AIMprocess, providing the basis for the project plan.

To achieve an early understanding of current business operations andfuture processes, the team also performs baselining and processmodeling during this phase.


The goal is to identify business and system requirements, propose thefuture business model, and determine the current application andinformation technology architecture. The information gatheredprovides input to downstream activities in subsequent phases. Theteam reviews financial, operational, technical, and administrativeprocesses to verify that everyone understands and agrees on thedetailed business requirements. All business requirements areassociated with planned future business processes. Sharing an accurateunderstanding of these requirements is a critical success factor to theproject.

Operations Analysis

During Operations Analysis, the project team develops BusinessRequirements Scenarios based on deliverables from Definition that areused to assess the level of fit between the business requirements andstandard application functionality. Gaps are identified andcorresponding solutions developed. The analysis results in a proposalfor conducting business operations under the envisioned applicationtechnical architecture. Solutions for gaps evolve into detailed designsduring Solution Design.

A model for the application architecture is created and the technicalarchitecture is designed. The technical architecture includes high-levelhardware, software, and communications components to support thefuture business system. The Application and Technical Architecturedocuments are used to develop detailed designs during SolutionDesign.

To develop models of future business operations you must verify yourinitial assumptions regarding solutions for gaps. Solutions may requireonly minor modifications to forms, reports, and programs. The teamshould explore workarounds to application gaps before consideringcustom modifications or new development. If solutions require customdevelopment, the team prepares high-level solution documents. Thesedocuments include general descriptions of the required features and awork estimate for each customization. The customization approach andestimates are approved before detailed design begins during SolutionDesign.

The Performance Testing team creates models for testing theperformance characteristics of the new system. These models usuallyfocus on critical system processing associated with key businessfunctions and transactions.


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

Solution Design

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

Supporting business requirements may require building applicationextensions to standard features; several alternative solutions may havebeen defined during Operations Analysis. The project team carefullyscrutinizes these solutions and chooses the most cost effectivealternatives.

To design effective business solutions, you should make sure thatplanned user roles and job procedures are efficient. When designingsolutions, consider organizational changes, process improvement, andreengineering 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 technicalarchitecture begins to take form. The technical staff designs a technicalarchitecture that can support the standard application configuration andcustom solutions and considers the future system architecture needs ofthe company. The technical staff also designs performance testingprograms and the environment for executing the performance tests.

As solutions to business requirements are created you will begin todevelop operating documentation. As the system is refined thedocumentation is revised.

Business process design is iterative. Tasks that span both OperationsAnalysis and Solution Design may be performed as a unit by a designteam.

Build

The coding and testing of all customizations and other custom softwareincluding enhancements, data conversions, and interfaces are doneduring Build. Policy and procedure changes relating to businessprocess modifications are developed. Business system testing isperformed to validate that the developed solutions meet businessrequirements.


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

During Build the performance testing team creates performance testingcomponents and executes the performance tests. Developers produceunit-tested program modules. Integration, performance, and businesssystem tests are performed and a working, tested business systemsolution is delivered at the end of the phase.

Transition

During Transition, the project team deploys the finished solution intothe organization. All the elements of the implementation must cometogether to transition successfully to actual production. The projectteam trains the end users while the technical team configures theproduction environment and converts data. Transition ends with thecutover to production, when end users start performing their job dutiesusing the new system.

Transition is a demanding experience for the project team and, inparticular, for the end users who have to maintain two systems untilproduction is declared. Managing changes and buffering yourorganizations 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 mayconsist of multiple deployments where subsets of the applications maybe deployed to various geographical sites and/or business units atdifferent times.

Production

Production begins immediately with the production cutover. It marksthe last phase of the implementation, and the beginning of the systemsupport cycle. Included in this final phase is a series of refinements andperformance measurement steps. The Information Systems (IS)personnel work quickly to stabilize the system and begin regularmaintenance. They will provide the ongoing support to theorganization for the remaining life of the system. During Production,you compare actual results to project objectives. System refinementbegins in a controlled manner to minimize impact to end users. Finally,you start preliminary planning of the future business and technicaldirection of the company.


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


Determining a Project Approach

When deciding on the project approach for your implementationconsider the following dimensions:

• Scope—project objectives, business functions, sites, andapplications addressed

• Cost/Time/Quality—the balance among cost, implementationspeed, and quality in meeting requirements

• Risk—the potential of an adverse condition occurring that willimpact the project or the organization

• Track Record—the approaches that have or have not worked inthe past for this organization

• Resources—the resource constraints that affect the practicality ofcertain 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 impactthey can have on the success of the implementation.

Critical Success Factor Percent Impact

Internal/External toProject

Sufficient infrastructure 10 External

Clear understanding of businessneeds

15 External

Upper management support 20 External

Strong program/projectmanagement

20 Internal

Team strength 15 Internal


Critical Success Factor Percent Impact

Internal/External toProject

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 thedemands on the information systems infrastructure are too great.Determine how far you can realistically stretch the infrastructure over aspecific period of time.

Clear Understanding of Business Needs

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

Upper Management Support

Upper Management Responsibilities

Upper management has several key responsibilities that are connectedto 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 informationabout major planned or potential events that could impact theproject


Time/Budget/Quality Considerations

The project budget and schedule must be based on realistic estimateswith appropriate contingencies. If real time and budget constraintsexist, Project Management must work closely with upper managementto ensure an appropriate balance is reached. Frequently, time andbudget constraints are imposed before the project scope has beendetermined and a detailed project plan has been developed.

Strong Project Management

A strong project manager identifies problems, determines solutions, anddrives the solution process. An inexperienced or ineffective managermay be unable to identify problem areas that could escalate andnegatively impact the project. If high risk project approaches (such asFast Track implementations) are selected, strong project management isessential to complete the project successfully

The organization’s willingness or ability to delegate responsibility andcontrol to the project manager should also impact your selectionapproach. If complete responsibility and control is held by the projectmanager, communication with upper management can occur throughexception reporting and issues management. Frequently, incompletedelegation of authority results in responsibility without control. Inthese cases, the project manager may not be able to perform effectivelybecause he does not have the right level of decision making authority.Fast Track approaches are unusually dependent on fullproject/program management authority since decisions must be madequickly.

Team Strength

Capitalizing on individual and team strengths while compensating forweaknesses are critical factors affecting the project’s success. Potentialteam factors include:

• a strong team with a weak project manager may succeed, but therisk is high; a weak team with strong project management canbecome a strong, effective project team

• a group of strong individuals does not guarantee a strong team;teamwork is essential


Organizational Readiness

Application implementations cause change and change managementcan mean the difference between project success or failure. Projectmanagers should be tuned to organizational factors impacted by theproject, for example:

• Do various levels in the organization view the project as adesirable solution to current problems?

• Is the Information Systems department able to absorb newtechnology and support the project?

• What is the level of computer literacy? How many people will beusing an automated system for the first time?

• How stable is the organization? Change may be difficult for theuser community if it is also being driven by other initiatives.

• Are all levels of management ready? Authorizing a systemimplementation is different than managing the associatedorganizational changes.

• Did the user community participate in the system selection?Greater involvement can mean less resistance to subsequentchanges.

• If the applications will be deployed at various sites, are businessfunctions performed differently at each location?

• What is the organization’s strategy regarding centralized versusdecentralized planning and control?

• What is the history of system implementation and has it created apositive mindset regarding future projects?

Selecting an AIM Implementation Approach

AIM defines two implementation approaches:

AIM Classic

AIM processes are conducted with resources and timeframes optimizedfor low risk and quality.


AIM Fast Track

AIM processes are conducted with resources and timeframes optimizedto achieve the earliest possible go-live date. However, by acceleratingimplementation you assume a greater risk that some requirements maybe missed or you will not achieve the quality of a classicimplementation.

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

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

Table 1-2 summarizes some of the criteria you should consider inselecting a Classic or Fast Track implementation categorized by AIMprocess.

AIM Processes Classic Implementation Fast Track Implementation

Business RequirementsDefinition

Business requirements not wellunderstood.

Business processes documented andrequirements clearly defined andwell understood.

Business process changes areanticipated.

No significant changes to businessprocess that could impact the project.

Business RequirementsMapping

Moderate to substantial changesto the application software maybe performed.

Minimal application customizations.Gaps between requirements and thestandard application software will beresolved by changing businesspolicies and procedures.

Application andTechnical Architecture

Major shifts in computingparadigm, tools, andarchitecture.

Little change in technology; solid ISskill set.


AIM Processes Classic Implementation Fast Track Implementation

Organization has littleknowledge or experience in newarchitecture.

Sound expertise regarding plannedarchitecture.

Module Design andBuild

Significant application softwarechanges.

Few or no customizations.

Data Conversion Large conversion volumes andmoderate to complexconversion processes and tools.

Straightforward data conversion.

Documentation Significant customdocumentation required.

Few or no changes to standarddocumentation.

Business SystemTesting

Substantial business systemtesting required forcustomization, data conversion,interfaces.

Many complex businessprocesses.

Substantial business processchanges.

Small scope to the business systemtesting - few customizations, custominterfaces, and data conversions.

Few complex business processes.

Few business process changes.

Performance Testing Some performance testingrequired.

Sufficient hardware and networkcapacity clearly exists. Noperformance test required.

Training Requires custom developedmaterials and classes.

Standard training materials andclasses.

Production Migration Complex migration toproduction.

Simple cutover to production.

Table 1-2 Classic Versus Fast Track Implementation


Multiple Deployment Phase Considerations

Determine if the transition into production needs to occur for allorganizations at the same time. If a phased implementation is planned,decide what applications will be implemented in each phase. Thiscombination of choices presents four scenarios:

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

• Deploy all applications for different organizations at differenttimes.

• Deploy subsets of the applications for all organizations at thesame time.

• Deploy subsets of the applications for different organizations atdifferent times.

Consider the following factors when deciding on a single-phase ormultiple-phase deployment:

• Is the organization facing changes from other sectors? Allowtime for an organization to absorb major changes beforeintroducing new factors.

• Is the organizational culture amenable to integrating the newsystem into its operations? The risk will be less if theorganization is accustomed to using a common system withrelated policies and procedures. If business units have beenoperating independently the organization must adapt to acultural change as well as the new system.

• Can the project team adequately execute the project so that thereis minimal risk in implementing all applications for allorganizations at one time?

• What is the company’s experience with previous systemimplementations?

• What is the project team’s experience with previous systemimplementations?

• Is the application a production, controlled, or beta release of thesoftware?

To minimize risk, use the pilot implementation approach. Go live witha carefully selected subset of users who are well trained and able to dealwith initial problems.


Develop an interface between the applications and the existing systemso that transactions are posted to both systems. This allows theremainder of the organization to use the current system in parallel withthe pilot implementation. For example, journal entries could post to thenew General Ledger and to the existing General Ledger. This allowsconsolidated reporting from the current system until all regions are cutover.

Along with risk reduction, phased deployment adds complexity andcost to the project:

• The project duration is lengthened requiring the project team toremain 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 previousone. Production migration needs, startup demands, and supportrequirements are occurring in parallel.

• Peaks in computer resource utilization may occur during phaseoverlaps due to multiple application database instances beingneeded for training, data conversion, and production for thedeployment just ending, and start up tasks for the nextdeployment.

Level of Process/Requirements Analysis

The scope of process analysis and requirements definition activity canvary greatly. For example, the objective may be to minimizecustomizations by matching the business processes to the applications.Or the objective may be to change the applications to match the businessprocesses because of an overall strategy of minimizing changes tobusiness procedures.

If the organization intends to replace many business practices, theremay be little need for the team to assess or understand how business iscurrently done. On the other hand, if the strategy is to integrate theapplications into current processes, it is critical that the teamunderstand how the business is currently operating.

At a minimum, each current business process must be identified toensure everything is addressed by the project. Substantial time andexpense can be saved by minimizing current process analysis but thereis a tradeoff between cost, time, and risk.


Acceleration Techniques

In certain situations you may be able to condense the project durationby using acceleration techniques. This is how you can tailor the AIMWorkplan and use a Fast Track implementation approach.

Project Management (PJM) imposes phase start and completioncheckpoints that are valuable for project management and control butmay disrupt natural process/task overlap opportunities and projectflow.

In large, complex implementations, the formal phase signoffs areneeded for scope and risk management. The Classic implementationapproach 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 anacceptable 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 processesfollow:

Definition

Definition should always be a standalone phase. Have a milestone andphase-end checkpoint after Definition and use it to reassess the futureproject 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 apopular approach, but incurs greater risk because the OperationsAnalysis checkpoint is removed. The full vision of the future systemdoes not emerge until Solution Design is nearing completion. Thistechnique 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. Thistechnique offers economies in projects with numerous customizations,but there is a risk of non-integrated designs and scope creep.


Operations Analysis, Solution Design and Build

Collapse the first three phases into a single super-phase. This is onlysuitable for small scale projects that are easy to control and that usealternative risk mitigation steps.

Other considerations:

• If there is uncertainty regarding any aspect of the project, use theclassic approach to assure good checkpoint and risk management.

• By using multiple parallel business process definition/mapping,teams can speed up Definition and Operations Analysis. Mitigaterisk for this technique by assigning a specific process/solutionteam to ensure cross-process integration. Use a project datarepository such as Designer/2000 for custom developedsolutions. The repository automatically cross-validates designsand enforces integrated solutions.

• If there are minimal large, complex customizations, begin workon them early because of the timeframes required for designing,building, and testing major customizations. It may be possible toselectively overlap specific customizations. To further mitigaterisk, define a formal subproject specifically for a givencustomization.

Process Teams for Requirements Definition and Mapping

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

Business requirements scenarios created during Definition will bemapped to the applications during Operations Analysis. The processteams create scenarios that represent how the process driven businessrequirements can be satisfied using the standard application features.The goal is to arrive at a solution that satisfies the business needs of theusers, resolves current system problems, and optimizes processefficiency. 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 teammembers, key users, and application consultants. The applicationconsultants enable features, set system parameters, and guide processmapping 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.


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

A repetitive implementation process task cycle for business processes areperformed multiple times for different subject areas. For example,Current Business Baseline, Future Process Model, BusinessRequirements Scenarios, and Business Requirements Mapping Formwill occur for each business process. An example is shown in thefollowing diagram:

Baselining

Testing

Business

Solutions

Requirements

Mapping

Modeling

Define FutureProcess and

Function Model(ProcurementProcesses)

CurrentBusinessBaseline

(ReceivingProcesses)


Function Model(Payment

Processes)

CurrentBusinessBaseline

(ProcurementProcesses)

CurrentBusinessBaseline(Payment

Processes)


Function Model(ReceivingProcesses)

Defining Business

Scenarios

Define BusinessRequirements

Scenarios(ProcurementProcesses)


Scenarios(ReceivingProcesses)


Scenarios(Payment

Processes)

Map BusinessRequirements(ProcurementProcesses)

Map BusinessRequirements

(ReceivingProcesses)


(PaymentProcesses)

Test BusinessSolutions

(ProcurementProcesses)

Test BusinessSolutions(ReceivingProcesses)

Test BusinessSolutions(Payment

Processes)

Figure 1-4 Repetitive Implementation Process Task Cycle Example


Acceleration Techniques for Module Design and Build

Multiple Tasks for Program Modules

The default Project Workplan for AIM includes a single task for CreateCustom Modules. In reality, this task must be repeated for all thecustomizations, conversions, and interfaces required by the project.When preparing a detailed project plan, add tasks for each individualprogram module that must be built and tested. This gives you theflexibility to assign several programmers to the construction tasks andperform resource leveling to derive the detailed schedule. There mayalso be opportunities for parallel development that can be identifiedusing this technique.

Prioritization for Customizations

Some customizations identified during Solution Design may not becritical for initial production cutover. By delaying these Build activitiesyou can move to Business System Testing and Production Migrationmore quickly. Development of these less important programs cancontinue in parallel with other activities, but are introduced afterproduction.

Schedule Optimization

Work closely with the designers so that you can define the inter-moduledependencies in the project plan. You may also wish to assign prioritiesso that the auto-leveling feature of your project planning tool cangenerate an appropriate schedule. We recommend that you useresource-driven scheduling for program construction tasks so thatmultiple resources can be most efficiently utilized. Fixed-durationscheduling can be used for Business System Testing since additionalresources may be brought in during this process.

Parallel Design and Development

Since the primary predecessor for program construction is the detaileddesign document, the project plan may include Build activities inparallel with Solution Design activities. If development is accelerated inthis way, some of the assumptions incorporated into earlier designscould change when later designs are developed, which may require thatthe earlier designs are revisited and the related programs updated orrewritten. This approach could also shorten the lead-time of ModuleDesign and Build.


Project Tracking

Careful attention to progress reporting, signoffs, and scope control areparticularly important while managing Solution Design. Includefrequent checkpoints and milestones so that you always know the statusof the project.


Estimating AIM Projects

The preliminary application implementation project estimate is basedon:

• 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 theoverall vision?

• Who will participate in the project (employees, consultants,vendors)?

• What are the constraints affecting the project (timing or budgetlimitations, organization changes)?

• Which applications will be implemented?

• What sites will be involved?

• Will a phased deployment approach be employed? If so, in whatsequence will the applications be implemented?

• When will work commence?

• What experience does the organization have regarding thetechnology that will be used?

Before creating a detailed work plan, develop the project scope,suggested approach, and preliminary budget. Use an iterative processwhere different project scenarios are defined at a summary level andthen estimated.

Generally accepted industry practices include using experience andresults from similar projects to develop estimates for the differentscenarios.

The final budget should be developed using a detailed bottom upestimating process based on the detailed work plan. This project planshould include:

• Work Breakdown Structure (WBS)

• Resource Assignments


• Dependencies

• Deliverables

• Dependency Relationships

Appropriate contingencies should be included in the estimate. Use theplan 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 fordeveloping the detailed work breakdown structure and contain all theAIM tasks with associated dependencies, project roles, and deliverablenames.

Table 1-3 summarizes Oracle’s experience in medium size projects. Itpresents a “Process as a Percentage of Project Effort” view that is theresult of using the detailed bottom up model. Each cell represents theprocess’ percentage of project effort in that phase. The table sums downfor phase totals and across for process totals. For example, SolutionDesign is the most work intensive phase of the project and requires 30percent of the project work effort.

Process (as % of Project Effort) Def

initi

on

Ope

ratio

ns

Ana

lysi

s

Sol

utio

n D

esig

n

Bui

ld

Tra

nsiti

on

Pro

duct

ion

Tot

al

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 yourimplementation.

The following table summarizes Oracle’s experience in medium-sizeprojects as a “Process Effort as a Percentage of Phase.” Each cell in the


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

Process (% of Phase Effort) Def

initi

on

Ope

ratio

ns

Ana

lysi

s

Sol

utio

n D

esig

n

Bui

ld

Tra

nsiti

on

Pro

duct

ion

% o

f Tot

al

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 Conversion 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 tablesthat detail the percentage of task distributions by process for the projectroles in that phase.


Managing an AIM Project

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

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

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

• Control and Reporting determines the scope and approach of theproject, manages change, and controls risks. It contains guidesfor reporting progress status externally and for controlling theQuality Plan.

• Work Management defines, monitors, and directs the workperformed on the project. It also maintains the financial view ofthe project for Oracle management.

• Resource Management determines the right level of staffing andskills for the project, and the working environment to supportthem.

• Quality Management implements quality measures to ensurethat the project meets the organization’s purpose andexpectations throughout the project life-cycle.

• Configuration Management stores, organizes, tracks, andcontrols all items produced from and delivered to the project. Italso provides a single location from which all project deliverablesare published.

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


• Project Planning defines the project scope, quality, timeline, andcost. It also determines the appropriate organization of resourcesand assigns responsibilities for project tasks.

• Phase Planning tasks update project plans and procedures forthe phase.

• Phase Control tasks execute concurrently with the phaseexecution. They perform project monitoring, directing, andreporting functions.

• Phase Completion tasks conclude and secure sign-off of a phase.

• Project Completion results in the satisfactory conclusion of theproject and settlement of all outstanding issues prior to shuttingdown the project.

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

ProjectPlanning

Planning Control Completion

ProjectCompletion

Control and Reporting

Work Management

Resource Management

Quality Management

Configuration Management

Phase Management

Figure 1-5 Project Management Life-cycle

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


Control

InitialPhase

IntermediatePhases

FinalPhase

Control Control

Execution Execution Execution

Project Planning

Phase Planning

Phase Control

Phase Completion

Project Completion

Figure 1-6 Managing an AIM Project

For more information on PJM, refer to the Oracle Method ProjectManagement 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 thatcan be tailored to specific user needs. For example, you can combinetasks from a business process re-engineering project with yourapplication 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 addresswithin the following risk areas:

• Plan resources.

• Track budget to actuals.

• Adhere to project scope and terms.


• Follow an efficient and complete design, build, and transitionroute.

• 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 thetasks and dependencies in your workplan. If a hybrid method will beused, ensure that the dependencies are preserved.

Adding and Removing Tasks

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

Customizing Templates and Deliverables

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

Working on Multi-site/Multi-phase Projects

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


Using AIM with a User Method

Sometimes a project team member or user wishes to use their ownproject method. When this occurs, do a detailed fit and gap analysisbetween the methods. For any identified gaps, incorporate theappropriate AIM tasks and dependencies into the user’s method. Makesure that the associated deliverables will be produced and develop agap strategy for all remaining open issues.

Oracle Method Definition 2 - 1

C H A P T E R

2 Definition

his chapter describes the Definition phase of AIM. The goal ofDefinition is to determine the business and information system’s

high-level requirements necessary to meet a set of defined businessobjectives.


SolutionDesign






Documentation

Performance Testing

Training



Data Conversion

Figure 2-1 Context of AIM Definition Phase

T

2 - 2 Definition AIM Method Handbook

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 businessobjectives.

• Develop a high-level conceptual architecture.

• Determine the high-level architectural, technological, andconfiguration requirements to support the functional andinformation needs of the application.

• Defines the project scope clearly.

• Obtain management approval to proceed with OperationsAnalysis.

• Optional: Examine the existing business processes andinformation systems affected by the project’s defined businessobjectives.


The critical success factors for Definition follow:

• clear definition of the business objectives to be addressed

• active participation by key management and knowledgeable userand technical representatives from the areas of the businessaffected by the project’s objectives

• access to information related to the existing business processesand systems affected by the project

• detailed, thorough, and documented process modeling sessions

• effective project management of scope and issues

• sufficient time and resources


Overview Table

This table illustrates the prerequisites, processes, and key deliverablesfor Definition.

Process Prerequisites Key Deliverables


Business Process ReengineeringStudies

Business Volume Requirements

Existing Reference Material Current Business Baseline

Future Business Strategy Financial and Operations Structure

High-Level Existing System DataModel

Future Business Function Model

Original Justification for BusinessSystems Investment

Future Process Model

Sales and Presales Material Process and Mapping Summary

Application and TechnicalArchitecture

Architecture Designs and TechnicalDocuments from Sales Cycle

Architecture Scope, Objectives andApproach

Existing System Architecture orTechnical ConfigurationDocuments

Architecture Requirements

Existing System ManagementProcedures Documents

Architecture Strategy

Existing Systems ArchitectureStrategy or Policy Documents

Conceptual Architecture

Technical Architecture Baseline

Module Design and Build Customization Strategy



Data Conversion Legacy System Documentation Conversion Scope, Objectives andApproach

Conversion Strategy

Documentation Business Documentation Standardsand Guidelines

Glossary DocumentationRequirements

Documentation Standards andProcedures

Performance Testing Application User Manuals Performance Test Scope, Objectivesand Approach

Performance Testing Strategy

Training Training Material Standards andGuidelines

Education and Training Plan

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 tocreate them during Definition.

Prerequisite Source

Application Manuals Client

Architecture Designs and TechnicalDocuments from Sales Cycle

Client

Business Documentation Standards Client

Business Process ReengineeringStudies

Client


Prerequisite Source

Existing Reference Material Client

Existing Systems ArchitectureStrategy or Policy Documents

Client

Existing System Architecture orTechnical Configuration Documents

Client

Existing System ManagementProcedures Documents

Client

Future Business Strategy Client

High-level Existing System DataModel

Client

Legacy System Documentation andGuidelines

Client

Original Justification for BusinessSystems Investment

Client

Performance Testing Standards andGuidelines

Client

Sales and Presales Material Client

Table 2-2 Definition Phase Prerequisites


Processes

The processes used in this phase follow:


Complete baseline understanding of current events and businessprocesses. Develop process and function models of future businessoperations. Gather volumes of business transactions and storagerequirements. Establish repository of key process and mappinginformation, as well as decisions.


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


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

Data Conversion

Define the Conversion Scope, Objectives, and Approach, and preparethe Conversion Strategy.

Documentation

Define a glossary of terms for the project. Specify the documentationrequirements and determine the documentation standards andprocedures.

Performance Testing

Identify the scope, objectives, and strategy you will use for theperformance testing process, including measurements to make, testingmethods, and testing tools.


Training

Plan education and training for the project team. Deliver skills andapplications education to prepare team members for process modelingand requirements definition.

Key Deliverables

The key deliverables of this phase follow:

Deliverable Description

Architecture Requirements Documents the high-levelrequirements for the architecture ofthe new systems. The requirementsare classified by whether or not theyconstitute policies for the newbusiness systems.

Architecture Scope,Objectives, and Approach

Documents the scope of thearchitecture process, the objectives ofthe design, and the approach thatyou will use. This is created if amore precise definition of scope,objectives, and approach is neededfor an architecture subproject.

Architecture Strategy Documents the strategy that you willuse for the architecture process. Itincludes a discussion of the methods,tools, and techniques that you willemploy to perform the work outlinedin the scope document.

Business VolumeRequirements

Inventory of key transaction and datavolumes by business functional area.



Conceptual Architecture Documents the conceptualarchitecture for the new systems. Itis a high-level view of the newapplication and technical architectureand is intended as a working modelfor the architecture work and for thebroader project team. It is also theprimary vehicle for communicationof the future information system’sarchitecture to management.

Conversion Scope,Objectives, and Approach

The conversion requirements andrelated scope, objectives, andapproach.

Conversion Strategy The conversion strategy forimplementing the defined conversionrequirements.

Current Business Baseline An analysis of the current businessprocesses and functions.

Customization Strategy A strategy document that describeshow the project will respond tocustomization requests.

DocumentationRequirements

The business needs that must be metby project documentation.

Documentation Standardsand Procedures

The standards and procedures to beapplied to project documentation.

Education and Training Plan Contains the training schedule forcourses. Determines the resourcesneeded for preparing training andholding the session. Also assessesgeneral education course needs.

Financial and OperatingStructure

A depiction of the financial structureand the operating organizations ofthe company.



Future Business FunctionModel

Catalogs the elementary functions tobe supported within future businessprocesses.

Future Process Models Contains Process Flow Diagrams ofthe events and business processesthat will be supported by theapplications and functions of thebusiness area.

Glossary Documents the definitions of keyterms used throughout the project.

Performance Testing Scope,Objectives, and Approach

Documents the scope of theperformance testing process, theobjectives of the testing, and theapproach that you will use.

Performance TestingStrategy

Documents the strategy that you willuse for the performance testingprocess. It includes a discussion ofthe methods, tools, and techniquesthat you will employ to perform thework outlined in the scopedocument.

Process and MappingSummary

A summary of key processes,business requirements, and mappingdecisions.

Technical ArchitectureBaseline

Documents technical informationabout the existing legacy systems,including the applications, hardware,networks, and interfaces.

Trained Project Team Project Team members qualified totransfer knowledge to theconstituents they represent.

Table 2-3 Definition Phase Key Deliverables


Approach

This section describes the approach for Definition.

Tasks and Deliverables

This table lists the tasks executed and the deliverables produced duringDefinition.

ID Task Deliverable

Business Requirements DefinitionRD.010 Identify Financial and Operating Structure Financial and Operating StructureRD.020 Conduct Current Business Baseline Current Business BaselineRD.030 Develop Future Process Model Future Process ModelRD.040 Develop Future Business Function Model Future Business Function ModelRD.050 Establish Process and Mapping Summary Process and Mapping SummaryRD.060 Gather Business Volumes Business Volume RequirementsApplication and Technical ArchitectureTA.010 Define Architecture Scope, Objectives, and

ApproachArchitecture Scope, Objectives, andApproach

TA.020 Prepare Architecture Strategy Architecture StrategyTA.030 Establish Architectural Requirements Architecture RequirementsTA.040 Develop Conceptual Architecture Conceptual ArchitectureTA.050 Conduct Technical Architecture Baseline Technical Architecture BaselineModule Design and BuildMD.010 Prepare Customization Strategy Customization StrategyData ConversionCV.010 Define Conversion Scope, Objectives, and

ApproachConversion Scope, Objectives, andApproach

CV.020 Prepare Conversion Strategy Conversion StrategyDocumentationDO.010 Prepare Glossary GlossaryDO.020 Specify Documentation Requirements Documentation RequirementsDO.030 Determine Documentation Standards and

ProceduresDocumentation Standards andProcedures


ID Task Deliverable

Performance TestingPT.010 Define Performance Testing Scope, Objectives,

and ApproachPerformance Testing Scope,Objectives, and Approach

PT.020 Prepare Performance Testing Strategy Performance Testing StrategyTrainingTR.010 Prepare Training Strategy Education and Training PlanTR.030 Conduct General Education Classes Trained Project TeamTR.040 Conduct High-level Overview of Application

FeaturesTrained Project Team

Table 2-4 Definition Phase Tasks and Deliverables


Task Dependencies

This diagram shows the dependencies between tasks in Definition.

TR.040Conduct High-level

Overview ofApplicationFeaturesTR.040

RD030

Develop FutureProcess Model

RD.030

TR.010

Prepare TrainingStrategyTR.010

TA.030Establish

ArchitectureRequirements

TA.030

TA.020Prepare

ArchitectureStrategyTA.020 TA.050

Conduct TechnicalArchitecture

BaselineTA.050

PT.010Performance

Testing Scope,Objectives, and

ApproachPT.010

TA.010DefineArchitecture

Scope, Objectives,and Approach

TA.010

PT.020Prepare

PerformanceTesting Strategy

PT.020

TR.030

Conduct GeneralEducation Classes

TR.030

RD.020

Conduct CurrentBusiness Baseline

RD.020

RD.010Identify Financial

and OperatingStructureRD.010

BUSINESS

REQUIREMENTS

DEFINITION

DOCUMENTATION

MODULE DESIGN

AND BUILD

APPLICATION AND

TECHNICAL

ARCHITECTURE

DATA

CONVERSION

TRAINING

PERFORMANCE

TESTING

Definition

Figure 2-2 Definition Phase Task Dependencies


RD040Develop Future

Business FunctionModel

RD.040

TA.040Develop

ConceptualArchitecture

TA.040

RD.080

Gather BusinessVolumesRD.060

CV.010Define ConversionScope, Objectives,

and ApproachCV.010

CV.020Prepare

ConversionStrategyCV.020

MD.010Prepare

CustomizationStrategyMD.010

DO.010

Prepare GlossaryDO.010

DO.020Specify

DocumentationRequirements

DO.020

DO.030Determine

DocumentationStandards and

ProceduresDO.030

RD.050Establish Process

and MappingSummaryRD.050

BUSINESS

REQUIREMENTS

DEFINITION

DOCUMENTATION

MODULE DESIGN

AND BUILD

APPLICATION AND

TECHNICAL

ARCHITECTURE

DATA

CONVERSION

TRAINING

PERFORMANCE

TESTING

Definition

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


Managing Risks

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

Risk Mitigation

Management, users, orproject team not committedto the magnitude of change.

Have clearly stated objectives fromexecutive management and regularreporting to executive steeringcommittee.

The tendency to preserve oldprocesses and not developnew ones.

Select key area team leaders whosupport the need for change, canfacilitate change in their areas, andare knowledgeable about their areasand processes.

Knowledgeable users notinvolved in current andfuture process definition.

Assign a project sponsor role to aleader from the user community whocan promote a high level ofcommitment from key users and willnurture support for project teammembers as they work outside theirnormal jobs and duties.

Project team not adequatelytrained in process modelingtechniques.

Conduct process modeling sessionsfor team members; have themdemonstrate required skills with aqualified instructor.

Missed or incompleteprocesses and unidentifiedevents.

Have functional executivemanagement review the integratedprocess model and event catalog forcompleteness.

Process model does nottightly couple all integratedprocesses.

Have representatives from eachprocess team review the processmodels from other teams.

Insufficient data gathered onvolumes and processingwindows.

Have both functional andinformation processing managementreview and agree upon volume andprocessing windows.


Risk Mitigation

Incomplete definition ofscope for the architecturework.

Create a project organization thatenables input and consideration ofbusiness, functional, and technicalrequirements in architecture.

Treatment of the architectureas a purely technical pursuitand inadequate considerationof business requirements asdrivers for architecture(bottom-up approach).

Consider business requirements andfunctional mapping as well astechnical requirements as drivers forthe optimal configuration anddeployment of the applications beingimplemented.

Lack of project teamexpertise in applicationdeployment strategies oradvanced technicalarchitecture.

Screen project team candidates forprerequisite skills and experience.

Lack of involvement or sign-off by senior management ofkey architecture strategies,plans, and issue resolutions.

Communicate conceptualarchitectures to senior managementand organize a review, if appropriate.

Inadequate or non-existentquality assurance in theimplementation project.

Appoint a quality manager who hasresponsibilities for quality assuranceand enforcing review and approvalprocedures.

Imprecise definition of scopeand objectives forperformance testing, leadingto false conclusions .

Ensure that the scope and objectivesfor performance testing are madeclear by senior management, and thatthey understand what performancetesting can or cannot achieve orpredict.

Lack of a structured methodfor performance testing,leading to measurements thatare difficult to interpretrelative to the targetproduction system.

Use a structured method forperformance testing to ensure thatthe test results can be interpreted inthe context of their meaning for thereal production system.


Risk Mitigation

Lack of appreciation of thedependency of performancetesting on good qualityapplications setup data anddata conversion programs.

Have a member of the performancetesting team review the work anddeliverables relating to applicationsetup and conversion.

Lack of project resources toprovide a controlled,segregated performance testenvironment.

Plan ahead so that the requiredresources are available for thisactivity.

Conversion requirements,scope, and objectives notclearly defined.

Discuss conversion requirementswith the client early in the projectlife-cycle. Encourage the client tomake decisions that impact theconversion scope during Definition.

Conversion strategy notclearly documented andunderstood.

Make decisions about the conversionstrategy (such as using automatedconversion tools during Definition)and communicate this strategy to theclient.

Documentation standardsand procedures poorlydefined or incomplete.

Require documentation standardsand procedures input and approvalfrom key client areas involved inusing the final documentation.

Training requirements notfully developed.

Create a detailed set of trainingrequirements listing expected rolesthat 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. Inaddition, advice and comments on each process are included.



Business Requirements Definition begins in Definition with the task ofconstructing the current business baseline in order to understand theevents to which existing business processes currently respond. Thisexamination of current requirements expands to create a vision of howfuture processes and requirement scenarios will respond to thoseevents, as well as any additional ones anticipated by the company’sfuture business strategy. Model the future processes with both processmodels and function models to ensure sufficient breadth and depth ofprocess definition.

The operating and financial structure of the business entity affectsapplication and technical architecture definition as well as set up.Gather and formalize business volumes and use them to determinestorage and performance requirements.


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

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

The existing technical architecture of a business may or may not beimportant for the implementation of a new system, depending on thescope of the implementation. If the existing legacy systems are to be


completely or largely replaced and/or the project is a Fast Trackimplementation, gathering information about the existing systems maynot be necessary. Conversely, an implementation that will reuse theexisting business technical infrastructure, or will integrate withpreserved existing systems, may require additional work to understandthe technical components of the existing systems.

The application architect works closely with the technical architect tocreate a prototype architecture that satisfies the high-level business andinformation systems requirements and policies. The prototypeConceptual Architecture forms the basis of the architecture workingmodel for the project and covers both application and technicalarchitecture. After this stage the Conceptual Architecture is preliminaryand will be in a format that both non-technical project managers andsponsors can understand. If there are multiple architectural options,this deliverable should present the options and their tradeoffs, and thereview of the Conceptual Architecture will include a decision regardingwhich option to use as a working architecture model. Even in projectswhere the architecture is fairly clear cut (such as a single applicationinstallation on a single database server) creating a conceptual view ofthe architecture so that senior management understands the architectureand technical direction of their business can still be useful.


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

The Customization Strategy outlines the customization philosophy, suchas minimizing customization as much as possible. It also describes thedevelopment tools developers will use for each type of module.

An important part of the strategy is how much overlap is acceptablebetween phases. For example, some of the functional teams maycomplete their mapping earlier than others. Should designers beginwriting design documents for required custom extensions before otherteams have completed their mapping? After the team approves somedesign documents, should programmers begin building custommodules before other designs are completed? Allowing some overlapcan speed up the implementation; however, it increases the risk ofrework, since solutions arrived at later may affect earlier decisions.


Data Conversion

Definition provides the client with two deliverables that defineConversion Scope, Objectives, and Approach and Conversion Strategy.Detail the client’s conversion requirements (both programmatic andmanual conversion requirements) when defining Conversion Scope,Objectives, and Approach. These requirements then form thefoundation for documenting the Conversion Strategy. This strategyshould provide a complete solution for meeting the client’s conversionrequirements. If an automated tool provides the best conversionsolution for your client, then discuss this in the Conversion Strategydocument.

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

Documentation

The documentation process addresses the needs of users, technical, andoperations staff. Designate a key resource from each area as part of thecommittee that specifies documentation requirements, standards, andprocedures. The detailed documentation plan should identify allsources of information required by the documentation team, as well asroles and responsibilities for reviewing the deliverables.

The glossary documents the vocabulary of a project and should includeunfamiliar or confusing terms. The business community, ISdepartment, and project team should participate in the selection ofwords for the glossary and reach agreement on the definitions. Theglossary often includes terms that describe the new systemfunctionality, or words whose meanings are changing from the old tothe new system.

Performance Testing

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

Decide whether to use some form of automated testing tools in thePerformance Testing Strategy. Some automated load testing tools can


provide the means to simulate complex processing environments withmany simultaneous online transactions. However, these tools aregenerally costly and require special expertise and training. If thisprocess will not employ an automated tool, then the team will have todevise other methods for conducting the test.

The timing of when to initiate a performance test will depend on theprecise scope and goals of the project. If the test objective is to providemetrics to support architectural decisions (for example, the capacityneeded for a database server, or the performance viability of acentralized or distributed hardware configuration), the test shouldprobably be conducted early in the implementation project. If a testobjective is to validate business processes throughout the project, then itmay occur in the middle of a project. At the very end of a project,performance testing may help to tune the system. The same testprograms can be reused throughout the project life-cycle.

Performance testing usually requires a controlled test environment thatmay mean isolating the test from other project work, on separate testmachines. This may also be wise from the standpoint that aperformance test may put an undue load on servers and networks andcould severely impact other project processes in shared environments.Plan the test environment and identify hardware that is available to thetest team in Definition. Ideally, the technical hardware and softwareenvironment should be identical to the production environment, butthis may not be possible depending on project circumstances. If it isnot, you should try to minimize the differences and establish the impacton the test results. If the test will require a volume test database, youwill also need to plan for significant disk capacity.

Training

The project team must prepare to take on the challenges of businessprocess redesign and systems implementation. The more they knowabout proven methods for adapting the business to a new system, themore they will perform an advocacy role. The team must gain anunderstanding of the fundamentals of application implementation andhow the business must operate in the new environment. The team mustacquire a conceptual level of knowledge about application features andfunctionality. Additionally, courses to improve their skills (such asproject management skills, manufacturing principles and practices, andso on) must be delivered.


This page intentionally left blank.


Estimating

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

Definition Pha

se E

ffort

Ana

lyst

App

licat

ion

Adm

inis

trat

or

App

licat

ions

Arc

hite

ct

App

licat

ions

Exp

ert

Bus

ines

s A

naly

st

Bus

ines

s Li

ne M

anag

er

Clie

nt P

roje

ct M

anag

er

Con

figur

atio

n M

anag

er

Dat

abas

e A

dmin

istr

ator

Dat

abas

e D

esig

ner

Fac

ilita

tor

IS M

anag

er

IS O

pera

tions

Sta

ff

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


IS S

uppo

rt S

taff

Lead

Tes

ter

Mod

ule

Des

igne

r

Net

wor

k A

dmin

stra

tor

Pro

duct

ion

Dat

abas

e A

dmin

istr

ator

Pro

gram

mer

Pro

ject

Dat

abas

e A

dmin

istr

ator

Pro

ject

Man

ager

Pro

ject

Spo

nsor

Qua

lity

Aud

itor

Sys

tem

s A

dmin

istr

ator

Sys

tem

Arc

hite

ct

Tea

m L

eade

r-A

rchi

tect

ure

Tea

m L

eade

r -

BR

Tea

m L

eade

r-C

onve

rsio

n

Tea

m L

eade

r-C

usto

miz

atio

n

Tea

m L

eade

r-D

ocum

enta

tion

Tea

m L

eade

r -

Map

ping

Tea

m L

eade

r-P

erfo

rman

ce T

estin

g

Tea

m L

eade

r -

Tes

ting

Tea

m L

eade

r-T

rain

ing

Tec

hnic

al A

naly

st

Tec

hnic

al A

rchi

tect

Tec

hnic

al E

xper

t

Tec

hnic

al E

xper

t - B

uild

Tec

hnic

al E

xper

t - D

esig

n

Tec

hnic

al E

xper

t - E

nviro

nmen

t

Tec

hnic

al E

xper

t-E

xist

ing

Sys

tem

s

Tec

hnic

al W

riter

Tes

ter

Tra

iner

Use

r

Tas

k S

umm

ary

100

0 0 100

0 0 100

0 0 100

100

0 100

30 50 10 100

30 50 10 100

45 100

0 40 100

80 100

0 25 75 100

10 0 90 0 100

20 80 0 100

5 0 100

5 10 100

30 70 100

5 5 30 5 55 100

15 70 15 100

60 30 10 100

5 95 100

0 5 95 100

Table 2-6 Definition Phase Estimating (cont.)


Scheduling

The critical role during Definition is the analyst. By assigning moreanalysts during this phase, you may be able to shorten the critical path.

Key decision makers in the user and upper management communitiesare frequently on the critical path. Although their availability canimpact the project schedule and the quality of decisions, their schedulescan be difficult to predict. Upper management should encourage keypersonnel to allocate sufficient time to the project.

Be realistic about the number of resources that can be applied to a taskeffectively. In general, you should stop adding resources to a role whenaverage utilization starts to fall below 100 percent of the target. This is asymptom that the incremental communication and administrationassociated with adding resources is reducing productivity. Allow atime 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 projectplan with associated resource and cost forecasts. For moderate to largeprojects it is not unusual to spend several person weeks developing agood plan. The critical path is a sequence of critical tasks throughoutthe project. If one of those tasks takes one day longer than planned, theend date of the project will be one day later. Tasks not on the criticalpath have slack; they can be completed later than planned withoutaffecting the end date for the project.

Warning: Avoid planning with too much detail. It istempting to define tasks at a very detailed level duringplanning. However, later you may discover that trackingprogress at this level is so time consuming that you abandontracking altogether.


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


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

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


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

This can be an opportunity to use external consulting resources in acost-effective way. Consultants can have a large impact in a short time.In this way important knowledge can be transferred to local staff andcorrect sizing estimates and architectural decisions can be made.

Consider the impact of a multi-phased deployment on the scheduling ofthis process. For example, you may elect to go live with the newapplications at different times at different sites. In this case, yourtechnical architecture may need to grow over time to support thephased deployments.


Module Design and Build scheduling depends on several factors thatcan 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 yourdevelopers can test their custom software?

• What kinds of technical design, coding, testing anddocumentation standards do you need, and when must they beready?


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

Seek an optimally sized development group. Development activityseems to be more sensitive to the size of the group than other activities.Avoid too large of a group, which can introduce inefficiencies due toincremental communication and administrative time requirements asthe number of people increases.

Data Conversion

The Data Conversion tasks from subsequent phases can be performed inDefinition if the existing systems data is well understood and nosignificant issues arise. The benefit of an early execution of DataConversion is the support for module and module integration testing inModule 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? Willall business units use the applications in the same way?

The scope of the user and technical documentation to be produced andthe techniques used to create this material can have a major impact onthe project schedule.

Performance Testing

Early in the project, assess the risk of encountering performanceproblems. If there is significant risk, incorporate Performance Testing inthe 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)?


Staffing

This diagram illustrates a typical project organization for Definition.

Definition Organization

Configuration Management Resource Management

Control & Reporting Quality Management

Resource Management Oracle Product/SupportLiaison

Oracle Account Manager Data Base Administration

Project ManagementSupport Team

Administrative Assistant/Project Librarian

Existing SystemsExamination

Team Members

Team Lead

Functional AreaTeam

(A)

Team Members

Team Lead

Functional AreaTeam

(B)

Business ProcessIntegration

Business RequirementsDefinition & Mapping

Technical Architecture &Performance Testing

Data Conversion Training &Documentation

Project Management

Figure 2-3 Staffing Chart for Definition


Staffing Suggestions

This section provides advice and comments on project organization forDefinition.

Project Management

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

If the complexity of a project goes beyond a certain point, frequentlydriven by the need for multiple deployment phases, you may need totreat the effort as multiple projects.


A key staffing requirement is recruiting analysts with goodinterpersonal skills, a knowledge of the business and applicationfunctionality, and sufficient data conversion expertise to conductpreliminary conversion analysis. If applications will be deployed inphases at multiple sites, your analysis activities will be more complex,which may require more experienced staff. For example, a phaseddeployment may mean that some sites will be using the newapplications, while others are still using the legacy systems. This cannecessitate the use of temporary bridge systems. Until all sites aredeployed, these systems pass transactions to the appropriate systemused for consolidating reporting.


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


The key Definition activity for this process concerns design andplanning for establishing the development environment. Ensure thatsomeone skilled in development management is available for this task.

A phased deployment approach may significantly affect the timing ofstaffing needs for Module Design and Build. For example, if you aredeploying to different sites at different times, you may need to develop


custom software associated with various deployments. This couldsignificantly 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, youneed someone who can perform high-level analysis tasks to identifydata conversion needs.

Software tools that can significantly improve productivity are availablefrom various vendors. Using these tools may require lead time forevaluation, acquisition, and installation. If you use such a tool, you mayneed staff with related expertise.

If you deploy in multiple phases, you will need to perform dataconversions at different times. This affects the timing of your staffingneeds.

Documentation

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

A multi-phased deployment approach may require documentation tasksto be performed for each deployment. If various business units dobusiness in different ways, some user documentation may need tochange for each deployment. This would affect the timing of relatedstaffing requirements.

Performance Testing

Specialists are required to effectively perform this process. Decisionsregarding whether such staff will be needed are made in this phase.

If you deploy in multiple phases, you may need a phased PerformanceTesting approach. Make sure that the maximum load your system willexperience after all deployments can be handled by the plannedconfiguration. This consideration could affect the timing of staffingneeds.


Training

Decisions about the training approach are made in this phase; thereforeyou need staff that can advise you on approaches. For example, youmight 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 thetrainers”

• train Information Systems analysts to support the newapplications

• conduct separate training for each deployment in a multi-phasedproject

Decisions related to these issues will impact your staffing requirements.

Oracle Method Operations Analysis 3 - 1

C H A P T E R

3 Operations Analysis

his chapter describes the Operations Analysis phase of AIM. Thegoal of Operations Analysis is to formulate the detailed

requirements for the computer application system and to propose asolution.

Application & Technical Architecture

Definition Operations Analysis

Solution Design




Module Design & Build

Documentation

Performance Testing

Training



Data Conversion

Figure 3-1 Context of AIM Operations Analysis Phase

T

3 - 2 Operations Analysis AIM Method Handbook

Overview

This section provides an overview of Operations Analysis.

Objectives

The objectives of Operations Analysis follow:

• Produce accurate information, function, and process models forthe business areas being addressed.

• Define the detailed function, data, and operational requirementsthat the new application system must support.

• Map business requirements to application capabilities andpropose solutions to gaps.

• Define a technical architecture of hardware and software inwhich the application system must perform.

• Propose a transition strategy for moving from the current systemto the new application system.

• Identify audit and control reporting and application integrationrequirements.

• Train the project team.

• Develop performance testing models and scenarios.


The critical success factors of Operations Analysis follow:

• active participation by team management and knowledgeableuser and technical representatives from the area of the businessaffected by the project

• thorough knowledge of the standard functionality of theapplications being implemented

• timely resolution of outstanding issues and questions


• clear definition of the business objectives to be addressed by theproject

• access to information related to the existing business processesand systems affected by the project

• effective management

Overview Table

This table illustrates the prerequisites, processes, and key deliverablesfor Operations Analysis.


Application andTechnical Architecture

Architectural Requirements

Architectural Strategy



Future Applications Deployment

Process and Mapping Summary

System Availability Strategy


Application Security Architecture

Application Function Architecture

Hardware and NetworkArchitecture

Logic Application and DatabaseArchitecture

Performance Risk Assessment

Physical Database Architecture

System Capacity Plan

System Management Procedures

Module Design andBuild

Business Data Mapping Form

Customization Strategy

Solution Document

Database Extension Design

Module Function Design

Module Technical Design



Data Conversion Conversion Scope, Objectivesand Approach

Conversion Standards

Conversion Strategy

Current Business Baseline

Conversion Data Mapping

Conversion Program Design

Conversion Test Procedures

Documentation Document Prototypes andTemplates

Document Requirements

Document Standards andProcesses

Documentation Environment

Business Systems Testing Mapping Scenario

Integration Fit Analysis

Testing Strategy

Performance Testing Performance Test TransactionModels

Performance Test Data Design

Performance Test Scripts

Test Database Load ProgramDesign

Test Transaction Program Design

Training User Training Manuals

Production Migration Education and Training Plan

Transition Strategy

Detailed Transaction andContingency Plan

Production Support Infrastructure

Table 3-1 Operations Analysis Phase Overview Table


Prerequisites

Prerequisites for Operations Analysis follow. You should use theseprerequisites, if they exist, prior to beginning this phase. Otherwise,you may need to create them during Operations Analysis.

Prerequisite Source

Architectural Requirements Application and TechnicalArchitecture

Architectural Scope, Objectives, andApproach


Architectural Strategy Application and TechnicalArchitecture

Business Volume Requirements Business RequirementsDefinition

Conceptual Architecture Application and TechnicalArchitecture

Conversion Scope, Objectives, andApproach

Data Conversion

Conversion Strategy Data Conversion

Current Business Baseline Business RequirementsDefinition

Customization Strategy Module Design and Build


Documentation

Documentation Requirements Documentation

Education and Training Plan Training

Financial and Operating Structure Business RequirementsDefinition


Prerequisite Source

Future Business Function Model Business RequirementsDefinition

Future Process Model Business RequirementsDefinition

Glossary Documentation

Performance Testing Scope,Objectives, and Approach

Performance Testing

Performance Testing Strategy Performance Testing

Process and Mapping Summary Business RequirementsDefinition

Technical Architectural Baseline Application and TechnicalArchitecture

Table 3-2 Operations Analysis Phase Prerequisites

Processes



Create detailed business requirements scenarios that depict sequencedelementary business functions for mapping process steps toapplications. Determine business requirements for system availability.Define audit and control requirements for financial and systemadministration purposes. Define reporting requirements for allfunctions.


Map business requirements to application functionality. Prove theviability and feasibility of proposed business processes and theirintegration. Map information flow and access needs by organization.



Develop strategies to meet the reporting needs and system availabilityrequirements of the business. Determine the details of deploying thenew application across data centers within the scope of the newarchitecture. Refine the initial conceptual architecture and identify anysubsystems that need to be developed or integrated.

Data Conversion

Prepare the Conversion Standards to be used throughout the conversionprocess.

Documentation

Create the documentation environment and produce the prototypes andtemplates.

Performance Testing

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

Training

Provide technical and functional application training to the projectteam, including specific training segments for defining and using theapplications as well as maintaining the system.


Prepare a transition strategy for migrating the company, systems, andpeople into the new enterprise system.


Key Deliverables



Acceptance Certificate Agreement by management that theintegrated business solutions satisfybusiness objectives.

Architecture SubprojectProposals

Proposals for architecture subprojectsto design and build, or integrate,architecture subsystems.

Architecture Subsystems Describes the subsystems needed tosupport the new architecture. Thesubsystems may be designed andbuilt in-house, or may be purchased.Examples include data warehouses,OLAP systems, and enterprise datatransport mechanisms.

Audit and ControlRequirements

A statement of security, maintenance,and monitoring of the productionsystem.

Business AvailabilityRequirements

A statement of the business needs interms of operating hours, systemuptime, and response andturnaround time.

Business Data Mapping Verification that the underlying tablestructures and attributes will supportbusiness processes.



Business RequirementsMapping Form

Detailed business requirementswritten in business language andassociated with business processes,analysis and comparison of thecurrent solution for a businessrequirement to a proposed solution,and details for the type and nature ofthe solution in a descriptive format.

Business RequirementsScenarios

A set of formal statements of thedetailed business requirements foreach business process, the source ofthese requirements, how theserequirements will be satisfied (eitherby the application, manual processsteps, workarounds or otherapplication solutions), and whatprototyping steps must be taken toprove the designs.

Conceptual Architecture Revision of the original ConceptualArchitecture to reflect analysis doneduring Operations Analysis.

Conversion Standards Documents naming conventions, filestructures, automated dataconversion toll usage standards, andso on, used to ensure consistency andquality.

Documentation Environment Contains the DocumentationEnvironment Proposal, procurementinformation, and installationdocumentation.

Documentation Prototypesand Templates

Prototypes and templates developedfor documentation, for example: UserReference Manual, User Guide,Technical Reference Manual, andSystem Management Guide.



Future ApplicationDeployment

Details the future deployment ofapplications needed to support thebusiness and information systemsrequirements and the broadercorporate vision.

Future Process Models Defines the future business model inthe form of integrated process flowsbuilt upon the business processessupported by the new application.

Information Access Model A model that depicts access to keyprocess and organization informationfor reporting and/or securitypurposes.

Information Flow Model A model that visually depictsinformation flows in the businessbetween business functions, businessorganizations, and applications.

Integration Fit Analysis Identifies the new integration pointswhich will require interfaces.

Mapping Scenario A plan for and record of businesssolution testing, including businessprocesses involved in the test, thebusiness conditions that are neededto test the application system,definition of test script execution,support tools required duringexecution of the test, and a record oftest actions.

Master Report Tracking List A document that supports theanalysis and mapping of reportrequirements to future businessprocesses and standard applicationreports. It contains a consolidatedlist of reporting requirements and thefinal disposition of reportrequirements.



Performance Test Scenarios The performance test scenarios thatwill be simulated in performancetesting. These are point-in-timesnapshots of the total productionsystem processing environment thatwill be modeled in the performancetest. There may be more than oneperformance test scenario to model,and each may have a different set oftransactions.

Performance TestTransaction Models

The transaction models that will beused to simulate each performancetest scenario. They will, in general,contain a subset of the totaltransactions and processing thatwould occur in a real system and areapproximations to the real processingenvironment in a live system. Thisalso discusses the transaction ratesand measurements to be used fortesting.

Project Team Training The environment to be used fortraining the project team.

Training PreparationChecklist

Lists the resources required forproject team training.

Trained Project Team Project personnel trained to performassigned project tasks.

Reporting Strategy Strategy for the reporting systemsneeded to support the variousreporting requirements of thebusiness. Includes operational, adhoc, decision support, and analyticalreporting across applications,databases, and sites.



Solution Document A document that summarizes thebusiness need that the applicationfeatures cannot meet, and proposes asolution that can include acombination of custom components,manual workarounds, and otherexisting application features.

System Availability Strategy Documents the strategy for handlingplanned and unplanned outages. It isthe system implementation of themore general business availabilityrequirements.

Transition Strategy Outlines the approach for migratingthe people, company, and system toproduction status. Includestransition and contingency plans andtransition support strategy.

Table 3-3 Operations Analysis Phase Key Deliverables


Approach

This section describes the approach for Operations Analysis.


This table lists the tasks executed and the deliverables produced duringOperations Analysis.

ID Task Deliverable

Business Requirements DefinitionRD.070 Create Business Requirements Scenarios Business Requirements ScenariosRD.080 Determine Audit and Control Requirements Audit and Control RequirementsRD.090 Identify Business Availability Requirements Business Availability RequirementsRD.100 Develop Reporting Requirements Master Report Tracking ListBusiness Requirements MappingBR.010 Prepare Mapping Environment Configure Mapping EnvironmentBR.020 Map Business Requirements Business Requirements Mapping

FormBR.030 Map Business Data Business Data Mapping FormBR.040 Conduct Integration Fit Analysis Integration Fit AnalysisBR.050 Develop Information Flow Model Information Flow ModelBR.060 Develop Information Access Model Information Access ModelBR.070 Conduct Reporting Fit Analysis Master Report Tracking ListBR.080 Test Business Solutions Mapping ScenarioBR.090 Confirm Integrated Business Solutions Acceptance CertificateApplication and Technical ArchitectureTA.060 Develop System Availability Strategy System Availability StrategyTA.070 Define Future Application Deployment Future Applications DeploymentTA.080 Develop Reporting Strategy Reporting StrategyTA.090 Revise Conceptual Architecture Conceptual ArchitectureTA.100 Define Architecture Subsystems Architecture SubsystemsTA.110 Propose Architecture Subprojects Architectural Subproject ProposalsModule Design and BuildMD.020 Define and Estimate Custom Extensions Solution Document


ID Task Deliverable

Data ConversionCV.030 Prepare Conversion Standards Conversion StandardsDocumentationDO.040 Prepare Documentation Environment Documentation EnvironmentDO.050 Produce Documentation Prototypes and

TemplatesDocumentation Prototypes andTemplates

Performance TestingPT.030 Identify Performance Test Scenarios Performance Test ScenariosPT.040 Identify Performance Test Transaction Models Performance Test Transaction ModelsTrainingTR.020 Prepare Project Team Training Environment Project Team Training EnvironmentTR.050 Prepare Project Team Training Training Preparation ChecklistTR.060 Train Project Team Trained Project TeamProduction MigrationPM.010 Prepare Transition Strategy Transition Strategy

Table 3-4 Operations Analysis Phase Tasks and Deliverables


Task Dependencies

This diagram shows the dependencies between tasks in OperationsAnalysis.

BUSINESS

REQUIREMENTS

DEFINITION

APPLICATION AND

TECHNICAL

ARCHITECTURE

BUSINESS

REQUIREMENTS

MAPPING

OperationsAnalysis

RD.060Create BusinessRequirements

ScenariosRD.070

RD.090Identify Business

AvailabilityRequirements

RD.090

TA.060Develop System

AvailabilityStrategyTA.060

RD.070Determine Audit

and ControlRequirements

RD.080

RM.050Conduct

Integration FitAnalysisBR.040

RM.010

Prepare MappingEnvironment

BR.010

RM.020


BR.020

RM.040

Map BusinessData

BR.030

RD.100

Develop ReportingRequirements

RD.100

A

TA.070Define Future

ApplicationDeployment

TA.070

Figure 3-2 Operations Analysis Phase Task Dependencies


BUSINESS

REQUIREMENTS

DEFINITION

APPLICATION AND

TECHNICAL

ARCHITECTURE

BUSINESS

REQUIREMENTS

MAPPING

OperationsAnalysis

TA.080

Develop ReportingStrategyTA.080

TA.090

Revise ConceptualArchitecture

TA.090

RM.060

Test BusinessSolutionsBR.080

RM.070Confirm Integrated

BusinessSolutionsBR.090

RM.030

Conduct ReportingFit Analysis

BR.070

TA.110Propose

Architecture Sub-projectsTA.110

TA.100Define

ArchitectureSubsystems

TA.100

RM.110Develop

Information FlowModel

BR.050

RM.120Develop

InformationAccess Model

BR.060

B C

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


MODULE DESIGNAND BUILD

DOCUMENTATION

DATACONVERSION

OperationsAnalysis

PERFORMANCETESTING

TRAINING

PRODUCTIONMIGRATION

TR.050

Prepare ProjectTeam Training

TR.050TR.020Prepare ProjectTeam TrainingEnvironment

TR.020

TR.060

Train Project TeamTR.060

CV.030Prepare

ConversionStandards

CV.030

A



MODULE DESIGNAND BUILD

DOCUMENTATION

DATA

CONVERSION

OperationsAnalysis

PERFORMANCETESTING

TRAINING

PRODUCTION

MIGRATION

PT.030Identify

Performance TestScenarios

PT.030

DO.040Create

DocumentationEnvironment

DO.040

DO.050ProduceDocumentationPrototypes and

TemplatesDO.050

PM.010

Prepare TransitionStrategyPM.010

PT.040IdentifyPerformance Test

TransactionModelsPT.040

MD.020Define and

Estimate CustomExtensions

MD.020

B C



Managing Risks

The areas of risk and mitigation for Operations Analysis include thefollowing:

Risk Mitigation

Team members inadequatelytrained on the use ofmethods and tools.

Provide project team trainingregarding methods and tools.

Screen project team candidates toensure necessary skills andexperience will be available.

Insufficient business processresearch.

Ensure training sessions sufficientlyexplain that process research goesdown to the level of ElementaryBusiness Functions and validate thatthe research reaches this level.

Erroneous statement ofrequired system availability.

Obtain agreement from the usercommunity about the level of systemoutage that can be tolerated by thebusiness.

Inconsistency of teamcomposition and expertiseacross process design,mapping, narrative writing,and approval activities.

Assign process design and mappingteams to groups of businessprocesses or areas and keep themtogether across all analysis anddesign tasks.

Inconsistency of teammethods and approachesacross business areas orprocess groups.

Conduct training sessions for teammembers on methods andapproaches. Have them demonstraterequired skills with a qualifiedinstructor.

Inadequate integration ofprocesses across design andmapping teams.

Create an integration team thatmonitors process designs. As theyare in-process, look for inter-teamintegration problems.


Risk Mitigation

Limited understanding bythe project team of theapplications tools to beimplemented and generallyaccepted industry practices.

Screen project team candidates toensure necessary skills andexperience are present.

Limited access to informationabout business areas, theirprocesses, and informationgeneration and use.

Conduct frequent checkpoints thatinclude a management review toensure that teams engaged in analysisactivities are not being blocked fromgathering information.

Incomplete consideration ofthe capabilities andlimitations of the technologyon which the architecturewill be based.

Employ team members withappropriate experience or knowledgeabout the technology.

Lack of visibility of majorarchitecture issues occurringin different areas or teams.

Assemble architecture teamrepresentation in channels or forumsto discuss major cross-functional orbusiness issues.

Insufficient communicationto the wider project team ofthe chosen conceptualarchitecture model to allteam members.

Communicate the conceptualarchitecture model to the broaderproject team so that everyone isproperly informed.

Not initiating development ofcomplex, bi-directionalsystem interfaces earlyenough in the project.

Allow adequate investment ofresources and time in developing asound project plan and follow it toensure tasks are begun early enoughin the project life cycle.

Lack of technical expertiseaffecting decisionsconcerning appropriatetechnology solutions.

Recruit team members withappropriate experience andknowledge.


Risk Mitigation

Lack of expertise indesigning system transactionmodels that will provideuseful results and provideanswers to the questionsposed by the objectives of theperformance testing process.

Careful design of the test transactionmodels with a clear vision of theobjectives of the test and the extent towhich approximate models canprovide useful answers.

Transaction models forperformance testing builtwithout allowing for futurebusiness growth, peakperiods, or detailedworkflow patterns.

Communicate the conceptualarchitecture model to the widerproject team so that everyone isproperly informed.

Poor or nonexistent businessvolume metrics and inabilityto relate the performance testresults in a meaningful wayto the production system.

Survey and establish businessvolume metrics in advance ofconducting performance testing.

Insufficient development ofconversion standards.

Start development of standards inOperations Analysis using thetemplate for Prepare ConversionStandards.

Poorly designeddocumentation prototypesand templates.

Include all key project areas in thedesign and approval of thedocumentation prototypes andtemplates.

Table 3-5 Risk Management Table for Operations Analysis


Tips and Techniques

This section provides tips and techniques for managing OperationsAnalysis. In addition, advice and comments on each process areincluded.


In Operations Analysis, format detailed business requirements intoscenarios containing elementary business functions. These includesequenced process steps that need to be supported by a combination ofapplication functions, manual process steps, other interfaced orintegrated applications, workarounds, or custom modules.

Along with the business requirements identified in Definition, gatherand formalize the business availability requirements that dictate systemavailability needs. This will be considered during the technicalarchitecture process.

The flow of information that results from business processes andtransactions is portrayed both within and across organizations. Thetype of information access required for operating, reporting, andconsolidation for each organization is also identified (for example, someorganizations are creators of information while others are consumers ofinformation). These tasks will help to formalize the understanding andcontrol of information access and timing requirements.


During Operations Analysis, good team organization is the mostimportant factor affecting the quality of this process. Mapping teamsshould address the same business areas and business processes asprocess design teams. Ideally, the same teams will work on processmodeling and design, business requirements identification, andmapping of requirements to application capabilities.

Key users should participate in mapping sessions. Perform mappingclose to the business process, in order to have access to agents and keyusers and to allow users to witness process execution. As decisions aremade and agreements reached, document them in BusinessRequirements Scenarios so that the final product reflects the proposedbusiness process design.


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

Maintain a meticulous record of process prototyping. This will makeacceptance of business solutions easier. Obtain an informal agreementbefore the formal signoff, if possible.


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

When the architecture team has refined the Conceptual Architecture,they should also identify architecture components that are standalonesubsystems and have a wider impact on the information systemsarchitecture than a localized extension to a collection of modules or asimple interface to a third party application. Examples of suchsubsystems might include a data distribution system that links multipleapplication installations and legacy applications; an operational datarepository that is synchronized to provide real-time information aboutthe state of business; a data warehouse; or an intranet web interface tothe new systems. Typically, these types of subsystems are onlyimportant in larger scale projects, but the concept of a non-localizedcomponent to an architecture, affecting multiple different applications,interfaces, or databases is entirely general.

Because of the possible impact of these subsystems on the overallsystems architecture and on multiple individual technical groupsworking on the project, separate the specification, design, and build ofthese systems into separate subprojects linked to the core Applicationand Technical Architecture process. The individuals or teams assignedthe task of managing the subsystems will produce individual proposalsfor the work needed to integrate the subsystems into the overall


technical infrastructure. Even if the subprojects components arepurchased as pre-built packaged applications, significant integrationwork may be necessary to integrate them.


One of the key deliverables of Operations Analysis is SolutionDocuments which describes required custom extensions with workestimates to design, build, and test all components. This is an importantdecision-making document for upper management since it allows themto evaluate the full cost of the implementation. If the time and cost toimplement the required extensions is greater than the perceived benefit,management may ask the project team to reevaluate some of the gapsand propose alternate solutions. You may decide to delay some of theoptional extensions until after production cutover.

The detailed work estimates in the Solution Documents are animportant input to the project manager for planning the detailed tasksin Solution Design and Build. They also specify the need for thetechnical resources you must secure for the project.

Data Conversion

In Operations Analysis, Conversion Standards should be prepared andfollowed throughout Data Conversion

Documentation

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

Create a prototype for each document that contains a table of contentsand a sample chapter that can be easily reviewed for document design,format, and suggested content. Prototypes present a clear visualindicator of the final product and serve as the model for templatedevelopment.

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


Performance Testing

In systems that support many tightly integrated business functions, theprocessing environment may be complex and have a large number ofdetailed transaction flows. In such cases approximations are inevitablein the definition of a test model.

During this phase the performance test team constructs test models thatmeet technical needs and will be financially feasible to implement. Theteam will construct the models relative to predicted or actualproduction system snapshots, and use input from the BusinessRequirements Definition and Mapping teams to understand the way thebusiness will run on the new system. In this way, the team can interpretthe test results properly in the context of a real production situations.Typically, the models selected will reflect situations of the highestprocessing load on the system or on some critical component of thesystem. The performance testing process depends on BusinessRequirements Definition and Mapping to obtain information ofsufficient detail and quality so that the test team can construct accuratemodels.

Training

During Operations Analysis, the project team is introduced to keyapplication features. Examples of key features are the use of multiplesets of books and available to promise functions. This backgroundprepares the team for mapping tasks. Team members must have agood understanding of system capabilities.


One of the key deliverables of Operations Analysis is the TransitionStrategy which outlines the approach for migrating the people,company, and business systems to production. It includes estimatedtransition resource requirements, high-level transition andimplementation contingency plans, and a transition support strategy.

The components of the Transition Strategy document are an importantinput to the project manager for planning the detailed tasks inTransition and for updating the Project Workplan. They also identifythe need for specific resources needed during the transition process.


EstimatingThe following table indicates the typical percentage of effort required byeach task by role.

Operations Analysis Pha

se E

ffort

Ana

lyst

App

licat

ions

Adm

inis

trat

or

App

licat

ions

Arc

hite

ct

App

licat

ions

Exp

ert

Bus

ines

s A

naly

st

Bus

ines

s Li

ne M

anag

er

Clie

nt P

roje

ct M

anag

er

Con

figur

atio

n M

anag

er

Dat

abas

e A

dmin

istr

ator

Dat

abas

e D

esig

ner

Fac

ilita

tor

IS M

anag

er

IS O

pera

tions

Sta

ff

ID TaskBusiness 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 Availability 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 & Build 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 Team Training Environment 1.5% 20 0

B.TR.050 Prepare Project Team Training 3.0% 45

B.TR.060 Train Project Team 13.3%

Production Migration 0.8%B.PM.010 Prepare Transition Strategy 0.8% 0



100.0%

Table 3-6 Operations Analysis Phase Estimating


IS S

uppo

rt S

taff

Lead

Tes

ter

Mod

ule

Des

igne

r

Net

wor

k A

dmin

stra

tor

Pro

duct

ion

Dat

abas

e A

dmin

istr

ator

Pro

gram

mer

Pro

ject

Dat

abas

e A

dmin

istr

ator

Pro

ject

Man

ager

Pro

ject

Spo

nsor

Qua

lity

Aud

itor

Sys

tem

s A

dmin

istr

ator

Sys

tem

Arc

hite

ct

Tea

m L

eade

r-A

rchi

tect

ure

Tea

m L

eade

r-B

R

Tea

m L

eade

r -

Con

vers

ion

Tea

m L

eade

r -

Cus

tom

izat

ion

Tea

m L

eade

r-D

ocum

enta

tion

Tea

m L

eade

r-M

appi

ng

Tea

m L

eade

r-P

erfo

rman

ce T

estin

g

Tea

m L

eade

r -

Tes

ting

Tea

m L

eade

r-T

rain

ing

Tec

hnic

al A

naly

st

Tec

hnic

al A

rchi

tect

Tec

hnic

al E

xper

t

Tec

hnic

al E

xper

t - B

uild

Tec

hnic

al E

xper

t - D

esig

n

Tec

hnic

al E

xper

t - E

nviro

nmen

t

Tec

hnic

al E

xper

t - E

xist

ing

Sys

tem

s

Tec

hnic

al W

riter

Tes

ter

Tra

iner

Use

r

5 0 10 0

0 10 0

5 0 10 0

0 10 0

30 40 10 10 0

5 20 10 0

20 10 0

5 95 0 10 0

5 95 0 10 0

25 0 10 0

5 20 10 0

5 5 10 0

25 25 10 0

10 10 70 10 0

10 0

30 10 0

10 0 35 10 0

20 20 30 10 0

20 80 10 0

70 0 20 10 0

10 0 10 0

80 5 15 10 0

10 0 0 10 0

65 0 10 0

65 25 10 0

25 35 10 10 10 0

0 5 25 25 0 10 0

0 2 2 6 90 10 0

90 10 10 0

Table 3-6 Operations Analysis Phase Estimating (cont.)


Scheduling

The critical role during Operations Analysis is the analyst. By assigningmore analysts to this phase, you can shorten the critical path. Executingtasks on the critical path in parallel also allows you to compress thephase timeline.


Scheduling suggestions for Operations Analysis follow:

Project Management

In Operations Analysis the last portion of Business RequirementsDefinition is completed and the majority of Business RequirementsMapping tasks occur. Managing the overlap between these processescan significantly affect your schedule.

Leverage analysis time with key users since user availability may be acritical resource constraint. If you have skilled analysts andknowledgeable users, several objectives associated with variousprocesses 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 fromuser management and staff. Time must be allocated from day-to-daywork to provide information about the business areas’ objectives,requirements, and work practices, and to attend reviews. The projectmanager should set expectations about the level of user participationneeded by explicitly scheduling these reviews and consultations in theworkplan.

Consider the impact of a multi-phase deployment. If applications willbe deployed in phases, there may be additional requirements, gaps, andsolutions needed at each site.


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


Schedule slippage for this process is often caused by:


• 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 runmapping scenarios. Depending on your business processes, the demodata may not be sufficient to exercise the Oracle Applications accordingto your scenarios. Consider augmenting the demo data.

If you are using a multi-phase deployment approach consider usingspecial Oracle features such as the open application program interfaces(APIs) to support temporary bridges from your legacy systems that maysupport some business units during initial deployment phases. Bypassing transaction data to Oracle Applications you can use them forconsolidated reporting and query even though a portion of theorganization temporarily continues to use legacy systems.


Coordinate the detailed scheduling of this process with the BusinessRequirements Definition development teams. Make sure functionfrequencies and data retention rules are reviewed and agreed on from abusiness perspective before finalizing the Capacity Plan.

Determine the impact of a multi-phased deployment approach ontechnical architecture; they may cause schedule slippage later in theproject.

Both the new applications and legacy systems may need support untilall business units convert to the Oracle Applications. A phaseddeployment approach may appear straightforward; however, therecould be major complexities in this area.


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


If different business units will be in production on legacy systems andnew applications, you may need to build temporary bridges betweenthem to support consolidated query and reporting. Consider usingOracle’s application programming interfaces (APIs) to facilitatebridging.

Data Conversion

Effective software products exist for data conversion that cansignificantly enhance a team’s productivity. At this point the decisionregarding whether you will use such tools should have been made toallow for acquisition, implementation, and training.

A multi-phase deployment approach may require iterations of somedata conversion tasks as the various subsets of business units go live onthe new system.

Documentation

Use an approach that leverages documentation developed earlier in theproject. A multi-phased deployment approach may have timeconsuming impacts on documentation that should be addressed.

Performance Testing

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

Training

Procrastination regarding training tasks (such as curriculumdevelopment, training site scheduling, and instructor identification) iscommon. This may result in schedule slippage later in the project or adecision to accept lesser quality training than initially planned.

Accurately assess your training needs and determine the appropriateapproach. Curriculum development is expensive but may be the mosteffective method of introducing a heavily customized system. StandardOracle education and custom developed training have considerationsthat can end up on the critical path. When will standard Oracle classesbe taught? How soon can custom training be developed?



The most important consideration is whether a multiple deploymentapproach will be used, since Production Migration must occur for eachdeployment.


Staffing

This diagram illustrates a typical project organization for OperationsAnalysis.

Operations Analysis Organization



Existing SystemsExamination

Team Members

Team Lead

Functional AreaTeam

(A)

Team Members

Team Lead

Functional AreaTeam

(B)


Business RequirementsDefinition & Mapping

Team Members

Team Lead


Team Members

Team Lead

Data Conversion

Team Members

Team Lead

Training &Documentation

Transition Oracle ApplicationsSpecialists

Project Management

Figure 3-3 Staffing Chart for Operations Analysis



This section provides advice and comments on project organization forOperations Analysis.

Project Management

The most important staffing related factors in Operations Analysis are:

• having the right mix of skills due to the diversity of processesoccurring simultaneously

• fostering a sense of ownership of key decisions by appropriatemanagers

• obtaining sufficient upper management, Information Systems,and user commitment to ensure accurate and timely results

• ensuring staff follow a systematic plan with appropriateguidelines, standards, and milestones

• dealing effectively with a mixed project team if you are usingpeople from various organizations (such as multiple consultingfirms, hardware/software vendors, or employees)

User and IS membership in the core project team is an effective tool infostering a sense of ownership in the new system. Consideration shouldbe given to full-time participation by key user and IS staff. Managementpersonnel who realize the importance of the application implementationand the fact that its success is based on their involvement willunderstand your request for full-time staff.


Substantial efficiencies can be gained by using some key peoplethroughout Business Requirements Definition and BusinessRequirements Mapping.

The main difference, from a staffing point of view, between these twoprocesses is that a critical mass of knowledge must exist regarding howthe standard Oracle Applications function during BusinessRequirements Mapping. This is where final decisions are maderegarding what aspect of the standard applications will suffice andwhere customizations and/or workarounds are needed. Ideally,thorough applications knowledge will exist throughout the entireproject.



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


This process must be staffed by an experienced technical architect whois knowledgeable in hardware, network, and operating systemconsiderations.


Module Design and Build work can begin when a custom solution iscomplete. In some cases, team members may be assigned too late totake advantage of the process overlap opportunities between mappingand design. As a result, benefits to the project schedule are notrecognized.

Data Conversion

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

Documentation

During Operations Analysis, the documentation environment must beprepared to meet the needs of the people assigned to developingdocumentation. Be certain to involve the writers in determining theirenvironment requirements.

Performance Testing

The fundamental approach to Performance Testing, and the design ofthe mechanisms to be used, is defined during Operations Analysis. Ifthe work in this phase is accomplished well, it may be possible to useless skilled staff to carry out the remainder of the performance testingplan. Assure yourself that the technical architecture will support theforecasted load by ensuring that sufficient expertise is applied to thisprocess.


Training

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


During Operations Analysis, the Transition Strategy is prepared. Thisdocument is critical for a successful move to production. Be sure thatthe individuals selected to define the strategy have a sufficientunderstanding of the transition requirements.

Oracle Method Solution Design 4 - 1

C H A P T E R

4 Solution Design

his chapter describes the Solution Design phase of AIM. The goal ofSolution Design is to use the requirements created during

Operations Analysis and finalize the system design and proposedapplications setups.


SolutionDesign






Documentation

Performance Testing

Training



Data Conversion

Figure 4-1 Context of AIM Solution Design Phase

T

4 - 2 Solution Design AIM Method Handbook

Overview

This section provides an overview of Solution Design.

Objectives

The objectives of Solution Design follow:

• Produce a design that meets functional requirements withinbusiness, technical, and financial constraints.

• Document the design specifications in a way that facilitates andsupports future maintenance of the system.

• Define proposed application setups and test plans.

• Create job-level designs that will support proposed businessprocesses.

• Design the application, security, database, and networkarchitectures.

• 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, andtest data.

• Develop User Training Manuals.

• Develop the detailed transition and contingency plans.


The critical success factors of Solution Design follow:

• clearly define the business objectives to be addressed by theproject

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


• know the capabilities and features of the application andavailable 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 deliverablesfor Solution Design.


Business RequirementsMapping

Business Requirements MappingForm

Business Requirements Scenario

Financial and Operations Structure

Information Access Model

Applications Setup Document

Process Narrative

Security Profiles




Architectural Requirements




Future Applications Deployment

Process and Mapping Summary

System Availability Strategy



Application Function Architecture






System Management Procedures

Module Design and Build Business Data Mapping Form

Customization Strategy

Master Report Tracking List

Solution Document

Build Standards

Design Standards


Module Function Design


Data Conversion Conversion Scope, Objectives, andApproach

Conversion Standards

Conversion Strategy


Conversion Environment

Conversion Data Mapping


Conversion Test Plan Procedures

Manual Conversion Strategy



Documentation Document Prototypes andTemplates

Document Requirements

Document Standards andProcesses

Documentation Environment

Initial User Reference Manual

Initial User Guide

Initial Technical Reference Manual

Initial System Management Guide

Business Systems Testing Mapping Scenario

Integration Fit Analysis

Testing Strategy

Unit Test Scripts

Link Test Scripts

System Test Scripts

Systems Integration Test Scripts

Performance Testing Performance Test TransactionModels

Performance Test Scenarios

Performance Test Data Design

Performance Test Scripts

Test Database Load ProgramDesign

Test Transaction Program Design

Training Trained Project Team User Training Manuals

Production Migration Conversion Strategy


Performance Test Strategy

Transition Strategy

Detailed Transition andContingency Plan


Table 4-1 Solution Design Phase Overview Table


Prerequisites

Prerequisites for Solution Design follow. You should use theseprerequisites, if they exist, prior to beginning this phase. Otherwise,you will need to create them during Solution Design.

Prerequisite Source

Architecture Requirements Application and TechnicalArchitecture


Business Data Mapping Form Business RequirementsMapping

Business Requirements MappingForm


Business Requirements Scenario Business RequirementsDefinition

Business Volume Requirements Business RequirementsDefinition

Conceptual Architecture Application and TechnicalArchitecture

Conversion Scope, Objectives, and,Approach

Data Conversion

Conversion Standards Data Conversion

Conversion Strategy Data Conversion


Customization Strategy Module Design and Build

Documentation Prototypes andTemplates

Documentation


Prerequisite Source


Documentation

Documentation Environment Documentation



Financial and Operating Structure Business RequirementsDefinition

Future Application Deployment Business RequirementMapping

Information Access Model Business RequirementMapping

Integration Fit Analysis Business RequirementMapping

Mapping Scenario Business RequirementsMapping

Master Report Tracking List Business RequirementsMapping

Performance Test Scenarios Performance Testing


Performance Testing TransactionModels

Performance Testing

Process and Mapping Summary Business RequirementsDefinition

Solution Document Module Design and Build

System Availability Strategy Application and TechnicalArchitecture


Prerequisite Source

Technical Architecture Baseline Application and TechnicalArchitecture

Transition Strategy Production Migration

Table 4-2 Solution Design Phase Prerequisites

Processes



Develop process narratives documentation that will serve as input intothe creation of training materials and user procedures. Finalizeapplication setups, security profiles, parameters, and user securitystructures.


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


Design customizations to address functionality gaps identified duringBusiness Requirements Mapping.

Data Conversion

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

Documentation

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



Prepare a Testing Strategy that encompasses all tasks in the testingprocess. Include an overview of the testing approach, the type of testscripts to be developed, the testing to be performed, a schedule oftesting resources and responsibilities, the testing tools andenvironments required, and a discussion of the problem managementprocess. Develop the detailed test scripts for each type of testingincluding unit, link, business system, systems integration, andregression testing. Test scripts can include test checklists, testspecifications or steps, test data profiles, and test sequences.

Performance Testing

Design the performance test database and identify how it will bepopulated. 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.


Develop the production support infrastructure, as well as contingencyand transition plans.

Key Deliverables



Application FunctionalArchitecture

The design of the functionalarchitecture for the applications foreach installation site.

Application SecurityArchitecture

The design of the security architectureto support the (inter-) organizationsecurity requirements.

Application Setup Document Setup data detailed documentation.



Conversion Data Mapping The mapping of the legacy system filesand data elements to the targetapplication tables and columns.

Conversion Program Design The program logic and rules dataconversion programs.

Conversion Test Plans The detailed conversion test plan forboth manual and automated dataconversions.

Database Extensions Design A design for new and changeddatabase objects, including theirrelationships to standard applicationdatabase objects.


The hardware, systems software, andnetworks to support the applicationsdeployment and database architecture.

Initial User ReferenceManual

Preliminary version of the UserReference Manual.

Initial User Guide Preliminary version of the User Guide.

Initial Technical ReferenceManual

Preliminary version of the TechnicalReference Manual.

Initial System ManagementGuide

Preliminary version of the SystemManagement Guide.

Logical Application andDatabase Architecture

The design of the application anddatabase architecture at the logicallevel. Includes the relationshipbetween the functional architectureand the logical data partitioning.Encompasses database schemes andlogical database objects.

Manual Conversion Strategy The strategy for performing manualdata conversion in contrast toautomated conversions.



Module Functional Design Custom module designs expressed inuser terms.

Module Technical Design Specifications for the programmodules with sufficient technical detailenabling the programs to besuccessfully coded.

Performance RiskAssessment

Study of the performance risksinherent in the chosen architecture andthe techniques and steps that can betaken to mitigate the risk.

Performance Test DataDesign

The detailed design for theconstruction of the test database. Thisspecifies the business objects andvolumes needed in the test databaseand how you will populate the testdatabase with the prerequisite data.

Performance Test Scripts The details of the individual steps thatyou will execute for each transactiontest user profile.

Physical DatabaseArchitecture

The detailed design for the physicallayout of databases in the architecture.Includes the mapping of the logicaldatabase architecture onto the physicalsubsystems that support the database.

Process Narrative A textual description of a businessdiagram at a job level.

Production SupportInfrastructure

Identifies the operationalinfrastructure for managing andmaintaining the applicationenvironment, database, and networkcommunications.

Security Profiles List of role-based securityspecifications necessary to ensure goodcontrols and transaction access.



System Capacity Plan The system capacity plan for thetechnical configuration. Includes theplanning of client and server machines,and addresses CPU, memory, and diskcapacity.

System ManagementProcedures

The detailed design for the systemsmanagement procedures necessary tosupport the architecture.

Test Database Load ProgramDesigns

The designs for any programs neededto load data into the test database.

Test Transaction ProgramDesigns

The detailed design for any transactionprograms needed for the test. Thismight include programs that executetransactions against the database, orautomated programs that manage theexecution of multiple simultaneoustransaction flows.

Testing Strategy Establishes the approach and scope oftesting activities. Identifies the testingtools and environment to be used, andhow defects will be managed.

Transition and ContingencyPlan

Detailed plan for Transition includingcontingency plans if problems arise.

User Training Materials Workbooks, slides, lab exercises, andproduct demonstrations for usertraining.

Table 4-3 Solution Design Phase Key Deliverables


Approach

This section describes the approach for Solution Design.


This table lists the tasks executed and the deliverables produced duringSolution Design.

ID Task Deliverable

Business Requirements MappingBR.100 Create Process Narratives Process NarrativeBR.110 Define Application Setups Application Setup DocumentBR.120 Design Security Profiles Security ProfilesApplication and Technical ArchitectureTA.120 Design Application Security Architecture Application Security ArchitectureTA.130 Design Application Functional Architecture Application Functional ArchitectureTA.140 Design Logical Application and Database

ArchitectureLogical Application and DatabaseArchitecture

TA.150 Design Physical Database Architecture Physical Database ArchitectureTA.160 Design Hardware and Network Architecture Hardware and Network ArchitectureTA.170 Develop System Capacity Plan System Capacity PlanTA.180 Assess Performance Risks Performance Risk AssessmentTA.190 Design System Management Procedures System Management ProceduresModule Design and BuildMD.030 Define Design Standards Design StandardsMD.040 Define Build Standards Build StandardsMD.050 Design Database Extensions Database Extensions DesignMD.060 Produce Module Function Design Module Function DesignMD.070 Produce Module Technical Design Module Technical DesignMD.080 Review Detailed Designs Acceptance CertificateData ConversionCV.040 Prepare Conversion Environment Conversion EnvironmentCV.050 Perform Conversion Data Mapping Conversion Data MappingCV.060 Design Manual Conversion Strategy Manual Conversion Strategy


ID Task Deliverable

CV.070 Design Conversion Programs Conversion Program DesignCV.080 Prepare Conversion Test Plans Conversion Test PlansDocumentationDO.060 Produce Initial User Reference Manual Initial User Reference ManualDO.070 Produce Initial User Guide Initial User GuideDO.080 Produce Initial Technical Reference Manual Initial Technical Reference ManualDO.090 Produce Initial System Management Guide Initial System Management GuideBusiness Systems TestingTE.010 Develop Testing Strategy Test StrategyTE.020 Develop Unit Test Scripts Unit Test ScriptsTE.030 Develop Link Test Scripts Link Test ScriptsTE.040 Develop System Test Scripts System Test ScriptsTE.050 Develop Systems Integration Test Scripts Systems Integration Test ScriptsPerformance TestingPT.050 Create Performance Test Scripts Performance Test ScriptsPT.060 Design Performance Test Transaction Programs Test Transaction Program DesignsPT.080 Design Performance Test Data Performance Test Data DesignPT.090 Design Test Database Load Programs Test Database Load Programs DesignsTrainingTR.070 Develop User Training Materials User Training MaterialsProduction MigrationPM.020 Design Production Support Infrastructure Production Support InfrastructurePM.030 Develop Detailed Transition and Contingency

PlanDetailed Transition and ContingencyPlan

Table 4-4 Solution Design Phase Tasks and Deliverables


Task Dependencies

This diagram shows the dependencies between tasks in Solution Design.

MD.020

Define DesignStandardsMD.030

RM.090

Define ApplicationSetupsBR.110

RM.080

Create ProcessNarratives

BR.100RM.100

Design SecurityProfilesBR.120

MD.060Produce Module

FunctionalDesignsMD.060

TA.120Design Application

SecurityArchitecture

TA.120

TA.130Design Application

FunctionalArchitecture

TA.130

TA.140Design LogicalApplication and

DatabaseArchitecture

TA.140

TA.160Design Hardware

and NetworkArchitecture

TA.160

TA.170

Develop SystemCapacity Plan

TA.170

TA.180Assess

PerformanceRisks

TA.180

TA.150Design Physical

DatabaseArchitecture

TA.150

MD.050

Design DatabaseExtensions

MD.050

CV.040 Prepare

ConversionEnvironment

CV.040

BUSINESS

REQUIREMENTS

MAPPING

MODULE DESIGN

AND BUILD

APPLICATION AND

TECHNICAL

ARCHITECTURE

SolutionDesign

DATA

CONVERSION

MD.050

Define BuildStandards

MD.040

A B

Figure 4-2 Solution Design Phase Task Dependencies


BUSINESS

REQUIREMENTS

MAPPING

MODULE DESIGN

AND BUILD

APPLICATION AND

TECHNICAL

ARCHITECTURE

SolutionDesign

DATA

CONVERSION

MD.070

Produce ModuleTechnical Designs

MD.070

TA.190Design SystemManagementProcedures

TA.190

CV.050 PerformConversion Data

MappingCV.050

CV.060Design Manual

ConversionStrategyCV.060

CV.070

Design ConversionProgramsCV.070

CV.080 PrepareConversion Test

PlansCV.080

MD.080

Review DetailedDesignsMD.080

C D E F G H

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


TE.010

Develop TestStrategyTE.010

PM.020Design Production

SupportInfrastructure

PM.020

BUSINESS SYSTEM

TESTING

DOCUMENTATION

SolutionDesign

PERFORMANCETESTING

TRAINING

PRODUCTIONMIGRATION

A B



BUSINESS SYSTEM

TESTING

DOCUMENTATION

SolutionDesign

PERFORMANCE

TESTING

TRAINING

PRODUCTION

MIGRATION

TE.020

Develop Unit TestScriptsTE.020

TE.030

Develop Link TestScriptsTE.030

TE.040

Develop SystemTest Scripts

TE.040

PT.050Create

Performance TestScriptsPT.050

PT.060Design

Performance TestTransactionPrograms

PT.060

PT.080Design

Performance TestData

PT.080

PT.090Design Test

Database LoadPrograms

PT.090

TE.090Develop SystemIntegration Test

ScriptsTE.050

DO.060

Produce InitialUser Reference

DO.060

DO.070

Produce InitialUser Guide

DO.070

DO.090Produce Initial

SystemManagement

GuideDO.090

TR.070

Develop UserTraining Materials

TR.070

DO.080Produce Initial

TechnicalReference

DO.080

PM.030Develop Detailed

Transition andContingency Plan

PM.030

DC E F G H



Managing Risks

The areas of risk and mitigation for Solution Design include thefollowing:

Risk Mitigation

Disruptive testing due tounplanned revisions, eventhough decisions have beenmade regarding keyapplication setups.

Create a comprehensive testingstrategy that details the coordinationand execution of every task in thetesting process, that should bedeveloped and communicated priorto commencement of any testing-related activity.

Disruption to designactivities due to frequentchanges in requirementsdesign and assumptions, andweak control over designlibraries.

Implement a configurationmanagement subsystem forcontrolling project deliverables.

Establish review and sign-off processfor each design.

Inaccurate or non-existentcapacity planning.

Encourage detailed capacity planningincluding future volume projections,peak periods, and changes ofheadcount.

Assess capacity risks and the strategyfor dealing with uncertainties.

Ensure expertise is available tosupport the need for capacityplanning.

Lack of good businessvolume informationnecessary for capacityplanning.

Train project staff in techniques forgathering business volumeinformation.


Risk Mitigation

Ensure effective managementsupport for the project, includingencouraging assignment ofknowledgeable staff to provideinformation to the project team.

Lack of clear standards andprocedures for databasedesign.

Conduct reviews of database designbefore approving.

Ensure that appropriate databasedesign standards are followed.

Poor design of automatedtool test programs leading tore-coding to changetransaction models and ratesduring test execution.

Recruit experienced automatedtesting tool technical staff or allowtime to adequately train staff on thetool.

Inaccurate or incompleteapplication setup data.

Link solution designs and setup datadefinitions to Definition andOperations Analysis deliverables.

Inadequate design standards. Encourage the development and useof design standards.

Conversion data mapping isincomplete due to applicationconfiguration issues notbeing resolved and datadefaults not selected.

Resolve the application setupunresolved issues that impact theconversion data mapping and decideon required data defaults.

Incorrect data conversionrules in conversion programdesign document.

Provide project team training onestablishing data conversion rules.

Define all conversion rules thatimpact the conversion code in theConversion Design deliverable.


Risk Mitigation

Inaccurate or incompletelinking between mappingsolutions and test plans.

Ensure that test scripts, including testspecifications and data profiles, buildon the mapping scenarios that weredeveloped during BusinessRequirements Definition.

Failure to develop a completeand thorough testing strategythat covers not only testexecution, but also thecoordination of test scriptdevelopment resources,testing environments andtools, defect managementand the overall approach tothe testing process.

Create a comprehensive testingstrategy that details the coordinationand execution of every task in thetesting process (develop andcommunicate prior tocommencement of any testing-relatedactivity).

Inadequate reflection ofbusiness requirements in testscripts.

Involve team members who wereresponsible for analyzing businessprocesses and developing businessrequirements in test scriptdevelopment.

Underestimation ofTransition resourcerequirements.

Develop a detailed plan mappingtransition activities to existing projectresources; if needed, augmentexisting resources by enlistingadditional client personnel and/oradditional consulting support.

Inadequate contingency plan. Emphasize the importance of havingcontingency plans to support normalbusiness operations for key processes(shipping, invoicing) in the event thatproduction cutover is unsuccessful.

Table 4-5 Risk Management Table for Solution Design


Tips and Techniques

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


Process Narratives are based on business process designs and definehow work is performed at the job level. They lay a foundation for userprocedures and user training, as well as business systems andacceptance testing. Applications setups are defined and securityprofiles are designed.


Solution Design is the phase where Application and TechnicalArchitecture is designed. The degree of detail needed for these designsdepends on the scope of the project and the project architecture process.If the architecture is being designed for a localized applicationimplementation project with a single installation, the architect willperform these tasks in detail. The system administrators can thenconfigure and set up the technical infrastructure for the new systemwithout requiring further work.

If, however, the architecture is at the enterprise level (spanning multiplesite implementations, installations, or databases) designing to the lowestlevel of detail may not be possible. Under these circumstances thearchitects will design to the degree of detail possible, with theunderstanding that the enterprise-level architecture will only addressthe enterprise-level issues. Individual architecture processes of morelimited scope will create the detailed designs for the individualimplementations.

The application architecture design developed in this phase involves thefollowing areas:

• Application Security Architecture

• Application Functional Architecture

• Logical Application and Database Architecture

• Physical Database Architecture

• Hardware and Network Architecture


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

The application architect creates a detailed application deployment planspecifying key application setup configurations, logical databasearchitecture and application installations, and determines theapplication-level security to be implemented in the system. Keyapplication setup parameters may be specified by the businessrequirements mapping team. The application architect will take thisinformation as input, validate the impact of the setup decisions onapplication data partitioning and logical database architecture and makerecommendations to the mapping team if necessary.

The technical architect works with the application architect to design thehardware and network infrastructure to support the applicationarchitecture and ensure key business and information systemsrequirements are met.


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

The overall customization approach is defined in the customizationstrategy prepared during Definition. Solution Documents producedduring the end of Operations Analysis are refined and detailed designscreated.

The first step is to define the Design and Build Standards that designersand programmers must follow. Design and Build Standards are neededfor the types of modules that you plan to build to support the solutionsdefined during Operations Analysis. For example, if no solutionsrequire the use of database triggers, related standards are not needed.Once design standards are defined, designers can begin writingfunctional design documents while the build standards are beingdocumented.

If there are many customizations, the Module Design and Build processcan consume a large portion of the schedule and budget. It is importantto schedule the appropriate technical resources and allocate time forbusiness analysts and users to participate in testing. The project planshould include sufficient detail so that resources can be assigned toindividual modules.


Data Conversion

Prepare the environment that will be used for the data conversiondesign, build, and testing tasks, then map the legacy data elements tothe Oracle Application tables and columns. If a standard interface isprovided with the Oracle Application, the legacy data should bemapped to the standard interface tables and columns.

After the conversion data mapping is complete, the conversionprograms should be designed. If an automated conversion tool is beingused, you may need traditional code. Regardless of the tools beingused, conversion business rules must be defined.

During this phase, conversion test plans are developed. A manualconversion plan needs to be constructed if manual data conversions willbe employed.

Documentation

Prototypes developed during Solution Design depict documentationdesign, format and content. They are created for user review andapproval before formal documentation begins. Usually documentationprototypes are required for:

• User Reference Manual

• User Guide

• Technical Reference Manual

• Systems Management Guide


The Testing Strategy describes the high-level direction and guidelinesfor testing all components of the application system. This includesoutlining the overall approach to the testing process, coordinating thedevelopment and execution of test scripts, scheduling adequate andappropriate testing resources, configuring testing environments andtools, and problem management. The Testing Strategy is a workingdocument that can be referenced throughout all tasks in the testingprocess.

Based on the characteristics of the system to be built, specific testingactivities may vary in importance. Specific considerations include thenumber of custom modules, availability and reliability of converteddata, system performance, number of system interfaces, the scope of


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

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

The testing process emphasizes re-using test script componentswherever possible to avoid duplication of effort. For example, whendeveloping the components of the system test scripts, it is important tobuild on the mapping scenarios and data profiles that were previouslydeveloped as well as the link test scripts that are related to the businessfunctionality that is being tested. Each level of testing builds on theprevious level, testing materials are re-used, and business processes aretested in successively larger and larger pieces.

Performance Testing

After the team arrives at feasible models for performance testing, thetechnical analysts will design the database and test programs needed tocreate the test transactions. The technical analysts decompose thetransaction models into test scripts that specify the individualtransactions and events to be created during the test. If performancetesting is using an automated load testing tool, the technical analystswill create programs to manage the specific transactions and test usersimulation. If not, there may be little or no design of specialperformance test transaction programs and the majority of the work inSolution Design will be focused on the test database design.

One of the critical success factors for this process is the inclusion oftesting against a volume test database. Performance Testing ispotentially the only area where testing of the system against asignificant volume of data occurs. Unfortunately, the bulk loading ofdata to create a database that is “industrial-sized” can be timeconsuming. There may be opportunities to leverage other work in theproject to alleviate this task (for example, by reusing the programscreated by the data conversion process). If the project has good qualityapplication data already set up, copy another database to provide thesetup data to bulk load transaction data.

Training

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


users with a thorough introduction to their new responsibilities andprocedures.


Define production support infrastructure by identifying anddocumenting the support requirements for application, database, andnetwork administration. Review the external software and hardwareproviders’ support programs and existing internal support procedures.Map the requirements to the support programs, and developprocedures to meet any requirements in areas that are not alreadycovered. Create and document a method for identifying andcategorizing internal and external support problems. Finally, develop atraining plan to communicate the support procedures to both ISpersonnel and users.

Develop a detailed transition and contingency plan that includes aseries of tasks or checklists to assist project management and users inpreparing for and executing the transition to production. The generalchecklist tasks facilitate planning and estimating Transition. Thespecific checklist tasks provide guidance in executing Transition.

The contingency plan outlines alternatives that may be implemented ifthe cutover to production is unsuccessful. It discusses thecircumstances that require the execution of a contingency plan and liststhe implementation steps. It also identifies a migration step to re-transition to the new system once problems are corrected.


Estimating


S olu tio n D es ig n

Pha

se E

ffort

Ana

lyst

App

licat

ions

Adm

inis

trat

or

App

licat

ions

Arc

hite

ct

App

licat

ions

Exp

ert

Bus

ines

s A

naly

st

Bus

ines

s Li

ne M

anag

er

Clie

nt P

roje

ct M

anag

er

Con

figur

atio

n M

anag

er

Dat

abas

e A

dmin

istr

ator

Dat

abas

e D

esig

ner

Fac

ilita

tor

IS M

anag

er

IS O

pera

tions

Sta

ff

ID T a skB u sin e ss R eq u irem en ts M ap p in g 4.7%C .B R .10 0 C re ate P rocess N arra tiv es 3.1% 95 0

C .B R .11 0 D e fin e A pplicat ion S etup s 1.5% 80

C .B R .12 0 D e sig n S ecurity P ro f ile s 0 .1% 80

A p p lica tio n & T ec h n ic a l A rch i tec tu re 5.2%C .T A .12 0 D e sig n A pplicat ion S ecu rity A rch itec ture 0.2% 60 30

C .T A .13 0 D e sig n A pplicat ion F unc t ion al A rch itec ture 0.2% 60 40

C .T A .14 0 D e sig n Log ica l A pp licat ion a nd D ataba se A rch itec ture 0.3% 40 10 10

C .T A .15 0 D e sig n P hysica l D ataba se A rch i te c ture 1.1% 80 0

C .T A .16 0 D e sig n H ard wa re an d N etw ork A rch ite c tu re 0.8% 10 0 0

C .T A .17 0 D e v e lop S ystem C ap ac ity P la n 1.0% 20 0 0

C .T A .18 0 A sse ss P erf orm ance R isks 0.5% 25 0

C .T A .19 0 D e sig n S ys te m M an age m ent P ro ced ures 1.1% 10 20 0 0

M o d u le D e sig n & B u i ld 21 .2 %C .M D .03 0 D e fin e D es ign S tand ard s 0.3%

C .M D .04 0 D e fin e B uild S tand ard s 0.3%

C .M D .05 0 D e sig n D atab ase E x tens ion s 0.4% 60

C .M D .06 0 P rod uce M od ule F un c tio na l D esig n 6.1% 20

C .M D .07 0 P rod uce M od ule T ech nica l D esig n 12.0%

C .M D .08 0 R e v ie w D e ta iled D esigns 2.2% 30 0

D a ta C o n v ers io n 20 .2 %C .C V .04 0 P rep are C o nv ersio n E nv iron m e nt 0 .9% 20

C .C V .05 0 P erf orm C onv ersion D a ta M a pping (M ap C onv ersion D a ta ) 11 .3%

C .C V .06 0 D e sig n M anu al C o nv e rsio n S tra teg y 0.8% 0

C .C V .07 0 D e sig n C on v e rsion P ro gram s 4.8%

C .C V .08 0 P rep are C o nv ersio n T e st P roce du res 2.4%

D o cu m e n ta tio n 14 .1 %C .D O .0 60 P rod uce In it ia l U ser R ef eren ce M anu al 6 .5%

C .D O .0 70 P rod uce In it ia l U ser G uide 5.2% 20

C .D O .0 80 P rod uce In it ia l T e chn ica l R e fere nce M an ua l 1 .9%

C .D O .0 90 P rod uce In it ia l S ystem M a na gem en t G u ide 0.5%

B u sin e ss S y stem T estin g 8.9%C .T E .01 0 D e v e lop T est S tateg y 0.3%

C .T E .02 0 D e v e lop U n it T est S c rip ts 1 .2%

C .T E .03 0 D e v e lop L ink T es t S crip ts 3 .0%

C .T E .04 0 D e v e lop S ystem T es t S crip ts 3 .5% 60

C .T E .05 0 D e v e lop S ystem s In te grat io n T es t S crip ts 0 .9% 20

P erfo rm an ce T estin g 3.9%C .P T .05 0 C re ate P erfo rm a nce T est S crip ts 1 .3% 30

C .P T .06 0 D e sig n P erfo rm a nce T e st T ran sac t ion P ro gram s 1.9%

C .P T .08 0 D e sig n P erf orm an ce T es t D a ta 0.2% 30

C .P T .09 0 D e sig n T es t D a ta base Loa d P rog ram s 0.5% 10

T ra in in g 6.2%C .T R .0 70 D e v e lop U ser T ra in in g M ateria ls 6 .2% 45 0

P ro d u ctio n M ig ratio n 2.3%C .P M .0 20 D e sig n P ro du c tio n S upp ort In f rastruc ture 0.8% 0 0

C .P M .0 30 D e v e lop D e ta iled T ran sit ion & C o ntinge ncy P lan 1.5% 0 0 0 0

P ro je ct M an ag em e n t 13 .2 %P JM M an ag e Ph ase 13.2%

C O N T C o nting ency 0.0%

10 0.0%

Table 4-6 Solution Design Phase Estimating


IS S

uppo

rt S

taff

Lead

Tes

ter

Mod

ule

Des

igne

r

Net

wor

k A

dmin

stra

tor

Pro

duct

ion

Dat

abas

e A

dmin

istr

ator

Pro

gram

mer

Pro

ject

Dat

abas

e A

dmin

istr

ator

Pro

ject

Man

ager

Pro

ject

Spo

nsor

Qua

lity

Aud

itor

Sys

tem

s A

dmin

istr

ator

Sys

tem

Arc

hite

ct

Tea

m L

eade

r-A

rchi

tect

ure

Tea

m L

eade

r -

BR

Tea

m L

eade

r-C

onve

rsio

n

Tea

m L

eade

r-C

usto

miz

atio

n

Tea

m L

eade

r -

Doc

umen

tatio

n

Tea

m L

eade

r-M

appi

ng

Tea

m L

eade

r-P

erfo

rman

ce T

estin

g

Tea

m L

eade

r -

Tes

ting

Tea

m L

eade

r-T

rain

ing

Tec

hnic

al A

naly

st

Tec

hnic

al A

rchi

tect

Tec

hnic

al E

xper

t

Tec

hnic

al E

xper

t - B

uild

Tec

hnic

al E

xper

t - D

esig

n

Tec

hnic

al E

xper

t - E

nviro

nmen

t

Tec

hnic

al E

xper

t - E

xist

ing

Sys

tem

s

Tec

hnic

al W

riter

Tes

ter

Tra

iner

Use

r

5 10 0

10 10 10 0

10 10 10 0

10 10 0

10 0

10 30 10 0

20 10 0

10 35 45 10 0

10 20 50 10 0

0 25 50 10 0

20 40 10 10 0

10 90 10 0

10 90 10 0

40 10 0

80 0 10 0

90 10 10 0

30 30 10 0 10 0

30 40 10 10 0

0 10 90 10 0

10 90 10 0

90 10 10 0

10 90 10 0

10 90 10 0

10 70 10 0

20 80 10 0

20 80 10 0

10 0 10 0

20 80 10 0

80 20 10 0

10 30 10 0

20 60 10 0

10 60 0 10 0

60 20 20 10 0

20 50 10 0

60 10 20 10 0

0 5 25 25 10 0

10 0 10 0

0 75 10 15 10 0

Table 4-6 Solution Design Phase Estimating (cont.)


Scheduling

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


Scheduling suggestions for Solution Design follow:

Project Management

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

Consistently applying the policies, procedures, standards, guidelines,and tools provided to solution designers can have a positive impact onthe timeline. For example:

• Use an effective test database instance with sufficient test data toexplore different solution scenarios.

• Use design walkthroughs to identify integration problems thatcould be time consuming if discovered during testing.

• Require unit test plans.

• Control design changes.

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

In addition to application customizations, solution designs for dataconversion, interfaces, technical architecture, performance testing, anduser training are produced during this phase. Emphasis oncustomizations may detract from the importance of addressing theseother development areas. Thorough planning and tracking can preventschedule slippage due to last minute training material development oran interface that was overlooked.

If a phased deployment approach will be used you may have bothlegacy and new systems in production simultaneously. How willconsolidated reporting and queries be addressed? You may need


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

Issue management can have a major impact on the Solution Designschedule. Emphasize the importance of identifying, documenting,investigating, and resolving issues in a timely manner.


The primary scheduling factors associated with Module Design andBuild are:

• the number of available and qualified team members

• the availability of an appropriate work environment

• the accuracy and completeness of the information developed inprevious phases

• the extent to which tasks can be conducted in parallel

Data Conversion

Allow for changes to the conversion modules caused by the discoveryof new requirements during the performance of Module Design andBuild tasks.

Documentation

The time needed to develop documentation is frequentlyunderestimated. Consider using professionals (for example, technicalwriters) to improve productivity.

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

Business Systems Testing

Business System Testing requires carefully documented test scenariosthat include expected results. To adequately test a complex system youneed sufficient data to exercise application functionality. Inadequatepreparation 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 practicalperformance tests. There may be ways to ensure your system will be


able to handle the anticipated production load. For example, manyhardware vendors, in conjunction with Oracle, provide performancetesting services.

Performance testing may be complicated by multi-phase/multi-sitedeployment approaches, resulting in a longer time requirement.

Training

Training approaches may impact the schedule, for example:

• Will standard Oracle training, custom training, or a combinationbe used?

• Will internal or external instructors be used?

• Will internal instructors need specialized training on how to teachthe class?

• Will classes be conducted at multi-sites simultaneously? If so,separate database instances may be needed for each site sostudents can do the exercises.

• What is an acceptable class size? Multiple sessions of someclasses may be required to accommodate students.

Unless you use experienced curriculum developers, it is easy tounderestimate the resources and time required to develop customtraining materials.

In many cases, changes in user policies and procedures accompany anapplications implementation. Be sure that users are trained in systemfunctions, company policies, and job procedures.


Detailed plans are required for the production application setup, dataconversion, systems administration, and data administration tasks. It iseasy to underestimate the time required for this process.

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

• Employees must be set up before you can enter project managersinto Project Accounting or Buyers into Purchasing.


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

Operating system and Applications logons and passwords must beestablished. Project team responsibilities must also be determined andcommunicated to all users prior to production.


Staffing

This diagram illustrates a typical project organization for SolutionDesign.

Solution Design Phase Organization



Functional Analysts

Functional Lead

Business Function(A)

Functional Analysts

Functional Lead

Business Function(B)


Business FunctionSpecialists

Team Members

Team Leader

Custom Software Design& Build

Team Members

Team Lead


Team Members

Team Lead

Data Conversion

Team Members

Team Lead

Training &Documentation

Transition

Oracle ApplicationsSpecialists

Project Management

Figure 4-3 Staffing Chart for Solution Design



This section provides advice and comments on project organization forSolution Design.

Project Management

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

In multi-phase/multi-site projects there may be impacts on the design oftraining classes, technical architecture, interface modules, applicationextensions, and data conversion custom software modules.


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

For multi-phase/multi-site deployments, try to select staff who haveexperience with this approach. Experienced staff may identify keyrequirements that otherwise might be missed.


Participation by skilled technical architects is critical. The InformationSystems department may be reluctant to use external technicalarchitects if they believe their group expertise is sufficient. Whether thetechnical architect is an employee or consultant is less important thanthe qualifications they bring to the process. Verifying that the technicalarchitecture will support the future system load is a critical componentof a successful project.


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


A good development lead on a medium to large project can manage theschedule and provide technical leadership. On a small project theproject manager might perform this role. The development lead isresponsible for the creation of custom extensions, an expensivecorporate asset. Using a structured, systematic development approachthat emphasizes quality control is essential.

If multiple deployment phases are used, additional customizations maybe requested or required for each deployment. Determine if additionalinterface development and data conversion tasks will be needed by aspecific deployment.

Data Conversion

To design data conversion solutions, both technical and functionalexpertise and a good understanding of application integration dataconsiderations are needed.


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

If a phased deployment to different parts of your organization willoccur, determine the testing requirements that must be satisfied for eachuser community. Their approval of the system is closely tied to theBusiness System Testing results. Extensive or complicated testing mayrequire additional staff.

Performance Testing

Performance testing usually requires specialists. Hardware vendorsmay provide performance testing services at their own sites. You maybe able to leverage their staff and facilities.

If you deploy in multiple phases, your system load will increase overtime. This potentially complicates performance testing but allows a costsavings by phasing in additional computer and network capacity asnecessary.

Training

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


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

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


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

Oracle Method Build 5 - 1

C H A P T E R

5 Build

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


SolutionDesign






Documentation

Performance Testing

Training



Data Conversion

Figure 5-1 Context of AIM Build Phase

T

5 - 2 Build AIM Method Handbook

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 OracleApplications

– temporary bridge subsystems which transaction databetween legacy and new systems during multipledeployments

• Create, test, and accept database extension and installationroutines.

• 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 performancetests, and prepare a report.


The critical success factors of Build follow:


• clear understanding of the business objectives being addressed bythe project

• effective participation by executive and user management


• 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 deliverablesfor Build.


Module Design and Build Application Setup Document

Approve Designs

Build Standards


Link Test Scripts

Module Functional Design


Physical Resource Plan

Unit Test Scripts

Custom Database Objects

Develop Environment

Installation Routines

Module Source Code



Data Conversion Conversion Data Mapping



Conversion Testing Plans


Detailed Transition andContingency Plan

Business Object Tested ConversionPrograms

Conversion Programs

Unit Tested Conversion Programs

Validation Tested ConversionPrograms

Documentation Design Standards

Document Prototypes andTemplates

Document Standards andProcedures

Documentation Requirements

Initial System Management Guide

Initial Technical Reference Manual

Initial User Guide

Initial User Reference Manual

Online Help Text

System Management Guide

Technical Reference Manual

User Guide

User Reference Manual



Business System Testing Business Requirements Scenario

Process Narrative


System Test Scripts

Systems Integrated Test Scripts

Testing Strategy

Integration Test Systems

Link Test Modules

Performance Test Results

Prepared Users

System Test Applications

Testing Environments

Test Install Routines

Unit Test Modules

Performance Testing Perform Test Data Design

Perform Test Transactions Models

Perform Testing Strategy

Test Database Load ProgramDesigns

Test Transaction Program Designs

Performance Tested Database

Performance Tested Environment

Performance Tested Report

Tested Database Load Programs

Tested Transaction Programs

Table 5-1 Build Phase Overview Table

Prerequisites

Prerequisites for Build follow. You should use these prerequisites, ifthey exist, prior to beginning this phase. Otherwise, you may need tocreate them during Build.

Prerequisite Source

Application Function Architecture Application and TechnicalArchitecture


Prerequisite Source

Application Security Architecture Application and TechnicalArchitecture

Application Setup Document Business RequirementsMapping

Approve Designs Module Design and Build

Build Standards Module Design and Build

Business Requirements Scenarios Business RequirementsDefinition

Conversion Environment Data Conversion

Conversion Program Design Data Conversion

Conversion Testing Plans Data Conversion

Conversion Test Procedures Data Conversion

Conversion Data Mapping Data Conversion


Database Extension Designs Module Design and Build

Design Standards Module Design and Build

Detailed Transition and ContingencyPlan


Documentation Prototypes andTemplates

Documentation


Documentation



Prerequisite Source

Hardware and Network Architecture Application and TechnicalArchitecture

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 DatabaseArchitecture


Module Function Designs Module Design and Build

Module Technical Designs Module Design and Build

Performance Risk Assessment Application and TechnicalArchitecture

Performance Test Data Designs Performance Testing

Performance Test Scripts Performance Testing

Performance Test TransactionModels

Performance Testing

Performance Test Strategy Performance Testing

Physical Database Architecture Application and TechnicalArchitecture

Physical Resource Plan Project Management

Process Narratives Business RequirementsDefinition

Production Support Infrastructure Production Migration


Prerequisite Source

Security Profiles Business RequirementsDefinition

System Capacity Plan Application and TechnicalArchitecture

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


Model Design and Build

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

Data Conversion

Develop and test the conversion programs and perform conversionbusiness object and validation testing.

Documentation

Complete final updates to the documentation and prepare for transferof ownership to the user community. Create and install the online helptext.



Prepare testing environment and perform testing tasks for the customextensions and total business solution. This includes the execution ofthe test scripts, documentation and analysis of test results, and theproblem management process whereby identified errors are resolvedand re-tested.

Performance Testing

Develop the special database load and transaction programs, constructthe test database, create the test environment, and execute theperformance tests. Document the testing process and results in the finalperformance test report.

Key Deliverables



Business Object TestedConversion Programs

A record of information about theconversion programs that have beentested.

Conversion Programs Conversion code needed for dataconversion.

Custom Database Objects New tables, indexes, views,sequences, grants, and synonymsrequired to support the customextensions. A component of thisdeliverable is scripts to create thenew database objects in theproduction environment.

Development Environment The environment to support customsoftware development.



Installation Routines Operating system shell scripts, SQL*Loader, or terminal keystroke files toinstall and configure customextensions in the productionenvironment. This may also includedocumented manual procedures foronline setup that cannot be easilyscripted.

Integration Tested System A set of systems whose interfaceshave been tested.

Link Tested Modules Tested modules that interact witheach other.

Module Source Code Forms, Reports, SQL, PL/SQL, C andother code for the new modules. Fornon-coded modules such asFlexfields and Alerts, this representsthe online implementation of thesesolutions.

Online Help Text Online user reference (full-screen textwith suggestions regarding systemusage and error messages).

Performance Test Database The database(s) to be used forexecuting the performance tests. Itshould have a significantly greatervolume of data than is usual forbusiness system test databases. Ingeneral, it will include bothapplication setup data andtransaction data. Depending on thecircumstances and timing of theproject, the database may be sparselypopulated, but will have all the dataneeded to allow the test transactionprograms to execute flawlessly.



Performance TestEnvironment

A fully configured performance testis executed. The environmentincludes hardware, networks, testdatabase(s), automated test executiontools, and monitoring tools. All stepsshould have been taken to allow theperformance test team to connect tothe system and start the execution ofthe performance tests.

Performance Test Report Report summarizing the performancetest including the test approach, thetest models, test hardware andsoftware configuration, test results,and conclusions.

Performance Test Results Performance test measurements.

Prepared Users Users trained in specific standardand custom applicationsfunctionality.

Regression Tested ExecutionModules

Modules that have been tested toensure defects have been corrected.

System Management Guide Procedures for managing theapplication (for example, backup,recovery, audit, security).

System Tested Applications Applications that have been systemtested.

Technical Reference Manual A manual providing technicalinformation for use duringapplication maintenance.

Test Database LoadPrograms

Coded and tested data loadprograms that will be used topopulate the performance testdatabase.



Test Transaction Programs Coded and tested transactionprograms that will be used to executethe performance test.

Tested Conversion Programs Data conversion programs that havebeen tested.

Tested Installation Routines Validated installation routines forcustom modules.

Testing Environments The environment to be used fortesting custom software.

Unit Tested Modules Custom software modules that havebeen tested.

User Guide Procedures needed to respond to allsupported business events usingstandard and customized software.

User Reference Manual Manual to provide information tousers about system use duringproduction.

Valid Tested ConversionPrograms

Data conversion programs that havebeen tested and accepted.

Table 5-3 Build Phase Key Deliverables


Approach

This section describes the approach for Build.


This table lists the tasks executed and the deliverables produced duringBuild.

ID Task Deliverable

Module Design and BuildMD.090 Prepare Development Environment Development EnvironmentMD.100 Implement Database Extensions Custom Database ObjectsMD.110 Create Custom Modules Module Source CodeMD.120 Create Installation Routines Installation RoutinesData ConversionCV.090 Develop Conversion Programs Conversion ProgramsCV.100 Perform Conversion Unit Test Unit Tested Conversion ProgramsCV.110 Perform Conversion Business Object Test Business Object Tested Conversion

ProgramsCV.120 Perform Conversion Validation Test Validation Tested Conversion

ProgramsDocumentationDO.100 Complete User Reference Manual User Reference ManualDO.110 Complete User Guide User GuideDO.120 Complete Technical Reference Manual Technical Reference ManualDO.130 Complete System Management Guide System Management GuideDO.140 Provide Online Help Text On-line Help TextBusiness System TestingTE.060 Prepare Testing Environments Testing EnvironmentsTE.070 Perform Unit Test Unit Tested ModulesTE.080 Perform Link Tests Link Tested ModulesTE.090 Perform Installation Test Tested Installation RoutinesTE.100 Prepare Key Users for Testing Prepared UsersTE.110 Perform System Testing System Tested ApplicationsTE.120 Perform Regression Testing Regression Tested Custom Modules


ID Task Deliverable

TE.130 Perform Systems Integration Testing Integration Tested SystemPerformance TestingPT.070 Develop Performance Test Transaction

ProgramsTest Transaction Programs

PT.100 Develop Test Database Load Programs Test Database Load Program DesignsPT.110 Construct Performance Test Database Performance Test DatabasePT.120 Prepare Performance Test Environment Performance Test EnvironmentPT.130 Execute Performance Test Performance Test ResultsPT.140 Create Performance Test Report Performance Test Report

Table 5-4 Build Phase Tasks and Deliverables


Task Dependencies

This diagram shows the dependencies between tasks in Build.

MD.090Prepare

DevelopmentEnvironment

MD.090

MD.100ImplementDatabaseExtensions

MD.100

MD.110

Create CustomModulesMD.110

TE.070

Perform Unit TestTE.070

TE.080

Perform Link TestTE.080

PT.070Develop

Performance TestTransactionPrograms

PT.070

PT.100Construct

Performance TestDatabase

PT.100

CV.090Develop

ConversionProgramsCV.090

CV.100Perform

Conversion UnitTest

CV.100

CV.110PerformConversion

Business ObjectTest

CV.110

CV.120Perform

ConversionValidation Test

CV.120

DO.110

Complete UserGuide

DO.110

DO.100

Complete UserReference

DO.100

TE.060

Prepare TestingEnvironments

TE.060

PT.110Develop

Performance TestDatabase Load

ProgramPT.110

MODULE DESIGN

AND BUILD

PERFORMANCE

TESTING

DOCUMENTATION

DATA

CONVERSION

BUSINESS SYSTEM

TESTING

Build

Figure 5-2 Build Phase Task Dependencies


MD.120

Create InstallationRoutinesMD.120

TE.130

PerformInstallation Test

TE.130

TE.110

Perform SystemTest

TE.110

TE.130

Perform SystemsIntegration Test

TE.130

TE.120

PerformRegression Test

TE.120

PT.140Create

Performance TestReportPT.140

DO.120CompleteTechnicalReference

DO.120

DO.140

Provide OnlineHelp TextDO.140

PT.120Prepare

Performance TestEnvironment

PT.120

PT.130

ExecutePerformance Test

PT.130

DO.130Complete System

ManagementGuide

DO.130

TE.100

Prepare Key Usersfor Testing

TE.100

MODULE DESIGN

AND BUILD

BUSINESS SYSTEM

TESTING

DOCUMENTATION

DATA

CONVERSION

PERFORMANCE

TESTING

Build

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


Managing Risks

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

Risk Mitigation

Inadequate testing ofperformance test transactionprograms against theperformance test databaseprior to starting testmeasurement executions.

Begin test measurement executionsafter performance test transactionprograms have been tested andapproved.

New hardware or diskpurchases do not arrive intime for the performance testenvironment preparation.

Consider hardware or disk purchaselead times in scheduling theperformance testing.

Underestimating timeneeded to build and debugautomated performance testtool programs as well as thetest database.

Realistically assess development timefor a volume test database and/orautomated testing tool transactionprograms and discuss developmentmetrics with testing tool vendor.

Inadequately tested customcode that interferes witheffective system testing.

Perform rigorous unit and link testsof custom modules.

Ineffective conversionprograms due to insufficientconversion designs.

The conversion programmers verifythat the level of detail provided in theConversion Design is adequate.

Inadequate training of testersfor conversion businessobject and validation tests.

Train staff who will conductconversion object tests on thefunctionality of the targetapplications and testing procedures.

Insufficient test data. Ensure that sufficient time andresources are provided for test datadevelopment.


Risk Mitigation

Incomplete Business Systemand Systems IntegrationTests.

Business Systems Test and SystemsIntegration Test scripts should beexecuted and documented bypersonnel who understand thebusiness processes and interfaces thatare being tested.

Inadequate testingenvironment affecting controlover testing data andprocesses as well as thevalidity of test results.

Separate testing environments shouldbe configured to support each type oftesting, if possible. At minimum, agiven testing environment can bemanaged to support multiple types oftesting, but should not be used forother non testing-related projectactivities.

Fewer resources than neededto execute system andsystems integration testscripts and document testresults.

Ensure that sufficient resources areplanned for testing.

Inadequate defectmanagement resulting indefects that are identified butnot resolved in a controlled,reliable manner.

The defect management processshould be established in the TestingStrategy document, implementedprior to custom development, anddescribe the step-by-step process tobe followed in identifying, correcting,and re-testing a defect.

Table 5-5 Risk Management Table for Build


Tips and Techniques

This section provides tips and techniques for managing Build. Inaddition, advice and comments on each process are included.


Module Design and Build and Business System Testing are two distinctprocesses in AIM, but must be treated as a coordinated set of activitiesto ensure success. In particular, Develop Custom Modules is tightlyintegrated with Perform Unit Test and Perform Link Tests in BusinessSystem Testing. Programmers and testers repeat these three tasks foreach custom module and related sets of custom modules until allcustom extensions are ready for the business system test.

The movement of custom modules and database extensions from thedevelopment, unit, and link test environments to the business systemtest environment must be carefully executed to ensure that allcomponents function properly. This can be a major issue whencustomizations consist of a combination of different module types thathave different migration procedures. Some can be automated withscripts while other steps must be completed by entering parametersmanually in Application Object Library forms. The Business SystemTesting Strategy describes the number of testing environments and theBuild Standards define the migration procedures.

Data Conversion

During Build, the conversion programs are developed. If an automatedtool has been selected it may be used to build conversion templates thatmap the legacy data to the Oracle Application tables and then load thelegacy data into the Oracle tables.

The conversion programs should be unit tested during this phase toensure that they function as intended. Once legacy data is loaded intothe Oracle Application, the integrity of the data should be tested withineach Oracle application. In addition, a conversion validation test shouldbe executed to test the performance of the legacy data within the entiresuite of installed Oracle Applications.

Documentation

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


Reference Manual are completed, the online help text can be developedand installed. After the implementation is complete and the projectteam disbanded, the documentation will be a major resource for everyarea using the new system.


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

You may choose to perform multiple types of testing in a single testingenvironment. However, it is not recommended that testing beperformed in an environment that is concurrently supporting otherproject activities such as training or conversion testing. This practicecan cause corruption of test data or programs, inaccurate test results,and frustration for testers and the other users of the sharedenvironment.

The emphasis during Build involves testing each custom module as itmoves through development (unit and link testing) and testing theapplications and their integration with external systems (system testingand systems integration testing).

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

System testing and system integration testing should reflect actualbusiness flows and be executed in cycles. Each test specification istested multiple times with different data profiles, within the context ofdifferent occurrences of each business transaction.

Performance Testing

System and Database Administrators construct the performance testenvironment during Build. This includes:

• preparing the hardware and network connections

• migrating the fully populated test database


• migrating the special test transaction programs

• installing the applications

• installing performance monitoring tools

Administrators should perform as much environment testing aspossible before formally starting the test execution. The technicalanalysts and administrators should also perform testing of thetransaction programs, the test scripts, and the test database in the testenvironment.

The execution of a complex performance test rarely proceeds withoutinitial problems. Each iteration or test cycle may need to correctproblems in the environment found during a prior cycle or may test theeffects of a system re-tuning. There is a good deal of tuning and re-tuning necessary during the execution of a large-scale, multipletransaction performance test. To collect system measurements for aparticular set of test parameters or a test configuration may requiremultiple cycles before the system and the test programs are tunedproperly to give realistic or useful results.

At the end of the formal performance test process, a performance testreport summarizes the work performed by the team during the process,the results obtained, and conclusions and recommendations. Thecreation of a formal report is optional and may not be necessary if theperformance test process is relatively limited in scale and is not makingstrategic or critical project recommendations. The project mangerresponsible for the performance test project will decide whether aformal report is warranted.

At the end of the formal testing process, the programs and scripts maybe useful for performance regression testing in a continuingperformance quality management system. Before making changes tothe production technical configuration, or the applying of softwarepatches or upgrades, the business can use the performance test suite toassess the performance impact of changes.


Estimating


Build

Pha

se E

ffort

Ana

lyst

App

licat

ion

Adm

inis

trat

or

App

licat

ions

Arc

hite

ct

App

licat

ions

Exp

ert

Bus

ines

s A

naly

st

Bus

ines

s Li

ne M

anag

er

Clie

nt P

roje

ct M

anag

er

Con

figur

atio

n M

anag

er

Dat

abas

e A

dmin

istr

ator

Dat

abas

e D

esig

ner

Fac

ilita

tor

IS M

anag

er

ID TaskModule 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



100.0%

Table 5-6 Build Phase Estimating


IS O

pera

tions

Sta

ff

IS S

uppo

rt S

taff

Lead

Tes

ter

Mod

ule

Des

igne

r

Net

wor

k A

dmin

stra

tor

Pro

duct

ion

Dat

abas

e A

dmin

istr

ator

Pro

gram

mer

Pro

ject

Dat

abas

e A

dmin

istr

ator

Pro

ject

Man

ager

Pro

ject

Spo

nsor

Qua

lity

Aud

itor

Sys

tem

s A

dmin

istr

ator

Sys

tem

Arc

hite

ct

Tea

m L

eade

r -

Arc

hite

ctur

e

Tea

m L

eade

r -

BR

Tea

m L

eade

r-C

onve

rsio

n

Tea

m L

eade

r-C

usto

miz

atio

n

Tea

m L

eade

r-D

ocum

enta

tion

Tea

m L

eade

r -

Map

ping

Tea

m L

eade

r-P

erfo

rman

ce T

estin

g

Tea

m L

eade

r-T

estin

g

Tea

m L

eade

r -

Tra

inin

g

Tec

hnic

al A

naly

st

Tec

hnic

al A

rchi

tect

Tec

hnic

al E

xper

t

Tec

hnic

al E

xper

t - B

uild

Tec

hnic

al E

xper

t - D

esig

n

Tec

hnic

al E

xper

t-E

nviro

nmen

t

Tec

hnic

al E

xper

t - E

xist

ing

Sys

tem

s

Tec

hnic

al W

riter

Tes

ter

Tra

iner

Use

r

0 25 35 10 15 100

80 100

10 90 100

100 100

0 100 100

100 100

10 90 100

10 60 100

20 80 100

40 60 100

10 10 80 100

0 15 15 70 100

40 60 100

10 30 40 100

50 50 100

20 80 0 100

20 80 100

0 75 25 100

10 10 20 60 100

10 10 20 60 100

10 10 20 60 100

85 10 100

85 10 100

25 5 70 100

10 40 5 15 100

10 30 20 20 0 100

10 0 10 45 20 100

Table 5-6 Build Phase Estimating (cont.)


Scheduling

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


Scheduling suggestions for Build follow:

Project Management

During multi-phase/multi-site deployment you may need to maintainteam development capability throughout the deployment phases.

Team size can affect the Build schedule. Maximize parallel activities byhaving as large a team as possible, but avoid going beyond the sizewhere incremental administration and communication needs candecrease productivity.


Make every effort to ensure the development environment is ready ontime. 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 facilitateproducing design documents)

• administrative procedures for issue resolution, registeringmodules, getting deliverables approved, and obtaining answersto questions

Data Conversion

For multi-phase/multi-site deployments, data conversions may bescheduled at different times according to site requirements.



For smaller projects with good user participation you may considercombining System Testing and the Acceptance Test. Combining the twotasks requires careful planning and extensive user participation but cansignificantly reduce the timeline.

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

Performance Testing

If Performance Testing needs to be repeated because previous testresults were inaccurate or insufficient computer resources have beenallocated, the schedule may change accordingly.


Staffing

This diagram illustrates a typical project organization for Build.

Build Organization



Business FunctionSpecialists

Oracle ApplicationsSpecialists

Team Members

Team Lead

Custom Software Design& Build

Team Members

Team Lead


Team Members

Team Lead

Data Conversion

Team Members

Team Lead

Training

Transition

Team Members

Team Lead

Documentation

Team Members

Team Lead

Testing

Project Management

Figure 5-3 Staffing Chart for Build



This section provides advice and comments on project organization forBuild.

Project Management

The most important staffing factor in Build is having a strongdevelopment lead. This individual needs knowledge of OracleApplications technical architecture and the custom development tools tobe used. They must motivate developers to meet deadlines and tofollow project policies and procedures.

The development environment can have an impact on the morale andproductivity of developers. Custom software developers are verydependent on their environment to perform fundamental tasks.

Fewer team members with functional skills will be required duringBuild so some may be released from the team. At the same time,developers may be added to enhance the technical staff.


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

• strong development lead

• productive work environment

• committed developers willing to follow project policies andprocedures

• planned knowledge transfer method during project teampersonnel changes for multi-phase/multi-site projects

• effective issue management

Data Conversion

Using commercially available software can significantly affect thedevelopment time during this phase and reduce staffing requirements.

If your data conversions will be audited, you should begin to assemblethe appropriate documents and statistics. If a phased conversionapproach is being used, the conversion process could span several sitedeployments. The conversion of a given business object may need to berepeated multiple times. Multi-phased conversion deployment willhave a significant impact on staffing requirements.


Documentation

The documentation completed in this phase will impact the success ofthe project after the system has gone into production. Staff this finaldocumentation effort with team members who have exceptional writingskills and are detail oriented.


The system test relies heavily on the participation of the usercommunity. Sufficient users must be available for the test and beadequately trained in the new system functionality. Their approval ofthe system test results determine if the project continues to the nextphase.

Performance Testing

The last Performance Testing steps analyze test results and developconclusions. The performance testing team can be deployed elsewhereat this time unless follow up performance testing projects will beundertaken.

Oracle Method Transition 6 - 1

C H A P T E R

6 Transition

his chapter describes the Transition phase of AIM. The goal ofTransition is to install the new application system, prepare client

personnel, establish the system administration function, and then cutover to the new system.


SolutionDesign






Documentation

Performance Testing

Training



Data Conversion

Figure 6-1 Context of AIM Transition Phase

T

6 - 2 Transition AIM Method Handbook

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.


The critical success factors of Transition follow:

• clear understanding of the business objectives

• effective participation by business management


• sufficient technical and application architecture

• available and committed support staff to implement the newsolutions

• committed user involvement and ownership

• successful performance acceptance testing

• successful completion of production readiness plan

• effective training


Overview Table

This table illustrates the prerequisites, processes, and key deliverablesfor Transition.


Data Conversion Conversion Program Design



Performance Testing Results


Converted and Verified Data

Installed Conversion Software

Training Application Setup Document


User Training Materials

Trained Users

User Training Environment



Production Migration Hardware and NetworkArchitecture

Installation Routines

Integrated Tested Systems

Logical Application andDatabase Architecture

Online Help Text


Prepared Users

Production SupportInfrastructure

Security Profiles

System ManagementProcedures

Technical Reference Manual

User Reference Manual

Configured Applications

Documented Support Procedures

Production Environment

Production System

Production-Ready System

Business System Testing Acceptance Test Results

Table 6-1 Transition Phase Overview Table


Prerequisites

Prerequisites for Transition follow. You should use these prerequisites,if they exist, prior to beginning this phase. Otherwise, you may need tocreate them during Transition.

Prerequisite Source

Acceptance Test Plan Client

Application Setup Document Business RequirementsMapping

Conversion Environment Data Conversion

Validation Tested ConversionProgram Design

Data Conversion




Hardware and Network Architecture Application and TechnicalArchitecture

Installation Routines Application and TechnicalArchitecture



Online Help Text Application and TechnicalArchitecture

Performance Testing Results Performance Testing

Physical Database Architecture Application and TechnicalArchitecture

Prepared Users Application and TechnicalArchitecture


Prerequisite Source

Production Support Infrastructure Production Migration

Security Profiles Business RequirementsMapping

System Management Procedures Application and TechnicalArchitecture

Technical Reference Manual Documentation

User Reference Manual Documentation

User Training Materials Training


Data Conversion

Table 6-2 Transition Phase Prerequisites

Processes


Data Conversion

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


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

Training

Train users and support staff in preparation for going live on the newsystem.



Prepare the production environment, including entering applicationsetups. Implement the support infrastructure, assess productionreadiness, and execute production cutover.

Key Deliverables



Configured Applications Application ready for productionuse.

Converted and Verified Data Converted data in the productiondatabase that has been reviewedand verified.

Documented SupportProcedures

Procedures for supporting the newsystem in documentation form.

Installed ConversionSoftware

Installed conversion software andautomated conversion tools used inconverting legacy data.

Production Environment Installed production environmentready to receive final configuredapplications.

Production ReadinessChecklist

Detailed production readinessverification checklist.

Production Ready System New system ready to be installed inthe production environment.

Production System New system installed in theproduction environment ready forproduction use.

Trained Users Users who have attended usertraining.



Configured Applications Application ready for productionuse.

User Training Environment Environment to be used in trainingusers.

Table 6-3 Transition Phase Key Deliverables


Approach

This section describes the approach for Transition.


This table lists the tasks executed and the deliverables produced duringTransition.

ID Task Deliverable

Data ConversionCV.130 Install Conversion Software Installed Conversion SoftwareCV.140 Convert and Verify Data Converted and Verified DataBusiness Systems TestingTE.140 Support Acceptance Test Acceptance Test ResultsTrainingTR.080 Prepare User Training Environment User Training EnvironmentTR.090 Train Users Trained UsersProduction MigrationPM.040 Prepare Production Environment Production EnvironmentPM.050 Setup Applications Configured ApplicationsPM.060 Implement Support Infrastructure Documented Support ProcedurePM.070 Verify Production Readiness Production-Ready SystemPM.080 Commence Production Production System

Table 6-4 Transition Phase Tasks and Deliverables


Task Dependencies

This diagram shows the dependencies between tasks in Transition.

PM.040Prepare

ProductionEnvironment

PM.040

PM.050

Setup ApplicationsPM.050

CV.140

Convert and VerifyData

CV.140

TR.080Prepare User

TrainingEnvironment

TR.080

TR.090

Train UsersTR.090

PM.060Implement

SupportInfrastructure

PM.060

CV.130

Install ConversionSoftwareCV.130

TRAINING

DATA

CONVERSION

PRODUCTION

MIGRATION

BUSINESS SYSTEMTESTING

Transition

Figure 6-2 Transition Phase Task Dependencies


TE.140

SupportAcceptance Test

TE.140

PM.070

Verify ProductionReadiness

PM.070

PM.080

CommenceProduction

PM.080

TRAINING

DATA

CONVERSION

PRODUCTION

MIGRATION

BUSINESS SYSTEMTESTING

Transition

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


Managing Risks

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

Risk Mitigation

Malfunctioning or inefficientcustom software.

Design programs with performancein mind and include customprograms in Performance Testing.

Obtain formal and independentquality signoff of all testing activities.

Inadequate productionenvironment for conversionsoftware.

Verify in Build that the productionenvironment will be prepared in timeto install the conversion software.

Ensure that qualified and effectivestaff review and approvedeliverables.

Users who are unprepared to usethe production system.

Establish a user certification orreadiness program that providesincentives for system skill mastery,and prevents system use by peoplewho have not demonstrated theproper level of qualification.

Inadequate communication ofsupport procedures to end usersprior to production cutover.

Integrate support procedures intoend-user training and system testingprocesses.

Changes made to applicationsetups in the testing environmentnot documented in theproduction setup documents orimplemented in the productionenvironment.

Establish a procedure for migratingchanges to application setups into theproduction environment.

Table 6-5 Risk Management Table for Transition


Tips and Techniques

This section provides tips and techniques for managing Transition. Inaddition, advice and comments on each process are included.


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

Data Conversion

The conversion software should be installed in the productionenvironment. Assuming the prerequisite testing tasks are complete, thelegacy data should be converted to the Oracle Application productionenvironment and verified for accuracy and audit requirements.


The final testing task involves supporting trained end users in theexecution of the Acceptance Test. The system’s functionality will bemeasured in general against business requirements, and specificallyagainst Acceptance Test Criteria.

If users have been involved throughout the implementation, thereshould be no surprises during the final system acceptance test. Prior tothe test, users must be trained for appropriate system skills to enabletheir successful participation in the testing effort. A procedure shouldbe implemented to address any issues or problems that are identifiedduring testing, and all resolutions must be communicated to theacceptance test team.

Training

User training should be delivered prior to the new system going intoproduction; 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 bestapproach is to conduct a program of user certification or readinesstesting.

To retain the students’ attention and avoid overwhelming them withinformation, it is important to break training sessions into manageablesections that focus on clear objectives. Providing hands-on interaction


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


The Business System Testing and Training tasks during Transitionprovide opportunities to test the support procedures that have beendeveloped and documented. Distribute support materials throughoutthe company, and review them during user training and testingpreparation. Practice logging technical assistance requests (TARs)during testing and training to familiarize users with the supportprocedures and to highlight any areas lacking sufficient coverage.

Notify external vendor support groups of the production cutoverschedule. You may want to request additional support coverage duringthis period.

The typical transition time period is one month for small to moderateprojects with one deployment phase and includes the execution of alltraining, support infrastructure, data conversion, and the setup of theproduction environment.

A meeting with the entire organization will allow management toanswer any concerns and review contingency plans. In addition, keymanagers should be notified of the impending transition so they can beprepared to deal with any issues, potential delays in service, ororganizational changes.


Estimating


Transition Pha

se E

ffort

Ana

lyst

App

licat

ions

Adm

inis

trat

or

Bus

ines

s A

naly

st

Bus

ines

s Li

ne M

anag

er

Clie

nt P

roje

ct M

anag

er

Dat

abas

e A

dmin

istr

ator

IS M

anag

er

IS O

pera

tions

Sta

ff

IS S

uppo

rt S

taff

Mod

ule

Des

igne

r

Net

wor

k A

dmin

stra

tor

Pro

duct

ion

Dat

abas

e A

dmin

istr

ator

Pro

gram

mer

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

Table 6-6 Transition Phase Estimating


Pro

ject

Dat

abas

e A

dmin

istr

ator

Pro

ject

Man

ager

Qua

lity

Aud

itor

Sys

tem

Arc

hite

ct

Sys

tem

s A

dmin

istr

ator

Tea

m L

eade

r-A

rchi

tect

ure

Tea

m L

eade

r-C

onve

rsio

n

Tea

m L

eade

r-C

usto

miz

atio

n

Tea

m L

eade

r-M

appi

ng

Tea

m L

eade

r-P

erfo

rman

ce T

estin

g

Tea

m L

eade

r-T

estin

g

Tea

m L

eade

r-T

rain

ing

Tec

hnic

al A

naly

st

Tec

hnic

al A

rchi

tect

Tra

iner

Use

r

25 0 15 0 15 15 1004 11 85 100

5 30 15 50 100 5 5 25 50 100

10 30 0 100

25 35 10 1005 0 100

20 45 5 5 5 5 5 5 5 0 10020 0 100

Table 6-6 Transition Phase Estimating (cont.)


Scheduling

Migrating the business to a new production environment requires ahigh degree of planning and coordination. Scheduling is driven by theoperational concerns of the business, the effort and timing of dataconversion, and the number of users and sites to be migrated.


Scheduling suggestions for Transition follow:

Project Management

Pay particular attention to the dependencies associated with enteringsetup data and data conversion tasks. For example:

• Fixed assets account codes must be entered into the generalledger 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 thedates that transactions can be entered into the Oracle Applications mustbe determined and communicated to the user community withadequate lead time. For example, the data conversion approach maycall for closing all open purchase orders before going live. This meansthat all invoices for those purchase orders must be entered andmatched. To allow calendar time for invoices to be processed beforecut-over, you may decide that no new purchase orders or invoices canbe entered into the legacy system for two weeks before cutover to thenew applications. Purchasing and Payables would need to hold newrequisitions and invoices until they can be entered into the newpurchasing and accounts payable systems. Similar cutoff requirementsmay exist for other applications.

The focus during Transition is the transfer of knowledge about theapplication system to the user staff. This phase requires substantial userinvolvement and possibly third party vendor participation ornetworking and hardware support.

A multi-phase/multi-site deployment approach can create severalTransition challenges. You will need to repeat most, if not all,Transition tasks for each deployment.


Data Conversion

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


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

Training

Multi-phase/multi-site deployment approaches may require training tobe 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 classconducted simultaneously with other classes

• development of training data to support class exercises

• identification and distribution of class operating system andapplication logon IDs, passwords, and application responsibilities

• development and distribution of user manuals to classes and usersites prior to cutover

• availability of technical support personnel to deal with problemsduring classes


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


Staffing

This diagram illustrates a typical project organization for Transition.

Transition Organization



Applications

Data Conversion

Data Base


Technical Support

Team Members

Team Lead

Training

Team Members

Team Lead

Documentation

Team Members

Team Lead

Transition

Project Management

Figure 6-3 Staffing Chart for Transition



This section provides advice and comments on project organization forTransition.

Project Management

In addition to standard functionality testing, the Acceptance Test mayinclude:

• a test to simulate cutover and a day of production use; this isperformed in conjunction with an iteration of data conversion

• a parallel test that consists of running both the new applicationand the legacy system in parallel and performing the sameoperations with both; the results are verified to ensure that thenew system has the same functionality as the legacy system

Once Transition is complete, the client staff should be able to supportand maintain the application without outside assistance. Users shouldbe 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 andsignoff.

For multi-phase/multi-site deployments, data conversion teammembers may be needed over a long time period. Enable new teammembers to be productive quickly by carefully documenting conversionactivities.


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

Training

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



Do not release specialists from their team responsibilities too soon.There are usually unexpected issues near and during productioncutover that may require their assistance.

Oracle Method Production 7 - 1

C H A P T E R

7 Production

his chapter describes the Production phase of AIM. The goal ofProduction is to monitor and ensure that the application is

performing adequately, and to plan for future functional enhancements.


SolutionDesign






Documentation

Performance Testing

Training



Data Conversion

Figure 7-1 Context of AIM Production Phase

T

7 - 2 Production AIM Method Handbook

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.


The critical success factors for Production follow:

• effective change control tools and procedures

• accurate compilation of volumes, transaction histories, and otherperformance drivers


• adequate staff and expertise

• effective participation by business management and users

• effective technical and application architecture


Overview Table

This table illustrates the prerequisites, processes, and key deliverablesfor Production.


Production Migration Application FunctionalArchitecture



Architecture Scope and Objectives

Conversion Scope and Objectives

Data Conversion Strategy



performance Testing Strategy

Process Narrative

Production System


System Management Guide

Transition Strategy

Business DirectionRecommendations

Decommissioned Former System

Maintained ProductionEnvironment

Post Implementation ProductionSystem

Refined Production Environment

System Performance Assessment

Technical DirectionRecommendations

Table 7-1 Production Phase Overview Table

Production begins after the application system has gone intoproduction. During this phase the application implementation project isbrought to completion. The remaining development team reviews the


application under actual usage conditions. Problems are logged andanalyzed, performance exceptions are found, and tuning is performed.The business takes over maintenance of the application and plans aremade 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 tocreate them during Production.

Prerequisite Source

Application Functional Architecture Application and TechnicalArchitecture

Application Security Architecture Application and TechnicalArchitecture


Architecture Scope and Objectives Application and TechnicalArchitecture

Conversion Scope and Objectives Data Conversion

Data Conversion Strategy Data Conversion

Detailed Transition and ContingencyPlan


Performance Risk Assessment Application and TechnicalArchitecture


Process Narrative Business RequirementsMapping

Production System Production Migration


Prerequisite Source

System Capacity Plan Application and TechnicalArchitecture

System Management Guide Documentation

Transition Strategy Production Migration

Table 7-2 Production Phase Prerequisites

Processes



Audit, refine, and maintain the production system, propose the futurebusiness and technical direction for the company, and decommissionthe former system.

Key Deliverables



Business DirectionRecommendations

The functional project team, alongwith senior management, beginsplanning for future improvementopportunities.

Decommission Former System Archive historical data and software.If necessary, delete systemcomponents.

Maintained ProductionEnvironment

The production environment that willbe maintained.



Post-implementationProduction System

The production environment iscarefully maintained using proceduresand techniques documented in theSystem Management Guide.

Refined ProductionEnvironment

The production system will be refinedthrough tuning, application setupchanges, and other performanceadjustments.

System PerformanceAssessment

System transaction and reportingperformance is quantified. Metrics aredefined and applied to determine howwell the system supports the technicalneeds of the business.

Technical DirectionRecommendations

The technical project team, theInformation Systems staff, and seniormanagement begin planning for usingnew technologies.

Table 7-3 Production Phase Key Deliverables


Approach

This section describes the approach for Production.


This table lists the tasks executed and the deliverables produced duringProduction.

ID Task Deliverable

Production MigrationPM.090 Audit Production System Post-Implementation Production

SystemPM.100 Measure System Performance System Performance AssessmentPM.110 Maintain System Maintained Production EnvironmentPM.120 Refine Production System Refined Production EnvironmentPM.130 Decommission Former System Decommissioned Former SystemPM.140 Propose Future Business Direction Business Direction RecommendationsPM.150 Propose Future Technical Direction Technical Direction Recommendations

Table 7-4 Production Phase Tasks and Deliverables


Task Dependencies

This diagram shows the dependencies between tasks in Production.

1 Line( 6 5/16 tall X 6 1/4 wide)

PM.090

Audit ProductionSystemPM.090

PM.110

Maintain SystemPM.110

PM.120

DecommissionFormer System

PM.130

PM.100

Measure SystemPerformance

PM.100

PM.100

Refine ProductionSystemPM.120

PM.140Propose Future

TechnicalDirectionPM.150

PM.130

Propose FutureBusiness Direction

PM.140

PRODUCTION

MIGRATIONPRODUCTION

MIGRATION

ProductionProduction

Figure 7-2 Production Phase Task Dependencies


Managing Risks

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

Risk Mitigation

Ongoing production supportstaff does not possessadequate system knowledge.

Retain contractors to provide supportduring the critical period.

Ensure ongoing support staff areadequately trained anddocumentation is effective.

System performance cannotadequately supportproduction level transactionvolumes.

Refine the production system setupand configuration based on userfeedback regarding systemperformance, reporting, and systemfunctionality.

Additional exception casebusiness requirements arediscovered as users performjob duties followingproduction cutover.

Establish an ongoing applicationsupport business function withpolicies, procedures, organization,and staff to address new andchanged requirements.

Table 7-5 Risk Management Table for Production

Tips and Techniques

This section provides tips and techniques for managing Production. Inaddition, advice and comments on each process are included.


After production cutover, new system maintenance and enhancementbegins. Some related considerations are:

• New technologies that were not available or out of scope at thebeginning of the implementation may now be considered.

• New products and applications may be investigated.


• Requested customizations that were out of scope for the initialimplementation may be addressed.

• Planning for the next release of Oracle Applications may begin.

Adapt the Module Design and Build and Business System Testingprocesses to support the design, development, and testing ofenhancements to the production system. Incorporate the updatedinformation into the Customization Strategy, Design Standards, andBuild Standards so that they represent the standards for futureenhancements. Define additional standards for tools that you may usefor future enhancements.


System maintenance falls into three major categories: routine, on-demand, and upgrade:

• Routine maintenance includes setting up and executing hot andcold backups, monitoring system performance, managingtablespace, archiving and purging data, and database tuning. Italso involves tracking updates to the production configuration,application setup, and application of patches.

• On-demand maintenance usually occurs in response to a userrequest 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 andstructural impact, particularly in the case of major upgrades.Minor upgrades are typically small changes or corrections tosystem functionality, or performance enhancements for a specificprocess.

System refinement involves soliciting user feedback and acting onrequests relative to the implementation, production system, or support.These requests may involve adjusting application setups or profileoptions, tuning a report or form, or major programming enhancements.All enhancement requests should be logged, evaluated in terms ofimpact to the system and/or organization, and tested thoroughly priorto implementing the changes in the production environment.

It is strongly recommended that a separate shadow instance be createdand refreshed from the production instance to provide an environmentthat resembles the production configuration but is safe for testingpatches, upgrades, and system refinements.


Estimating


Production Pha

se E

ffort

Ana

lyst

App

licat

ion

Adm

inis

trat

or

App

licat

ions

Arc

hite

ct

App

licat

ions

Exp

ert

Bus

ines

s A

naly

st

Bus

ines

s Li

ne M

anag

er

Clie

nt P

roje

ct M

anag

er

Con

figur

atio

n M

anag

er

Dat

abas

e A

dmin

istr

ator

Dat

abas

e D

esig

ner

Fac

ilita

tor

IS M

anag

er

IS O

pera

tions

Sta

ff

ID TaskProduction 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



100.0%

Table 7-6 Production Phase Estimating


IS S

uppo

rt S

taff

Lead

Tes

ter

Mod

ule

Des

igne

r

Net

wor

k A

dmin

stra

tor

Pro

duct

ion

Dat

abas

e A

dmin

istr

at

Pro

gram

mer

Pro

ject

Dat

abas

e A

dmin

istr

ator

Pro

ject

Man

ager

Pro

ject

Spo

nsor

Qua

lity

Aud

itor

Sys

tem

s A

dmin

istr

ator

Sys

tem

Arc

hite

ct

Tea

m L

eade

r -

Arc

hite

ctur

e

Tea

m L

eade

r -

BR

Tea

m L

eade

r -

Con

vers

ion

Tea

m L

eade

r -

Cus

tom

izat

ion

Tea

m L

eade

r -

Doc

umen

tatio

n

Tea

m L

eade

r -

Map

ping

Tea

m L

eade

r -

Per

form

ance

Tes

t

Tea

m L

eade

r -

Tes

ting

Tea

m L

eade

r -

Tra

inin

g

Tec

hnic

al A

naly

st

Tec

hnic

al A

rchi

tect

Tec

hnic

al E

xper

t

Tec

hnic

al E

xper

t - B

uild

Tec

hnic

al E

xper

t - D

esig

n

Tec

hnic

al E

xper

t Env

ironm

ent

Tec

hnic

al E

xper

t - E

xist

ing

Sys

te

Tec

hnic

al W

riter

Tes

ter

Tra

iner

Use

r

0 50 0 100

40 20 100

0 20 50 10 100

15 20 15 20 100

0

25 100

50 50 100

Table 7-6 Production Phase Estimating (cont.)


Scheduling

The project changes its focus to providing initial support for theproduction environment as well as transferring knowledge andresponsibilities to the ongoing applications support infrastructure.


Scheduling suggestions for Production follow:

Project Management

Although budgetary concerns may be an issue, retain sufficientresources to complete the project in a quality manner.

Verify that you have completed the following activities:

• prepared the organization’s application support group to dealwith questions and initial system problems

• provided the appropriate applications and technical architectureto support the system load

• facilitated preparation of support infrastructure mechanisms

• developed appropriate documentation for support organizations

• trained the users and provided them with effectivedocumentation

Multiple deployments require multiple iterations of Production taskswhich may differ in significant ways. This will have a schedulingimpact.

Complexities that can affect scheduling are:

• “Mini” AIM phases and processes may be needed for eachdeployment unless the business functions operate exactly thesame at all sites.

• Procedural workarounds that address gaps may vary accordingto specific site requirements and could require adjustments to theuser training classes and user documentation.


• New interface and data conversion requirements could exist forspecific deployments if legacy systems are not availablethroughout the company.

• Oracle Applications upgrades may be necessary during therollout period.

The implementation development project does not end when the teaminstalls the application system into production; auditors must performthe system evaluation, and users may have questions or issues to beresolved. Production prepares for these situations in an organized andsystematic way. There is also an opportunity for the client andconsultants to plan future development efforts.


Staffing

This diagram illustrates a typical project organization for Production.

Production Organization


Team Members

Team Lead

Technical Support

Team Members

Team Lead

Training andTransition Support

Project Management

Figure 7-3 Staffing Chart for Production


This section provides advice and comments on project organization forProduction.

Project Management

In addition to support and maintenance responsibilities, Productionrequires other client involvement. Users must be prepared to provideinput into the system audit and may need to provide data ontransaction volumes and response times. In addition, users may beasked to search for and report as many problems as possible during thewarranty period.

During Production, the project team is usually limited to developersand support personnel. Each team member has to maintain or supporta broad functional area and must be cross-trained appropriately for thisresponsibility.

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 clientor a third party auditor). Use this time to transfer the ongoing jobs ofsupport and maintenance to the user.


The primary staffing challenges in Production are:

• retaining an appropriate number of team members to completethe project

• transferring responsibilities to user groups

• managing staff during the rollout of a multi-phased deploymentwhen key personnel may not be available for the project duration

Oracle Method AIM Work Breakdown Structure A - 1

A P P E N D I X

A AIM Work

Breakdown

Structure

his appendix provides a list of the full AIM work breakdownstructure (WBS).T

A - 2 AIM Work Breakdown Structure AIM Method Handbook

AIM Classic Approach Work Breakdown Structure

The following is a list of the AIM Classic approach work breakdownstructure.

ID Task Name Deliverable

A DEFINITIONA.PL Project Planning

A.PL.BEG Begin Definition Phase PlanningA.CR.010 Establish Scope, Objectives, and Approach Scope, Obj & ApproachA.CR.020 Define Control and Reporting Strategies, CR Strats, Stds & Procs

Standards, and ProceduresA.CR.030 Establish Management Plans Quality PlanA.WM.010 Define Work Management Strategies, WFM Strats, Stds & Procs

Standards, and ProceduresA.WM.020 Establish Workplan Project WorkplanA.WM.030 Establish Finance Plan Finance PlanA.RM.010 Define Resource Management Strategies, RM Strats, Stds & Procs

Standards, and ProceduresA.RM.020 Establish Staffing and Organization Plan Staffing PlanA.RM.030 Implement Organization Project OrganizationA.RM.040 Establish Physical Resource Plan Physical Resource PlanA.RM.050 Establish Infrastructure Project InfrastructureA.QM.010 Define Quality Management Strategies, QM Strats, Stds & Procs

Standards, and ProceduresA.CM.010 Define Configuration Management CM Strats, Stds & Procs

Strategies, Standards, and ProceduresA.PL.END End Definition Phase PlanningA.EX.BEG Start Definition Phase Execution

A.RD Business Requirements DefinitionA.RD.010 Identify Financial and Operating Structure Financial & Op StructA.RD.020 Conduct Current Business Baseline Current Business BaselineA.RD.030 Develop Future Process Model Future Process ModelA.RD.040 Develop Future Business Function Model Future Bus Func ModelA.RD.050 Establish Process and Mapping Summary Process & Mapping SumA.RD.060 Gather Business Volumes Bus Volume Requirements

A.TA Application and Technical ArchitectureA.TA.010 Define Architecture Scope, Objectives, Arch Scope, Obj & App

and Approach



A.TA.020 Prepare Architecture Strategy Architectural StrategyA.TA.030 Establish Architecture Requirements Architectural ReqsA.TA.040 Develop Conceptual Architecture Conceptual ArchitectureA.TA.050 Conduct Technical Architecture Baseline Technical Arch Baseline

A.MD Module Design and BuildA.MD.010 Prepare Customization Strategy Customization Strategy

A.CV Data ConversionA.CV.010 Define Conversion Scope, Objectives, Conv Scope, Obj & App

and ApproachA.CV.020 Prepare Conversion Strategy Conversion Strategy

A.DO DocumentationA.DO.010 Prepare Glossary GlossaryA.DO.020 Specify Documentation Requirements Documentation ReqsA.DO.030 Determine Documentation Standards Doc Stds & Procs

and ProceduresA.PT Performance Testing

A.PT.010 Define Performance Testing Scope, Perf Test Scop, Obj & AppObjectives, and Approach

A.PT.020 Prepare Performance Testing Strategy Perf Testing StrategyA.EX.END End Definition Phase Execution

A.TR TrainingA.TR.010 Prepare Training Strategy Performance Testing StratA.TR.030 Conduct General Education Classes Trained Project TeamA.TR.040 Conduct High-level Overview of Trained Project Team

Application FeaturesA.CT.CTR Phase Control

A.CT.BEG Begin Phase ControlA.CT.SUM Phase ControlA.CT.RES Unallocated ReserveA.CT.END End Phase Control

A.CO.COMP Phase CompletionA.CO.BEG Begin Phase CompletionA.CR.080 Secure Client Phase Acceptance Client Phase AcceptanceA.RM.080 Release Staff Released StaffA.RM.090 Release Physical Resources Released Physical

ResourcesA.QM.050 Perform Quality Assessment Quality ReportA.CM.060 Audit Key Deliverables Audited Phase BaselineA.CO.END End Phase Completion



B OPERATIONS ANALYSISB.PL.PLAN Phase Planning

B.PL.BEG Begin Phase PlanningB.PL.SUM Review and Revise Project PlansB.PL.END End Phase PlanningB.EX.BEG Begin Operations Analysis Execution

B.RD Business Requirements DefinitionB.RD.070 Create Business Requirements Scenarios Bus Reqs ScenarioB.RD.080 Determine Audit and Control Requirements Audit & Control ReqsB.RD.090 Identify Business Availability Requirements Bus Availability ReqsB.RD.100 Develop Reporting Requirements Master Rpt Tracking List

B.BR Business Requirements MappingB.BR.010 Prepare Mapping Environment Conf Mapping EnvironB.BR.020 Map Business Requirements Bus Reqs Mapping FormB.BR.030 Map Business Data Bus Data MappingB.BR.040 Conduct Integration Fit Analysis Integration Fit AnalysisB.BR.050 Develop Information Flow Model Information Flow ModelB.BR.060 Develop Information Access Model Information Access ModelB.BR.070 Conduct Reporting Fit Analysis Master Rpt Tracking ListB.BR.080 Test Business Solutions Mapping ScenarioB.BR.090 Confirm Integrated Business Solutions Acceptance Certificate

B.TA Application and Technical ArchitectureB.TA.060 Develop System Availability Strategy System Availability StratB.TA.070 Define Future Application Deployment Future Applic DeploymentB.TA.080 Develop Reporting Strategy Reporting StrategyB.TA.090 Revise Conceptual Architecture Conceptual ArchitectureB.TA.100 Define Architecture Subsystems Architecture SubsystemsB.TA.110 Propose Architecture Subprojects Arch Subproject Proposals

B.MD Module Design and BuildB.MD.020 Define and Estimate Custom Extensions Solution Document

B.CV Data ConversionB.CV.030 Prepare Conversion Standards Conversion Standards

B.DO DocumentationB.DO.040 Prepare Documentation Environment Documentation EnvironB.DO.050 Produce Documentation Prototypes Doc Prototypes &

Templates TemplatesB.PT Performance Testing

B.PT.030 Identify Performance Test Scenarios Perf Test ScenariosB.PT.040 Identify Performance Test Transaction Perf Test Trans Models

ModelsB.TR Training

B.TR.020 Prepare Project Team Training Environment Proj Team Train Environ



B.TR.050 Prepare Project Team Training Train Prep ChecklistB.TR.060 Train Project Team Trained Project Team

B.PM Production MigrationB.PM.010 Prepare Transition Strategy Transition StrategyB.EX.END End Operations Analysis Execution

B.CT.CTR Phase ControlB.CT.BEG Begin Phase ControlB.CT.SUM Phase ControlB.CT.RES Unallocated ReserveB.CT.END End Phase Control

B.CO.COMP Phase CompletionB.CO.BEG Begin Phase CompletionB.CR.080 Secure Client Phase Acceptance Client Phase AcceptanceB.RM.080 Release Staff Released StaffB.RM.090 Release Physical Resources Released Physical ResB.QM.050 Perform Quality Assessment Quality ReportB.CM.060 Audit Key Deliverables Audited Phase BaselineB.CO.END End Phase Completion

C SOLUTION DESIGNC.PL.PLAN Phase Planning

C.PL.BEG Begin Phase PlanningC.PL.SUM Review and Revise Project PlansC.PL.END End Phase PlanningC.EX.BEG Begin Solution Design Execution

C.BR Business Requirements MappingC.BR.100 Create Process Narratives Process NarrativeC.BR.110 Define Application Setups App Setup DocumentC.BR.120 Design Security Profiles Security Profiles

C.TA Application and Technical ArchitectureC.TA.120 Design Application Security Architecture Application Security ArchC.TA.130 Design Application Functional Architecture Application Func ArchC.TA.140 Design Logical Application and Log Applic and Database

Database Architecture ArchitectureC.TA.150 Design Physical Database Architecture Physical Database ArchC.TA.160 Design Hardware and Network Hardware & Network

Architecture ArchitectureC.TA.170 Develop System Capacity Plan System Capacity PlanC.TA.180 Assess Performance Risks Perf Risk AssessmentC.TA.190 Design System Management Procedures System Mgmt Procs

C.MD Module Design and BuildC.MD.030 Define Design Standards Design Standards



C.MD.040 Define Build Standards Build StandardsC.MD.050 Design Database Extensions Database Exten DesignC.MD.060 Produce Module Functional Design Module Func DesignC.MD.070 Produce Module Technical Design Module Tech DesignC.MD.080 Review Detailed Designs Acceptance Certificate

C.CV Data ConversionC.CV.040 Prepare Conversion Environment Conversion EnvironmentC.CV.050 Perform Conversion Data Mapping Conversion Data Mapping

(Map Conversion Data)C.CV.060 Design Manual Conversion Strategy Manual Conversion StratC.CV.070 Design Conversion Programs Conv Program DesignC.CV.080 Prepare Conversion Test Plans Conv Test Plans

C.DO DocumentationC.DO.060 Produce Initial User Reference Manual Initial User Ref ManualC.DO.070 Produce Initial User Guide Initial User GuideC.DO.080 Produce Initial Technical Reference Manual Initial Tech Ref ManualC.DO.090 Produce Initial System Management Guide Initial System Mgmt Guide

C.TE TestingC.TE.010 Develop Test Strategy Testing StrategyC.TE.020 Develop Unit Test Scripts Unit Test ScriptsC.TE.030 Develop Link Test Scripts Link Test ScriptsC.TE.040 Develop System Test Scripts System Test ScriptsC.TE.050 Develop Systems Integration Test Scripts Systems Int Test Scripts

C.PT Performance TestingC.PT.050 Create Performance Test Scripts Performance Test ScriptsC.PT.060 Design Performance Test Transaction Test Transac Prog Design

ProgramsC.PT.080 Design Performance Test Data Perf Test Data DesignC.PT.090 Design Test Database Load Programs Test Dbase Ld Prog Design

C.TR TrainingC.TR.070 Develop User Training Materials User Training Manuals

C.PM Production MigrationC.PM.020 Design Production Support Infrastructure Prod Support InfrastructureC.PM.030 Develop Detailed Transition & Detailed Trans & Cont Plan

Contingency PlanC.EX.END End Solution Design Execution

C.CT.CTR Phase ControlC.CT.BEG Begin Phase ControlC.CT.SUM Phase ControlC.CT.RES Unallocated ReserveC.CT.END End Phase Control

C.CO.COMP Phase Completion



C.CO.BEG Begin Phase CompletionC.CR.080 Secure Client Phase Acceptance Client Phase AcceptanceC.RM.080 Release Staff Released StaffC.RM.090 Release Physical Resources Released Physical ResC.QM.050 Perform Quality Assessment Quality ReportC.CM.060 Audit Key Deliverables Audited Phase BaselineC.CO.END End Phase Completion

D BUILDD.PL.PLAN Phase Planning

D.PL.BEG Begin Phase PlanningD.PL.SUM Review and Revise Project PlansD.PL.END End Phase PlanningD.EX.BEG Begin Build Execution

D.MD Module Design and BuildD.MD.090 Prepare Development Environment Development EnvironmentD.MD.100 Implement Database Extensions Custom Database ObjectsD.MD.110 Create Custom Modules Module Source CodeD.MD.120 Create Installation Routines Installation Routines

D.CV Data ConversionD.CV.090 Develop Conversion Programs Conversion ProgramsD.CV.100 Perform Conversion Unit Test Unit Tested Conv ProgsD.CV.110 Perform Conversion Business Object Test Bus Obj Tested Conv ProgsD.CV.120 Perform Conversion Validation Test Valid Tested Conv Progs

D.DO DocumentationD.DO.100 Complete User Reference Manual User Reference ManualD.DO.110 Complete User Guide User GuideD.DO.120 Complete Technical Reference Manual Tech Reference ManualD.DO.130 Complete System Management Guide System Mgmt GuideD.DO.140 Provide Online Help Text Online Help Text

D.TE Business System TestingD.TE.060 Prepare Testing Environments Testing EnvironmentsD.TE.070 Perform Unit Testing Unit Tested ModulesD.TE.080 Perform Link Testing Link Tested ModulesD.TE.090 Perform Installation Test Tested Install RoutinesD.TE.100 Prepare Key Users for Testing Prepared UsersD.TE.110 Perform System Testing Sys Tested ApplicationsD.TE.120 Perform Regression Testing Regression Test Exec ModD.TE.130 Perform Systems Integration Testing Integration Tested Systems

D.PT Performance TestingD.PT.070 Develop Performance Test Transaction Test Transaction Programs

Programs



D.PT.100 Develop Test Database Load Programs Test Database Load ProgsD.PT.110 Construct Performance Test Database Perf Test DatabaseD.PT.120 Prepare Performance Test Environment Perf Test EnvironD.PT.130 Execute Performance Test Perf Test ResultsD.PT.140 Create Performance Test Report Perf Test ReportD.EX.END End Build Execution

D.CT.CTR Phase ControlD.CT.BEG Begin Phase ControlD.CT.SUM Phase ControlD.CT.RES Unallocated ReserveD.CT.END End Phase Control

D.CO.COMP Phase CompletionD.CO.BEG Begin Phase CompletionD.CR.080 Secure Client Phase Acceptance Client Phase AcceptanceD.RM.080 Release Staff Released StaffD.RM.090 Release Physical Resources Released Physical ResD.QM.050 Perform Quality Assessment Quality ReportD.CM.060 Audit Key Deliverables Audited Phase BaselineD.CO.END End Phase Completion

E TRANSITIONE.PL.PLAN Phase Planning

E.PL.BEG Begin Phase PlanningE.PL.SUM Review and Revise Project PlansE.PL.END End Phase PlanningE.EX.BEG Begin Transition Execution

E.CV Data ConversionE.CV.130 Install Conversion Software Installed Conv SoftwareE.CV.140 Convert and Verify Data Converted & Verified Data

E.TE Business System TestingE.TE.140 Support Acceptance Test Acceptance Results

E.TR TrainingE.TR.080 Prepare User Training Environment User Training EnvironE.TR.090 Train Users Trained Users

E.PM Production MigrationE.PM.040 Prepare Production Environment Production EnvironmentE.PM.050 Setup Applications Configured ApplicationsE.PM.060 Implement Support Infrastructure Doc Support ProcsE.PM.070 Verify Production Readiness Prod-Ready SystemE.PM.080 Commence Production Production SystemE.EX.END End Transition Execution

E.CT.CTR Phase Control



E.CT.BEG Begin Phase ControlE.CT.SUM Phase ControlE.CT.RES Unallocated ReserveE.CT.END End Phase Control

E.CO.COMP Phase CompletionE.CO.BEG Begin Phase CompletionE.CR.080 Secure Client Phase Acceptance Client Phase AcceptanceE.RM.080 Release Staff Released StaffE.RM.090 Release Physical Resources Released Physical ResE.QM.050 Perform Quality Assessment Quality ReportE.CM.060 Audit Key Deliverables Audited Phase BaselineE.CO.END End Phase Completion

F. PRODUCTIONF.PL.PLAN Phase Planning

F.PL.BEG Begin Phase PlanningF.PL.SUM Review and Revise Project PlansF.PL.END End Phase PlanningF.EX.BEG Begin Production Execution

F.PM Production MigrationF.PM.090 Audit Production System Post-Implement Prod SysF.PM.100 Measure System Performance System Perf AssessmentF.PM.110 Maintain System Maintained Prod EnvironF.PM.120 Refine Production System Refined Prod EnvironF.PM.130 Decommission Former System Decomm Former SysF.PM.140 Propose Future Business Direction Bus Direction RecomF.PM.150 Propose Future Technical Direction Tech Direction RecomF.EX.END End Production Execution

F.CT.CTR Phase ControlF.CT.BEG Begin Phase ControlF.CT.SUM Phase ControlF.CT.RES Unallocated ReserveF.CT.END End Phase Control

F.CO.COMP Phase CompletionF.CO.BEG Begin Phase CompletionF.CR.080 Secure Client Phase Acceptance Client Phase AcceptanceF.RM.080 Release Staff Released StaffF.RM.090 Release Physical Resources Released Physical ResF.QM.050 Perform Quality Assessment Quality ReportF.CM.060 Audit Key Deliverables Audited Phase BaselineF.CO.END End Phase Completion

Oracle Method AIM Roles B - 1

A P P E N D I X

B AIM Roles

his appendix gives a brief description of each role and highlights itsmain responsibilities.T

B - 2 AIM Roles AIM Method Handbook

Role Descriptions

Application Administrator

The application administrator is responsible for code table maintenanceand production control. This person ensures the data content of theshared 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 additionalresponsibility.

The application administrator may also be responsible for administeringthe data that determines which data and functions users or groups ofusers may access.

Application Architect

The application architect establishes the application architecture of anewly implemented system. To accomplish this, the applicationarchitect translates the future vision of the business into an applicationand data deployment strategy. This strategy includes decisions aboutcentralizing or decentralizing business data and processing,identification of interface points and specific requirements for datatransfer and synchronization across the business, critical setup ofapplications to support the business process mapping, strategies tosupport the reporting needs of the business, and other less generalrequirements that may impact the architecture (such as multilingualrequirements). To ensure compatibility with the overall applicationsarchitecture, the application architect provides input to more detailedtechnical design efforts such as interfaces and custom components,

The application architect works closely with the technical architect toensure the physical layers of the architecture are consistent with andfully support, the business and information systems vision for thecorporation. This synergism may extend all the way from scoping andplanning the project through to the final architecture deliverables andclient review.

Application Expert

The application expert provides knowledge and guidance regardingapplication functionality. This person also supports and providesinterpretation for tools, templates, and methods.


Business Analyst

The business analyst conducts interviews and working sessions. Thisperson also identifies detailed business requirements and createsbusiness requirement scenarios.

Business Line Manager

The business line manager participates in interviews and workingsessions by providing information about business objectives and waysin which the units operate and respond to events to achieve thoseobjectives. Also, this person describes problems the business unit facesand requirements for the computer system. The business line managerhosts site visits by staff to collect the information. The business linemanager should review the content of the analysis documentation toensure it accurately describes the business and requirements.Additionally, this person is responsible for allocating staff time toprovide detailed information about the day-to-day business.

The role of the business line manager should be filled by a person whowill manage one of the business units that will use the system.

Client Project Manager

The client project manager is responsible for the day-to-daymanagement of the client’s contractual commitments to the project.This person must understand the client’s business objectives for theproject so that these can form the basis for resolving problems, conflictsof interest, and making compromises.

The client project manager obtains physical resources such asaccommodation space, office equipment, computer equipment, andmaterials. Additionally, this person ensures the client allocates time tothe project. The client project manager introduces the consulting staff tothe other client staff. This person is responsible for monitoring theproject’s performance, progress against milestones, appropriateness ofwork, quality of work, and seeks to resolve any problems with work orrelationships between development and business staff. The clientproject manager usually performs intermediate and phase-end signoffs.

The client project manager ensures availability of users, reviewscontents of models, and ensures user commitment, review, and signoffof deliverables.


Configuration Manager

The configuration manager plans, establishes, and controls the PJMConfiguration Management process on the project, with the followingresponsibilities:

• develops, documents, and implements PJM ConfigurationManagement plans and procedures

• establishes project baselines and determines the content of projectreleases

• ensures that no unauthorized changes are made to a projectbaseline

• enforces Configuration Management procedures across all projectprocesses

• establishes and ensures that the PJM Configuration ManagementRepository is adequately maintained and protected againstdamage or loss

Database Administrator

The database administrator is required on large projects when there area number of teams of analysts or designers working on differentbusiness areas or subsystems. During analysis, the databaseadministrator ensures data shared by business areas is modeled by acommon data structure that satisfies the functional requirements ofthose areas. During design of the system architecture, the databaseadministrator performs a similar function for the system data model.The database administrator can also identify common areas offunctionality.

This person should quickly understand the functional and datarequirements of the various areas, have strong analytical skills, andhave the ability to resolve conflicting requirements.

Database Designer

The database designer is responsible for producing the logical andphysical database designs. This person reviews the module designs toensure efficient access to the database.

The database designer must have a thorough understanding of thesystem data model. Additionally, an understanding of the technicalarchitecture and functionality of the system is required so that


compromises in the design can be made when different functions placeconflicting requirements on the database.

Facilitator

The facilitator runs mapping and process design sessions and keepsmomentum going.

IS Manager

The IS manager directs the client information systems organizationwithin a business. The IS manager acts as a business line manager forthe staff in the IS organization. This person is responsible for thetechnical infrastructure of a business, including decisions aboutpurchases, in-house development, and operational maintenance andsupport. The following information systems staff report directly orindirectly 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 acorporation 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 existingcomputer systems and new systems. The IS operations staff providesinformation on operational requirements. This person acts as aconsumer of the training program.

IS Support Staff

The IS support staff is responsible for technical support of the client’ssystems. This person provides information about any IS standards withwhich the project must comply, supports the business’ softwaresystems, and takes over support of the system during production. The


IS support staff participates in any training program for the systeminitially as consumers and later, possibly as providers. Finally, the ISsupport staff provides information about existing systems the newsystem will interface with or replace.

Lead Tester

The lead tester oversees the test script planning, development, andexecution activities. The lead tester reviews and approves the testscripts. This person manages the test execution, monitors the progressof testing activities, and ensures that the test results and problems arelogged. The lead tester also helps prioritize problem log entries.

Module Designer

The module designer is responsible for production of application andmodule designs. This person communicates closely with the databasedesigner to ensure the database design meets the data requirements ofthe module functionality and module access data efficiently. Themodule designer also produces module and link test plans. During thevarious testing activities and the production phase, this persondiagnoses faults and determines corrections.

The module designer must understand requirements from the businessanalysis and how to meet these requirements using the technical andsystem architectures and system data model.

Network Administrator

The Network Administrator is responsible for administering thenetwork. This includes ensuring that the network is correctlyconfigured, configuring and maintaining the network environment, andperformance monitoring the network.

Production Database Administrator

The production database administrator installs and configures theproduction database and maintains database access controls. Thisperson provides consultation on performance, is responsible formonitoring growth and fragmentation of the production database, andensures database backup and recovery.


Programmer

The programmer produces working code that meets the modulespecifications. The programmer diagnoses and corrects faults found bytests. During production the programmer executes regression tests onthe corrections.

The programmer must have a thorough understanding of thespecifications for the modules to produce code. This person should alsounderstand how those modules fit in the system architecture andbusiness and technical requirements that they implement.

Project Database Administrator

The project administrator supports the project manager and projectcoordinator by performing routine or repetitive tasks. The projectadministrator prepares or maintains reports, records, logs and otherwritten communications, collects progress data from project leaders,and distributes project calendars, meeting agendas, and meetingminutes. 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 subcontractororganizations

• prepares project progress reports

• records and distributes minutes, decisions, and actions frommanagement 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 alsoperforms deliverable and template version management, gathers andchecks out deliverables, assigns document names and records newdocuments into the library. This person also provides deliverable statusand advice regarding process integration.


Project Manager

The project manager is ultimately responsible for the success or failureof the project. This person must understand the project businessobjectives of both the client and consultant, and have a clear vision ofhow to achieve those objectives. The project manager agrees on thescope of the project with the client and resolves any conflicts among thevarious objectives of its stakeholders.

The project manager is responsible for the project planning, resourcing,monitoring, and reporting the progress against the plan. This personobtains any physical resources required for the project, recruits staff,and, if necessary, dismisses staff. The project manager is responsible forensuring that activities are performed in accordance with the QualityPlan.

Internal responsibilities of the project manager role should be delegatedto subordinate team leaders, as documented in the project organizationplan.

Project Sponsor

The project sponsor controls the budget and finances the project. Thisperson is usually a member of senior management. On large, cross-functional projects the project sponsor may be a board member. Thisperson must have a clear understanding of the project objectives,particularly concerning delivery of the business benefits. The projectsponsor is the ultimate arbiter on conflicting business requirements andscope changes. The project sponsor ensures the project is delivered ontime and within budget.

The project sponsor is responsible for ensuring other members of themanagement share commitment to the project. This person mayprovide the resources, particularly staff time, required to make theproject a success. The project sponsor usually performs the final sign-off.

Quality Auditor

The quality auditor conducts quality audits of the project. This positionshould be filled by a person independent of the project staff in theconsulting organization. The quality auditor needs training in the auditprocess. The quality auditor prepares for, conducts, reports on, andfollows up on any actions raised by the quality audit(s).


System Administrator

The system administrator is responsible for administering thedevelopment system. This person’s responsibilities include ensuringhardware is correctly configured; installing, configuring, andmaintaining operating and development software; and ensuring thatdaily backups of the system are performed. The system administratoralso designs and maintains the system’s security (for example,establishing system accounts).

The system administrator provides first-line support for problems withthe development system and ensures faults are quickly rectified. Thisperson may perform the set up and initial maintenance of theproduction system or advise the client’s operational staff on these tasks.The system administrator works with the project team to optimizesystem performance.

The system administrator installs packaged applications environmentsand converts data.

Team Leader

The team leader plans, directs, and monitors the day-to-day work of theteam. This person assigns work packages to the team members andensures that they understand the requirements. The team leader isresponsible for building team cohesion, motivating the teams, andproviding assistance and encouragement to the team members.

Each team leader performs the final quality control and qualityassurance for the team by reviewing all deliverables. This person alsosigns off team work completion and quality. Work that is not up toquality standards is returned. Team leaders review deliverables fromother 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 projectmanager may be performed by the same individual.

Technical Analyst

The technical analyst proposes solutions and technical assumptions anddevelops data profiles in support of testing.


Technical Architect

The technical architect is responsible for architecting the physicalcomponents of the database, hardware, and network in support of theapplication architecture. To accomplish this, the technical architectneeds to design the detailed database, hardware, and networkarchitecture to support the application architecture and deploymentstrategy. This includes decisions about the physical distribution ofprocessing across client and server machines, capacity planning of thetechnical infrastructure, detailed design of the layout of databases, andidentification and advisement of performance risks. The technicalarchitect oversees detailed technical work on interface and systemdesign to ensure the detailed work is consistent with the overalltechnical architecture.

The technical architect works closely with the application architect toachieve an integrated overall architecture supporting the business andinformation systems vision.

Technical Expert

The technical expert is a generic role covering the provision of highexpertise in the use and application of the various technologies used toconstruct the system where these are not specifically covered by otherroles (such as database designer). On the project there will be a role foreach technology; for example, C++ programming, Oracle Forms, andSQL Connect. There may also be experts needed in the areas of userinterface, standards, data conversion, and performance measurement.

The technical expert provides for the provision of standards for use ofthe technology (for example, C programming and GUI standards)provision of consultancy on the technology to other team members, andparticipation in reviews of the use of the technology.

Technical Writer

The technical writer becomes familiar with the business and technicalrequirements of the system and how the architecture, design, andmodules achieve those objectives. The technical writer specifies andproduces the user, technical, and operational documentation.

Tester

The testers develop and execute test script. Testers ensure test scriptsare reviewed by the appropriate business analysts prior to test


execution. This person records test results during testing activities anddocuments test faults in the problem log. Testers update test scripts toreflect approved change requests or software faults that were notanticipated in the original development. When problems are resolvedafter retesting, testers update the problem log.

Trainer

The trainer is responsible for defining the training requirements,preparing a training plan, producing training material, and deliveringcourses.

User

The user is a member of the client’s staff who actually uses theproduction system. The user’s responsibility is to be a consumer of thetraining program and report problems with the production system.

Oracle Method Role Usages C - 1

A P P E N D I X

C Role Usages

his appendix provides a general alphabetical index of the roles usedin AIM. The following table lists each role and the AIM task(s) that

requires its participation.T

C - 2 Role Usages AIM Method Handbook

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

Environment20

C.CV.040 Prepare Conversion Environment 20 D.MD.090 Prepare Development Environment 15 D.PT.120 Prepare Performance Test

Environment20

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,and Approach

10

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

Architecture60

C.TA.140 Design Logical Application andDatabase Architecture

40

C.TA.180 Assess Performance Risks 25 C.TA.190 Design System Management

Procedures10

C.TE.050 Develop Systems Integration TestScripts

20

Application Expert B.BR.020 Map Business Requirements 25 B.BR.030 Map Business Data 30 B.BR.070 Conduct Reporting Fit Analysis 20



B.BR.080 Test Business Solutions 30 B.BR.090 Confirm Integrated Business Solutions 25 B.RD.070 Create Business Requirements

Scenarios30

C.TA.120 Design Application SecurityArchitecture

60

Business Analyst A.DO.010 Prepare Glossary 95 A.DO.020 Specify Documentation Requirements 85 A.RD.010 Identify Financial and Operating

Structure100

A.RD.020 Conduct Current Business Baseline 90 A.RD.030 Develop Future Process Model 90 A.RD.040 Develop Future Business Function

Model100

A.RD.050 Establish Process and MappingSummary

100

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

Baseline20

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

Extensions10

B.PT.030 Identify Performance Test Scenarios 35 B.PT.040 Identify Performance Test Transaction

Models10

B.RD.070 Create Business RequirementsScenarios

50

B.RD.080 Determine Audit and ControlRequirements

100

B.RD.090 Identify Business AvailabilityRequirements

95

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



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

Architecture30

C.TA.130 Design Application FunctionalArchitecture

40

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

Programs5

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 OperatingStructure

*

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 *



B.BR.090 Confirm Integrated Business Solutions * B.BR.100 Create Process Narratives * B.MD.020 Define and Estimate Custom

Extensions*


*


*

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



B.BR.070 Conduct Reporting Fit Analysis 10 B.RD.070 Create Business Requirements

Scenarios10

Database Administrator B.TA.060 Develop System Availability Strategy 10 C.TA.140 Design Logical Application and

Database Architecture10

C.TA.150 Design Physical Database Architecture 80 C.TA.160 Design Hardware and Network

Architecture10

C.TA.170 Develop System Capacity Plan 20 C.TA.190 Design System Management

Procedures20

D.PT.120 Prepare Performance TestEnvironment

10

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


D.MD.100 Implement Database Extensions 20Facilitator 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

Scenarios5

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 *



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 andContingency Plan

*

C.TA.160 Design Hardware and NetworkArchitecture

*

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.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 *



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 ofApplication 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

Scripts20

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 CustomExtensions

70

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

Manual20

C.MD.050 Design Database Extensions 40 C.MD.060 Produce Module Functional Design 80 C.MD.070 Produce Module Technical Design 90



C.MD.080 Review Detailed Designs 30 C.PT.060 Design Performance Test Transaction

Programs60

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,Objectives, and Approach

5

B.TA.060 Develop System Availability Strategy 10 C.TA.160 Design Hardware and Network

Architecture10


Procedures20

D.PT.120 Prepare Performance TestEnvironment

10

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 DatabaseAdministrator

E.CV.140 Convert and Verify Data 20

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



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

Programs85

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,Objectives, and Approach

5

B.BR.010 Prepare Mapping Environment 30 B.TR.020 Prepare Project Team Training

Environment25

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,and Approach

10

A.DO.020 Specify Documentation Requirements 5 A.PT.010 Define Performance Testing Scope,

Objectives, and Approach30

A.PT.020 Prepare Performance Testing 15 A.TA.010 Define Architecture Scope, Objectives,

and Approach30

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




75

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 45System Administrator A.PT.010 Define Performance Testing Scope,

Objectives, and Approach5

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

Environment35

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

Guide20

C.TA.160 Design Hardware and NetworkArchitecture

35


Procedures40

D.DO.130 Complete System Management Guide 15 D.MD.090 Prepare Development Environment 35 D.PT.120 Prepare Performance Test

Environment40

D.PT.130 Execute Performance Test 30 D.PT.140 Create Performance Test Report 10



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 15Team Leader-Architecture A.TA.010 Define Architecture Scope, Objectives,

and Approach50

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-BusinessRequirements

B.RD.070 Create Business RequirementsScenarios

5

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

(Map Conversion Data)10

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

Contingency Plan10

D.CV.110 Perform Conversion Business ObjectTest

10

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

and Procedures30

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-PerformanceTesting

A.PT.010 Define Performance Testing Scope,Objectives, and Approach

55

A.PT.020 Prepare Performance Testing Strategy 70 B.PT.030 Identify Performance Test Scenarios 65 B.PT.040 Identify Performance Test Transaction

Models65

C.PT.050 Create Performance Test Scripts 10 C.PT.060 Design Performance Test Transaction

Programs20

C.PT.080 Design Performance Test Data 20 C.PT.090 Design Test Database Load Programs 10 D.PT.070 Develop Performance Test Transaction

Programs10

D.PT.100 Develop Test Database Load Programs 10 D.PT.110 Construct Performance Test Database 5 D.PT.120 Prepare Performance Test

Environment5

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



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

Application Features5

B.TR.020 Prepare Project Team TrainingEnvironment

10

B.TR.050 Prepare Project Team Training 5 B.TR.060 Train Project Team 6 C.PM.030 Develop Detailed Transition and

Contingency Plan15

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,and Approach

90

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

Models25


5

C.CV.050 Perform Conversion Data Mapping(Map Conversion Data)

90

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

Programs20

C.PT.080 Design Performance Test Data 50



C.PT.090 Design Test Database Load Programs 20 C.TA.120 Design Application Security

Architecture10

C.TA.140 Design Logical Application andDatabase Architecture

10

D.PT.110 Construct Performance Test Database 70 D.PT.120 Prepare Performance Test

Environment15

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,and Approach

10

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

Baseline80

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


C.TA.150 Design Physical Database Architecture 20 C.TA.160 Design Hardware and Network

Architecture45

C.TA.170 Develop System Capacity Plan 50 C.TA.180 Assess Performance Risks 50 C.TA.190 Design System Management

Procedures10

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

Extensions20



C.PM.020 Design Production SupportInfrastructure

100

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-ExistingSystems

A.DO.010 Prepare Glossary 5

Technical Writer A.DO.030 Determine Documentation Standardsand Procedures

70

B.DO.040 Prepare Documentation Environment 15 B.DO.050 Produce Documentation Prototypes

and Templates100

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

Manual80

C.DO.090 Produce Initial System ManagementGuide

80

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

Scripts60

D.CV.110 Perform Conversion Business ObjectTest

90

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

Application Features95



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.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 AIM 2.0 Data Model D - 1

A P P E N D I X

D AIM 2 Data Model

his appendix provides a general description of the AIM 2 DataModel.T

D - 2 AIM 2.0 Data Model AIM Method Handbook

Purpose and Objective of the Data Model

A sound method should be based on well-defined, related buildingblocks that can be used to develop and execute a project plan byutilizing resources, producing deliverables, and meeting businessobjectives. The AIM Data Model represents these building blocks andtheir relationships as Data Objects and Relationships.

The purpose of the Data Model is to help ensure quality, promote easeof use, and facilitate integration within Oracle methods like CDM orPJM. It provides a framework that ensures consistency among thevarious 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 depictedby the line connecting project and deployment.


Program

Deployment

ActivationBusiness Unit Site

Function

Person

RoleElementary BusinessFunction

Event

Affect

Activatedduring At

Go live during

Governedby

Organizerof

Activationof

Subjectof

Triggerd During

Domain of

Trainedduring

Attendedby

Aninstance

of

deliveredby

Process Step

Detail of

Described by

Trigger for

Response to

Requirement

RequirementsScenario

Mapping Scenario

An alternateapproach to

Supportedby

A uniqeresponsepath for

Executedvia

Associatedwith

Source of

Associatedwith

Source of

Application

ApplicationFunction

Supportedby

Capable of supporting

Within

Composed of

Procedure

Gap

Solution

Policy

Customization

Performed byfollowing

Instructions for

Module

Business Object Conversion

Part of

Composed of

Userof

Accessedby

Procedure Step

Performed using

Executed during

New steps tosupport

Impemented with

requiredto enable

Implementedwith

created toprovide

Implementedwith

Detailsof

Carriedout with

Source of

theresult of

AIM 2.0Data Model

Controledby

Initiator of

Within

Composed of

Performed during

Require

Assgnedto

Perform

Performed by

Performer of

Instance of

Executed by

Catalystfor Closure

of

High-level BusinessFunction

ConversionExecution

Execution of

Executed during

Associatedwith

Source of

Migration method for

Migrated via

Facilitatedby

Created tosupport

Part of

Composed of

Decomposed into

Sub-process

of

Sub-function of

Decomposedinto

Parentof

Child of

Revision 4 May 18, 1997

Project

Class SessionClass

Process

Figure D-1 AIM Data Model Diagram


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 andits relationships with other objects.

Relationship to AIM Processes, Tasks, and Deliverables

The data objects in the Data Model represent the information that isanalyzed, documented or is the subject of work on an AIM project.Processes and tasks operate on data objects that are then included indeliverables. In some cases there is no deliverable for a data object. Inother cases a data object may correspond to a section in an AIMdeliverable.

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 businessfunction at one site for one business unit. For example, a singledeployment will have many Activations in the process of going live,with multiple Business Units using multiple High-level BusinessFunctions at one or more sites. Each Activation represents a discreteunit of work that can be predicted and measured.

Relationships

There can be one or more Activation for a Deployment. One or moreBusiness Units may be associated with an Activation. You may go livewith Accounts Payable and Purchasing at a single site at the same time;however, an Activation is only associated with one Site.


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 andAccounts Payable are going live at a specific site at the same time youmay want to conduct training classes for the users. An Activation mayhave Classes; you may decide to train users from Site A at Site B, oryou may choose not to train users at specific sites.

Application

Definition

An Application is a collection of program modules that work togetherto support a set of related business functions. Order Entry, Inventory,Projects, Work In Process, General Ledger, and so on are OracleApplications.

Relationships

An Application may support one or more Business Functions. Forexample, General Ledger supports all of the Business Functions thatprovide journal entries. The Purchasing System may support theProject Accounting Business Function as well as the Purchasing andInventory Business Functions.

Application Function

Definition

An Application function is a portion of an Application that supports asubset 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 anApplication must have one or more Application Functions.


Business Function

Definition

A Business Function is what an enterprise does, or needs to do, toachieve its objectives. Manufacturing, purchasing, accounting,engineering, and sales are Functions.

There are two special kinds of Functions in AIM: High-level andElementary Business Functions. They are represented in the diagram asboxes inside of the box labeled Business Function.

A High-level Business Function is a Business Function that is at the topof the Business Hierarchy Diagram (an AIM deliverable). AnElementary Business Function is the lowest level in this diagram.

If Purchasing is a High-level Business Function, an Elementary BusinessFunction within Purchasing might be Approving Contracts. A typicalpart of a Business Function hierarchy would be Approving Contractsrolling up to a mid-level Business Functions Contract Management that inturn rolls up to Purchasing, the High-level Business Function.

Relationships

The dotted circle on the upper right hand corner of the BusinessFunction box indicates that one Business Function may relate to anotherin the hierarchical fashion described above.

At least one Event must relate to a High-level Business Function. Forexample, receiving an invoice is an Event that may be associated withthe 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, theteam will not be analyzing Events associated with some High- LevelBusiness Functions. However, to understand the organizationalcontext, such a High-level Business Function might still be included inthe Business Function Hierarchy diagram.

An Event may be related to only one High-level Business Function. It ispossible to design a Business Function Hierarchy poorly so that anEvent appears to be related to more than one High-level BusinessFunctions, however, this is a sign that the function hierarchy isambiguous and should be revised. Sales order might be related to theOrder Entry High-level Business Function.


A Business Function may relate or one or more Requirements. Thereare generally many Requirements for a Business Function. Examples ofRequirements associated with the Buyer Business Function are:

• ability to group like requisitions

• ability to automatically route requisitions to buyers by vendor oritem category

An Elementary Business Function may relate to one or more ProcessSteps but a Process Step must relate to at least one Elementary BusinessFunction.

Business Object

Definition

A Business Object is a physical or logical object of significance to abusiness (for example, a sales order, department, assembly, item,balance, or invoice). A Business Object is analogous to a class in objectoriented terminology.

Relationships

A Business Object may be related to one or more Conversions. FixedAssets are Business Objects that may need to be converted from a legacysystem to Oracle’s Fixed Asset System.

Business Objects must relate to at least one Business Function. If aBusiness Function for a Business Object to be converted does not appearto be identified there is a deficiency in your Business FunctionHierarchy diagram.

Business Unit

Definition

A business unit is part of an organization treated as a separate entitywithin the parent organization. Examples include a department ordistribution center.

Relationships

A Business Unit may be related to itself since there may be a hierarchyof Business Units. For example, A Procurement Department may becomprised of Purchasing, Inventory, and Contracts departments.


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. Purchasingand Accounts Payable may go live in several Business Units at the sametime. For example, a company may have regions with centralPurchasing and Accounts Payable Business Units in each region.

Class

Definition

A Class refers to the training of students on specific topics. Usuallytraining is provided for Oracle Applications such as Bill of Materials,Work In Process, and so on. Training may also be provided for jobpolicy and procedures, Help Desk operations, and so on.

Relationships

One or more Classes may be held for each Activation. If AccountsPayable is going live at a specific site on a specific date you may want tohold a class for that Activation. Depending on the number of students,you may need to have multiple classes. However, students from aparticular site may be trained elsewhere, therefore, you would notnecessarily have a Class for every Activation.

A Class must have at least one Class Session. If there are more studentsthan can be accommodated in one class you may need multiple ClassSessions.

Class Session

Definition

A Class Session consists of delivering a Class to a specific set of studentsat a particular place and time.

Relationships

There may be one or more Class Sessions for a Class. One or morepeople may attend a Class Session.


Conversion

Definition

Conversion includes the total set of activities converting BusinessObjects 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 datafrom the old system to the Oracle Fixed Assets system.

Relationships

A Conversion may be associated with one or more ConversionExecutions. For example, a project that has multiple deployments byregion may require a separate Fixed Assets data conversion for eachregion.

A Conversion must be associated with at least one Business Object. Forexample, an Inventory Conversion might at least migrate InventoryItems 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’sPurchasing System that is how Commitments are shown in OracleProjects. In this case you would also be converting Open PurchaseOrders to get them into Oracle Purchasing; therefore, the BusinessObject Open Purchase Orders is actually part of both the Oracle Projectsand Purchasing Conversions.

Conversion Execution

Definition

An example of a Conversion Execution would be the conversion of openorders from a legacy system to Oracle Order Entry in one region on agiven date. Other regions may go live with Order Entry on a differentdate requiring other order entry Conversion Executions.

Relationships

There must be at least one Conversion Execution associated with aConversion. A Conversion Execution must always be associated withonly one Conversion.


In a project with a phased deployment by region, the Accounts PayableConversion of open invoices may need to occur once for each region.

Customization

Definition

A customization is a change made to the standard Oracle software thatimplements a Solution to a Gap.

Relationships

A Customization must be related to only one Solution. A Solution mayrelate to one or more Customizations.

Deployment

Definition

A deployment is the total set of activities associated with the productionimplementation of a set of applications in specific location(s) at aspecific time.

For example, going live with Oracle’s General Ledger, Purchasing, andAccounts 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 Deploymentmay contain one or more Activations.

Gap

Definition

A Gap is a relationship between a Requirement and an ApplicationFunction where the standard Application Function will not meet theRequirement.

Relationships

A Gap must be related to one or more Requirements and one or moreApplication Functions; it may relate to only one Solution. A Solutionmust relate to one or more Gaps, therefore, the inability to drill downfrom General Ledger to Accounts Receivable may have been identifiedas a Gap for that a Solution was developed.


Mapping Scenario

Definition

A Mapping Scenario is a detailed step by step description of how youwant team members to test the standard Oracle software to see if it willmeet the needs of a Business Requirements Scenario.

Relationships

A Mapping Scenario must be related to only one Business RequirementsScenario. A Business Requirements Scenario may be related to one ormore 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 customsoftware to convert Business Objects from legacy systems to the newOracle systems.

Policy

Definition

A policy is a documented directive from enterprise management thatspecifies how some aspect of the business is to be conducted.

For example, a policy might be that any expenditure over fifty dollarsmust be transacted using a Purchase Requisition instead of petty cash.

Relationships

A Policy may be related to only one Solution. One or more Policiescould be related to a Solution.


A solution to a Gap may be to disallow separate costs for the same itemin different warehouses. This would be documented in a policyrequiring 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 abusiness function.

An example would be a Procedure for uploading journal entry data inspreadsheet form to Oracle General Ledger.

Relationships

A Procedure may relate to only one Solution. It must relate to at leastone Procedure Step.

Process

Definition

A Process is a grouping of tasks based on common functions ordisciplines that lead to one or more key deliverables. Examples ofProcesses 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 ofprocesses in an enterprise. For example, you might define a processcalled Replenish Inventory. This could be comprised of lower levelprocesses such as Analyze Stock Shortages, Create Requisitions, and so on.

Processes must be related to at least one Event. Several Events could berelated to one Process. The Invoice Entry Process is related to the Receiptof an Invoice Event.

A process must have at least one Process Step. The Invoice ProcessingProcess might include steps such as:

• date and time stamp invoice

• sort invoices by type


• 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 theprocess that you want to ensure the application can handle. For invoiceprocessing you may have the following Business RequirementsScenarios:

• 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 representactions required to complete a Process.

Relationships

A Process Step must be associated with only one Process. A ProcessStep must also be associated with an Elementary Business Function. AProcess Step must be associated with only one Procedure.

The Enter Invoice Process Step may be part of the Invoice ProcessingProcess. It must relate to an Elementary Business Function (that mightbe Process Invoices). There may be a user Procedure describing how toenter an invoice.

Program

Definition

A Program is an interrelated group of projects either run concurrentlyor sequentially, that share a system goal. Individual projects may havedifferent goals; however, the combined set of projects will have aprogram goal.


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 withpredetermined budget and business objectives.

Relationships

A project may be part of a Program that always has at least twoprojects. A project will always have at least one Deployment.

Requirement

Definition

A Requirement is a specific, detailed business need compared withApplication functionality to determine if the need can be met withstandard 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 differentwarehouses

• ability to drill down from General Ledger account balances tosubledger detail (such as Accounts Payable, Accounts Receivable,or Fixed Assets)

• ability to automatically track Engineering Change Orders

• ability to automatically assign new Asset categories andassociated account codes to fixed asset records being convertedfrom legacy systems

A Requirement must only be associated with one of the three objectsmentioned above. This AIM requirement facilitates cross referencingand maintaining an audit trail.


A Requirement may be associated with only one Gap; however, a Gapmay be associated with one or more Requirements. For example, thevanilla software may meet the drill down requirement from the GeneralLedger to detailed Account Payable records, but it does not address allthe needs for drill down to Accounts Receivable detail. This would bedocumented in AIM as a Gap related to this requirement.

Business Requirements Scenario

Definition

A Business Requirements Scenario is a formal statement of detailedbusiness requirements for a Process, the source of the Requirements,how these requirements will be satisfied (either the application, manualProcedure, Workarounds, or other application solutions), and whatprototyping 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 RequirementsScenarios.

A Business Requirements Scenario must be associated with one or moreMapping Scenarios.

For example, Invoice Processing is an Accounts Payable Process. Arelated Business Requirements Scenario would describe in narrativeform how the enterprise wishes to process invoices.

If the invoice processing Process has different possible paths because ofdecision points, there may be multiple Business RequirementsScenarios. One Business Requirements Scenario might deal with oneline invoices where there is no need to prorate tax lines to other invoicelines. Another scenario would address the more complex case.

When you want to test the application to see if the standard softwarewill handle a given Business Requirements Scenario, you will developone or more Business Mapping Scenarios.

Why might you have more than one Business Mapping Scenario? Theremight be different ways to use an Oracle Application to meet a givenBusiness Requirements Scenario. For example, assume that you can setup Oracle Accounts Payable to handle automatic proration of tax linesto other invoice lines in different ways; in this case you might want totry it for each different setup option. You would create Business


Mapping Scenarios to document how team members should test thesystem.

Role

Definition

A role is a generic set of activities that may be assigned to people (forexample, 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 beassigned a role.

Site

Definition

A site is a uniquely identifiable geographic location or place from thatone or more business organizations may be wholly or partly operating.

Relationships

A Site may be associated with one or more Activations. Someapplications may go live in a Site on one date, and other applicationsmay go live later at the same Site. An Activation is associated with onlyone Site.

Solution

Definition

A Solution is the resolution of the discrepancy between one or moreGaps 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 thatenhances the standard Application Function by changing or addingsoftware to the base Oracle Application. With the example ofinsufficient drill down capability from the General Ledger to detailedAccounts Receivable records, fields that resolve the Gap could be addedto a General Ledger form.


Relationships

A Solution must be related to one or more Gaps. It may relate to one ormore Procedures, Policies, or Customizations.

For example, assume that a Gap is an automated tax proration feature inOracle Accounts Payable that does not work exactly the way anenterprise wants. One Solution might be to establish a policy that taxproration will be done manually. An associated Procedure might bedeveloped indicating how to do the manual proration. A differentSolution would be to customize the Accounts Payable System byaltering the way it handles tax proration.

Oracle Method Glossary G - 1

Glossary

24x7 A period or window of serviceavailability that covers 24 hours day,seven days a week.

3GL see THIRD-GENERATION PROGRAMMING

LANGUAGE

4GL see FOURTH-GENERATION

PROGRAMMING LANGUAGE

A

ABT see APPLIED BUSINESS TECHNOLOGY.

Acceptance The approval, typically by aclient or user, of a project deliverable.

Access Control The ability to managewhich users or groups of users mayhave the privilege to retrieve, create,update, or delete data held in arepository, such as a relationaldatabase.

Activation A logical event correspondingto the enabling of one high levelbusiness function at one site for onebusiness unit. Each activationrepresents a discrete unit of work thatwe can predict and measure.

Actuals Information gathered during aproject concerning the actual amount oftime, finances or resources expendedon a task.

Advocate An individual who supports theproject within the client environment,without being involved in the project’simplementation. An advocate may be aformal or informal leader within theorganization.

G - 2 Glossary AIM Method Handbook

Agent A generic term for a party which isresponsible for the execution andcompletion of a process step. An agentmay be an organizational unit, afunctional unit, a business system, anemployee role, an external system, oran external party such as a customer orsupplier.

Agent Channel A horizontal division on aprocess flow diagram that indicateswhich agent performs which particularfunctions within the process beingmodeled.

AIM see APPLICATION IMPLEMENTATION

METHOD.

Application A collection of programmodules that work together to supporta set of related business functions; seealso MODULE.

(Oracle) Application Environment Acomplete application installation alongwith other utilities used for businessmapping, design, build, testing, ortraining. Usually, an applicationenvironment includes setups and testdata to support business modeling, andprocedures exist to recover tocontrolled starting points after sessionsare complete.

Application Fit A recorded matchbetween some aspect of a businessrequirement and the capability orfeatures of the application system thatsatisfies the requirement.

Application Function A portion of anApplication which supports a subset ofthe business functions supported by theoverall Application.

(Oracle) Application FunctionalConfiguration The definition of keyarchitectural setup parameters in anapplication instance or product groupto reflect the financial and operatingenvironment of the businessorganizations that transact within thatapplication instance or product group.

Application Gap A recorded variancebetween some aspect of a businessrequirement and the capability orfeatures of the application system thatare necessary to satisfy therequirement.

Application Implementation Method(AIM) A method that comprises aflexible approach for implementingOracle Applications.

Application Instance A unique set ofapplication tables and processes. Notethat two instances of the same versionof an application may share one set ofprogram modules but they may notshare the same set of application tables.

Application Interface A mechanism usedto transfer data between applications.A data flow between applications isalways implemented as a set of one ormore application interfaces; see alsoNEAR REAL-TIME INTERFACE and REAL-TIME INTERFACE.

Application Process An indication of thesequential execution of a series ofsystem functions, possibly includingmanual functions as well; see alsoMANUAL FUNCTION, SYSTEM FUNCTION,and SYSTEM PROCESS.


Application System An automatedcollection of business functions,entities, modules, technologyplatforms, and documentation thatperforms a specified set of businessfunctions; see also BUSINESS SYSTEM,MODULE, PLANNED RESPONSE SYSTEM,and SYSTEM FUNCTION.

(Oracle) Applications DistributedInterface An interface between similaror dissimilar Oracle Applicationsproducts that have data stored inmultiple separate databases. Thedatabases may or may not be residentat multiple sites (data centers). Thecorollary of this is that Applicationsdistributed interfaces may exist at asingle site.

(Oracle) Applications Interface Aninterface between similar or dissimilarOracle Applications products that havedata stored in the same database. Theinterface may or may not be supportedwithin the standard package products.

Applied Business Technology (ABT) Acompany that manufactures tools toprofile, estimate, and plan projects.Oracle Services has a global licensingagreement with ABT. Oracle Methodmakes use of Project Workbench,Methods Architect, and Project BridgeModeler as its worldwide methods andproject management software standard;see also PROJECT BRIDGE MODELER andPROJECT WORKBENCH.

Approach A particular way of putting amethod or task to use, including riskfactors, tips from experience,recommendations, and additionaladvice; see also TECHNIQUE.

Arm’s Length Transaction An inter-company transaction that is treated as athird party transaction.

Attribute Any detail that serves toqualify, identify, classify, quantify, orexpress the state of an entity; anydescription of a thing of significance.

AutoText Entry Microsoft Word allowsyou to store frequently used text,graphics, and other items and quicklyinsert them into documents. Thesestored items are referred to asAutoText entries. If you store text andgraphics as AutoText entries, you canretrieve them by clicking a button,typing a few keystrokes, or choosing acommand. Components of theDeliverable Templates are stored asAutoText entries in global templatesused to store boilerplate text; see alsoBOILERPLATE TEXT.

B

Backup and Recovery Strategy A storageand recovery strategy that protectsagainst business information lossresulting from hardware, software, ornetwork faults.

Baseline 1. A starting point or conditionagainst which future changes aremeasured. 2. A named set of objectversions which fixes a configuration ata particular point in time. A baselinenormally represents a milestone or keydeliverable of a project; see alsoCURRENT BUSINESS BASELINE.


Bid and Proposal Management (BPM)Specifies the process, tasks,responsibilities, and deliverablesregarding how business opportunitiesare qualified and responded to,eventually leading to the issue of anauthorized bid to a client.

Billable Project Expenses The projectexpenses that are billable to a client; seealso PROJECT EXPENSES.

Billable Utilization The utilization that isbillable to a client; see also UTILIZATION.

Black Box Test A test of all or part of anapplication system based uponfulfilling business requirements ormeeting functional specifications. Ablack box test does not require anunderstanding of the actual code undertest. A system test is usually a blackbox test.

Boilerplate Text Pre-written collection ofwords, sentences, headings, andformatting in a template that you canmodify to suit a specific need; see alsoAUTOTEXT ENTRY.

Bottom-up Estimate A task-level estimatederived by calculating the estimatingfactors critical to completion of eachtask; see also ESTIMATING FACTOR.

BPM see BID AND PROPOSAL

MANAGEMENT.

BPR see BUSINESS PROCESS REENGINEERING.

Budget A plan for determining, inadvance, the expenditure of time,money, etc.

Business An enterprise, commercialentity, or firm in either the private orpublic sector, concerned withproviding products or services tosatisfy customer requirements.

Business Aim A statement of businessintent measured subjectively; forexample, to move up market, or todevelop a sustainable level of growth;usually strategic or tactical with a 3-5year horizon.

Business Area The set of businessprocesses within the scope of a project.

Business Constraint Any external,management, or other factor thatrestricts a business or systemdevelopment in terms of resourceavailability, dependencies, timescales,or some other factor.

Business Data Mapping Verification thatthe underlying table structures andattributes will support businessprocesses.

Business Function Something anenterprise does, or needs to do, inorder to achieve its objectives; see alsoAPPLICATION SYSTEM, BUSINESS PROCESS,MANUAL FUNCTION, and SYSTEM

FUNCTION.

Business Function Model Arepresentation of all the businessfunctions within a defined scope. Awide range of techniques is availablefor modeling business functions.; seealso FUNCTION DECOMPOSITION andFUNCTION HIERARCHY.

Business Goal A statement of businessintent.


Business Location A uniquely identifiablegeographic location, site, or place fromwhich one or more business units maywholly or partly operate.

Business Model A model or collection ofmodels representing the definition ofkey components of a business.Components may include models ofprocesses, objectives, functions, andinformation; see also BUSINESS PROCESS

MODEL, ENTITY RELATIONSHIP DIAGRAM,and FUNCTION HIERARCHY.

Business Object A physical or logicalobject of significance to a business; forexample, a sales order, department,assembly, item, balance, or invoice. Abusiness object is analogous to a classin object-oriented terminology.

Business Objective Business conditionswhich, if met, will solve the businessproblem statement. Well-definedobjectives are measurable and oftenrelate directly to business processesand deliverables; see PROBLEMSTATEMENT.

Business Organization Any part of abusiness treated for any purpose as aseparate unit within the parentbusiness organization; for example, adepartment, division, or subsidiary; seealso BUSINESS UNIT.

Business Organization Type Aclassification of a business organizationinto one of several functionalcategories. Each business organizationtype has a distinct set of businessrequirements. All the businessorganizations of a certain type willtypically require similar applicationsand system capabilities. A given sitemay house one or more businessorganization types. Since businessorganizations may be related in ahierarchy, a high level businessorganization may be composed ofseveral business organizations ofdifferent types. For the purposes ofapplication architecture analysis anddesign, it is generally useful todecompose the hierarchy of businessorganizations until it is composed ofatomic organization types; see alsoCUSTOMER SERVICE, DISTRIBUTION,FINANCE, HUMAN RESOURCES,INFORMATION SYSTEMS,MANUFACTURING, MARKETING,PLANNING, RESEARCH AND

DEVELOPMENT, and SALES.

Business Priority A statement of the levelor urgency of important businessneeds.


Business Process The complete responsethat a business makes to an event. Abusiness process entails the executionof a sequence of one or more processsteps. It has a clearly defineddeliverable or outcome. A BusinessProcess is defined by the business eventthat triggers the process, the inputs andoutputs, all the operational stepsrequired to produce the output, thesequential relationship between theprocess steps, the business decisionsthat are part of the event response, andthe flow of material and/orinformation between process steps; seealso BUSINESS FUNCTION, BUSINESS

PROCESS MODEL, and EVENT RESPONSE.

Business Process Model The collection ofprocess flow diagrams that comprisethe complete set of business processeswithin the application scope; see alsoPROCESS FLOW DIAGRAM.

Business Process Reengineering (BPR)The activity by which an enterprisereexamines its goals and how itachieves them, followed by adisciplined approach of businessprocess redesign. A method thatsupports this activity.

Business Requirement A formalstatement that describes applicationfeatures necessary to support abusiness process step.

Business Requirements Mapping Anactivity that describes the businessrequirements for a business process inbusiness language, optionally comparesthe current solution for a businessrequirement to a proposed solution andspecifies details for the type and natureof the solution in a descriptive format.The deliverable can also be used as arecord of key decisions, or as aplaceholder in anticipation ofadditional detailed designdocumentation.

Business Requirements Scenario Aformal statement of the detailedbusiness requirements for a businessprocess, the source of theserequirements, how these requirementswill be satisfied (either by theapplication, manual process steps,workarounds or other applicationsolutions), and what prototyping stepsmust be taken to prove the designs.Known as a BRS.

Business Rule A rule under which anorganization operates. A policy ordecision that influences the processstep

Business Solution Testing A techniqueby which management agrees thatbusiness requirements will be satisfiedif the application and other toolsperform as specified by processdesigns.

Business System A combination ofpeople and automated applicationsorganized to meet a particular set ofbusiness objectives; see alsoAPPLICATION SYSTEM and PLANNED

RESPONSE SYSTEM.


Business Unit Part of an organizationtreated for any purpose as a separateentity within the parent organization.Examples include a department ordistribution center; see also BUSINESS

ORGANIZATION.

Business View A frequently used subsetof information, readily intelligible tousers and defined in business terms,derived from definitions held in anentity model. It is based on one entityand can encompass renamed attributesfrom the base entity or any other entity.

C

CASE see COMPUTER-AIDED SYSTEMS

ENGINEERING.

CASE Tools A set of integratedComputer-Aided Systems Engineering(CASE) and application developmenttools that assist in softwaredevelopment, for example, analyzingbusiness requirements, designingapplications, generating applicationcode, etc.

CDM see CUSTOM DEVELOPMENT METHOD.

Corporate Repository Location of acollection of documentation,customizations, modifications, orenhancements designed to alleviate therecreation of successfully completedwork.

Change A deviation from a currentlyestablished baseline.

Change Effort Any activity consciouslyundertaken by an enterprise, businessunit, or individual, that will result incritical change in one or more areas ofthe organization, e.g. new technologyimplementation; see alsoORGANIZATIONAL EFFORT.

Change Management 1. The complete setof processes employed on a project toensure that changes are implemented ina visible, controlled and orderlyfashion. 2. The activity, or set ofactivities, undertaken to governsystematically the effects oforganizational change.

Change Management Repository Asystem for maintaining configurationitems. It provides other services suchas version control, access control andinformation storage and retrieval whichsupport the configuration managementprocess.

Change Readiness A measure of anorganization’s state of readiness torealize change successfully; involves aconsideration of an organization’s high-impact leverage points for change, aswell as any change impediments.

Change Request 1. A request for a changeto the required behavior of a system,usually from a user as a result ofreviewing current behavior. 2. Themechanism by which a change isrequested, investigated, resolved andapproved; see also IMPACT ANALYSIS.


Class..A class refers to the deliverytraining to students on a certaintopic(s). Usually, training is providedregarding Oracle applicaitons such asBill of Materials, Work in Process, etc.Training may ablso be providedregarding job policy and procedures,Help Desk operations, etc.

Client/Server A type of technicalarchitecture that links many personalcomputers or workstations (clients) toone or more large processors (servers).Clients generally manage the userinterface, possibly with some localdata. Servers usually manage multiple-access databases, including ensuringdata integrity and other invariants; seealso INVARIANT.

Class Session..A class session consists ofdelivering a class to a specific set ofstudents at a particular place and time.

Column A means of implementing anitem of data within a table. It can be incharacter, date, or number format, andbe optional or mandatory.

Common Business Function A businessfunction that appears in more than oneplace in a hierarchy.

Company A commercial business; see alsoBUSINESS.

Company Base Hardware ConfigurationThe actual hardware configuration thatsupports the company baseconfiguration; see also COMPANY

BASELINE.

Company Baseline The CompanyBaseline is the supported configurationof hardware, software, bug patches,modifications, operating systems, etc.that is part of a common set of businesssystems for the entire enterprise. Theremay be lower level of CompanyBaselines such as a Latin AmericaBaseline that is a subset of theCompany Baseline.

Completion Criteria Standards or ruleswhich determine completion of a taskto an acceptable level of quality.

Computer-Aided Systems Engineering(CASE) The combination of graphical,dictionary, generator, projectmanagement, and other software toolsto assist computer development staffengineer and maintain high-qualitysystems, within the framework of astructured method.

Computer Network An interconnectedgroup of computers.

Conceptual Architecture A high levelmodel of an enterprise’s businessapplication that identifies theorganizational and geographicaldeployment of the most criticalapplication systems and the technologycomponents required to support them..This model provides the direction forthe detailed enterprise technicalarchitecture analysis. It should reflectthe vision of the client senior executivemanagement for the future direction ofthe information systems in theenterprise.

Conference Room Pilot A system test inan environment set up to simulate thefuture production environment.


Configuration A named set ofconfiguration items. Configurationsare used to hierarchically organizeconfiguration items in order to facilitatetheir management; see alsoCONFIGURATION ITEM.

Configuration Change Theimplementation of one or more changerequests which leaves the configurationin an internally consistent state; see alsoIMPACT ANALYSIS.

Configuration Item A deliverable ordeliverable component which is placedunder configuration management.

Configuration Management The processof managing hardware, software, data,and any other documentation neededduring the development, testing, andimplementation of informationsystems.

Constraint see BUSINESS CONSTRAINT andBUSINESS RULE.

Consulting Grade Level A grade levelassigned to Oracle Services consultingresources used to calculate the cost of aresource’s labor; 1-AdministrativeAssistant to 10-Regional Vice President.

Context Diagram A high-level diagram,indicating the major functionalcomponents and major internal andexternal interdependencies of a system.

Contingency Work effort allotted in aworkplan for all unforeseen butpossible occurrences of additionalwork.

Contribution Margin see MARGIN

AMOUNT and MARGIN PERCENTAGE.

Controlled Document A document whichconstitutes or represents a projectdeliverable for approval internally orby the client, and is subject to changecontrol.

Controls Environmental information thataffects what is possible; constraints orlimits.

Conversion The total set of activitiesassociated with bringing BusinessObjects forward from legacy systems tothe newly installed Oracle applications.

Conversion Execution An example of aConversion Execution would be whereopen orders are converted from alegacy system to Oracle Order Entry inone region on a given date. Otherregions may go live with Order Entryon a different date requiring otherorder entry Conversion Executions..

Conversion Fit Analysis A formalstatement of subsystems and entitiesconverted into the new applicationsdatabase.

Core Business Process A major, driverprocess that affects or influencesbusiness objectives. The set of businessprocesses identified in association withthe objectives represent the “coreprocesses” of the business area.

Corporation A group of businesses actingas part of a single legal entity.


Cost The amount allotted or spent toacquire, deliver or produce anything.e.g. the cost of labor to deliverconsulting services, the amount spenton incidental costs to deliver consultingservices, the amount spent onhardware, software, etc.

CPU (IS It CPU or Client?) SupportIdentification (CSI) A numberassigned to each Oracle customer. Thenumber is required in order to use theSupport hotline or RTSS. Associatedwith the CSI number is the client’sname, RDBMS version, supportedproducts, operating system, telephone,area code, and Technical contracts.

Critical Path Method (CPM) Network Anetwork diagram that shows tasks,their dependency links, and theircritical path.

Critical Success Factor (CSF) A businessevent, dependency, product, or otherfactor that, if not attained, wouldseriously impair the likelihood ofachieving a business objective.

CSF see CRITICAL SUCCESS FACTOR.

CSI see CPU SUPPORT IDENTIFICATION.

CT see CUSTOM TRAINING.

Current Business Baseline The set ofbusiness process and function modelsrepresenting the current applicationsystem that supports the business area;see also BUSINESS AREA, BUSINESSPROCESS MODEL and BUSINESSFUNCTION MODEL.

Custom Code Coding added to apackaged application or modulegenerated by a CASE tool toimplement functionality that theapplication or generator has notprovided; see also CUSTOM EXTENSIONS.

Custom Development Method (CDM) Astructured method for full life-cyclecustom development projects; see alsoLINE OF BUSINESS.

Custom Extensions Custom modules thatextend the functionality of packagedapplications without modifying thebase functionality; see also CUSTOM

CODE.

Customer Service The businessorganization that 1. manages returnsand repairs of products that may ormay not have been purchased from theenterprise originally; 2. responds tocustomer complaints about service orproducts; see also BUSINESS

ORGANIZATION TYPE.

Customization A change made to thestandard Oracle software whichimplements a Solution to a Gap.

Custom Support System A custom-builtinformation system conceived,developed, and managed at theenterprise level. It provides a serviceto one or more sites or business units.Such systems are designed to begeneric, flexible, and independent ofthe particular service sites. Examplesof custom support systems are:enterprise data warehouses, dataregistry propagation systems, anddistributed application data transportsystems.


Custom Training (CT) An OrganizationalChange Management area providingorganizations with training programsdesigned to meet specific trainingneeds identified through a preliminaryTraining Needs Assessment. CustomTraining seeks to re-skill a work forceto optimize performance with newtechnology.

Cut-over Transition to a new applicationsystem in a live, production mode ofoperation.

D

Database A collection of data, usually inthe form of tables or files, under thecontrol of a database managementsystem.

Database Architecture The collectiveapplication and database instances thatcomprise the complete system.

Database Function A callable routineexecuted within a database serverenvironment.

Database Index A mechanism to locateand access data within a database. Anindex may quote one or more columnsand be a means of enforcinguniqueness on their values.

Database Instance One set of databasemanagement processes and anallocated area in memory for managingthose processes. Typically, a databaseinstance is associated with onedatabase. Note that a database instancemay process data for one or moreapplications.

Database Management System (DBMS)A software environment that structuresand manipulates data, and ensures datasecurity, recovery, and integrity.

Database Package An Oracle databaseobject comprised of PL/SQL codeallowing execution of code at the serverbased on specific events or triggers.

Database Schema see ORACLE ID.

Data Conversion The movement of datafrom a legacy system or application to areplacement application or subsystem.

Data Definition The specification of adata element to be maintained. Thespecification includes datatype, size,and rules about processing: forexample, derivation, and validation;see also BUSINESS RULE and INVARIANT.

Data Definition Language (DDL) Asubset of SQL used to create, alter,drop, and otherwise change definitionsof tables, views, and other databaseobjects.

Data Dictionary A part of a database thatholds definitions of data elements, suchas tables, columns, and views.

Dataflow A named flow of informationbetween business functions, datastores,and external entities represented as anarrow on a dataflow diagram; see alsoBUSINESS FUNCTION, DATASTORE, andEXTERNAL ENTITY.

Dataflow Diagram A diagramrepresenting the use of data bybusiness functions; see also DATAFLOW,DATASTORE, EXTERNAL ENTITY, andPROCESS.


Dataflow Diagramming A technique forexpressing the significant dataflows ofa business system.

Data Integration The movement of databetween two co-existing systems. Theinterfacing of this data may occur onceevery hour, once a day, etc.

Data Integrity Testing Verification thatconverted data is accurate andfunctions correctly within a singlesubsystem or application.

Data Migration The movement of datafrom one database to another database-- but not necessarily to a workingapplication or subsystem tables.

Data Model A representation of thespecific information requirements of abusiness area; see also ENTITY

RELATIONSHIP MODEL.

Data Partitioning A technique to improveapplication performance or security bysplitting tables across multiplelocations.

Data Profile A description of the businessconditions that are needed to test theapplication system..

Data Registry The master copy of the dataassociated with a business object.Several databases may share access to acommon data registry to ensureconsistency and eliminate redundantentries across multiple applications anddatabases. An example of a dataregistry would be a shared customermaster. All updates and changeswould be made to the customer masterdata registry and are then propagatedto subscribing sites. All systemsrequiring customer information wouldinterface with the customer dataregistry.

Data Registry Interface An interface thattransfers data registry data betweensimilar or dissimilar applications.

Data Replication The copying of data toand from sites to improve local serviceresponse times and availability;frequently employed as part of abackup and recovery strategy.

Datastore A temporary or permanentstorage concept for logical data itemsused by specified business functionsand processes.

Data Transfer The physical movement ofdata between applications, perhapsacross sites.

Data Transformation The process ofredefining data based on somepredefined rules. The values areredefined based on a specific formulaor technique.

Data Translation The process ofredefining data in a manner differingbetween its original representation andits final representation.


Data Warehouse A repository of subject-oriented data used for informationretrieval and decision support.

DB2 An SQL-based databasemanagement system.

DBMS see DATABASE MANAGEMENT

SYSTEM.

DDL see DATA DEFINITION LANGUAGE.

Decision A point in a process flow wherethere is a choice of possible paths. Theoutcome of the decision determineswhich path the flow follows.

Decision Point The diagrammaticrepresentation, on a process flowdiagram, of a decision which results inthe subsequent execution of one of twoor more alternative sequences ofprocess steps. The decision is actuallymade during the execution of theprevious process step. The decisionpoint is shown after that step fordiagrammatic convenience.

Decision Support System (DSS) Anapplication primarily used toconsolidate, summarize, or transformtransaction data to support analyticalreporting and trend analysis.

Deliverable A tangible, measurableoutput of a task.

Deliverable Component A subset of adeliverable. A deliverable componentmay be the output of a task step.

Deliverable Guideline A detaileddescription of a deliverable thatincludes: detailed description, usage,audience, and distribution, formatguidelines, control, template, andsamples; see also DELIVERABLE.

Deliverable Management The process ofmanaging the creation, review,modification and distribution ofdeliverables provided to a client.Software may be included as one of themanaged deliverables.

Deliverable Template A tool designed toaid in production of deliverables; atemplate that gives the format andstructure of a deliverable; see alsoDELIVERABLE.

Delivery Vehicle The mechanism forproducing or implementing something.For example, SQL* Forms is a vehicle toproduce computer programs.

Dependency The relationship of one taskto another where the start or end dateof the second task (successor)constrained by the start or end date ofthe first (predecessor); see alsoPREDECESSOR and SUCCESSOR.

Deployment ..The total set of activitiesassociated with the productionimplementation of a set of applicationsin specific location(s) at a particularpoint in time.

Design Prototype A first working versionof a system generated directly frombusiness models.


Detailed Deliverable A deliverablewhose structure originated from a highlevel deliverable, but that containssignificantly more detail; see alsoDELIVERABLE and HIGH-LEVEL

DELIVERABLE.

Development Life-cycle A completeprocess of developing computersystems.

Distributed Database A database that isphysically located on more than onecomputer processor. It is connected viasome form of communicationsnetwork. An essential feature of a truedistributed database is that users orprograms work as if they had access tothe whole database locally.

Distributed Processing The ability tohave several computers workingtogether in a network, where eachprocessor runs different activities for auser, as required.

Distribution A high-level businessfunction responsible for configuring thefirmware parts of inventory, housingfinished goods inventory (FGI), andshipping finished goods to customersor to internal sites; often synonymouswith a business organization; see alsoBUSINESS ORGANIZATION TYPE.

Distribution Management DistributionManagement is the process to managethe release and distribute of software ina controlled manner. This includes thekitting of software, documentation,patches and other. It involves initialreleases and subsequent patch tapes,upgrades and new releases. It alsoincludes providing the organizationalchallenges of obtaining releaseapproval from the Company BaselineReview Board (CBRB).

DSS see DECISION SUPPORT SYSTEM.

E

EBF see ELEMENTARY BUSINESS FUNCTION.

EF see ESTIMATING FACTOR.

Effort The amount of work, measured inperson-hours, to perform a task.

EIS see EXECUTIVE INFORMATION SYSTEM

Element A thing of significance aboutwhich information is recorded; acomponent at the most useful, basiclevel.

Element Type Any element held in therepository is classified as a particulartype. Examples of element type areentity, attribute, program module,process, table, diagram, text, softbox.Occurrences or instances of these arecalled elements.


Elementary Business Function (EBF) Abusiness function which if started, musteither complete successfully or, if itcannot complete successfully, mustundo any effects that it has had up tothe point of failure. An elementarybusiness function changes a business’sdata from one consistent state toanother; see also FUNCTION HIERARCHY.

End User see USER.

Enterprise A group of departments,divisions, or companies which make upan entire business.

Enterprise Support Systems The set of allcomputer-based systems, documents,and procedures used in support ofbusiness enterprise operations.

Enterprise Technical Architecture (ETA)A series of rules, guidelines, andprinciples used by an organization todirect the process of acquiring,building, modifying, delivering, andintegrating Information Technologyresources throughout the enterprise.These resources can include equipment,software, business processors,protocols, standards, methodologies, ITorganizational structures and more.

Entity A thing of significance, whetherreal or imagined, about whichinformation needs to be known or held.It is implemented in a database as oneor more tables.

Entity Integrity Rules The rules thatspecify valid values or combination ofvalues for attributes of an entity. Thesemay include unique identifiers,domains, and multi-attribute validationrules; see also BUSINESS RULE andREFERENTIAL INTEGRITY CONSTRAINT.

Entity Relationship Diagram (ERD) Adiagram that pictorially representsentities, the relationships between themand the attributes used to describethem; see also ATTRIBUTE, ENTITY, andRELATIONSHIP.

Entity Relationship Model A type of datamodel. Part of the business model thatconsists of many Entity RelationshipDiagrams; see also DATA MODEL.

Entity Test A detailed test of certain keydata elements of a business entity thatis being converted or interfaced fromone system to another.

ERD see ENTITY RELATIONSHIP DIAGRAM.

Ergonomics The use of good designtechniques that emphasize ease-of-use.

Estimate A preliminary calculation of thetime and cost of work to beundertaken. The construct optioncalculates estimates using bottom-up,percent adjustment, or top-downtechniques in Project Bridge Modeler;see also BOTTOM-UP ESTIMATE, PERCENT

ADJUSTMENT ESTIMATE, WORK ESTIMATE,and TOP-DOWN ESTIMATE.

Estimated Function Point Count 7Function Points per System Entity + 5Function Points per System Function.


Estimating Factor (EF) An item thatcritically affects the amount of workeffort estimated to complete a task; seealso BOTTOM-UP ESTIMATE.

Estimating Formula A formula that usesestimating factors to derive an estimatefor a task.

Estimating Guideline Text whichdescribes in detail how a task isestimated.

Estimating Model The combination ofestimating factors and estimatingformulas necessary to completelyestimate a route.

ETA see ENTERPRISE TECHNICAL

ARCHITECTURE.

Event An occurrence in a business’senvironment to which that businessmust respond; see also BUSINESS SYSTEM

and EVENT RESPONSE.

Event Mechanism A permissible way inwhich an event is recognized. Forinstance, a Customer Order may beentered into the system if received byfax, phone, mailed-in purchase order orinternet-facilitated, but not by markingson a scratch pad.

Event Response An event and thebusiness process which responds tothat event; see also APPLICATION

SYSTEM, BUSINESS SYSTEM, and EVENT.

Executive Information System (EIS) Areporting application targeted for useby executives. Usually suchapplications have extremely user-friendly, graphical interfaces with asmall local datastore derived fromconnection to a data warehouse. It isoften used synonymously with decisionsupport system.

Expense The amount of money allotted orspent to cover incidental costs (e.g.travel & living) or the cost of something(hardware, software, etc.) to deliverconsulting services.

Expense Reimbursement Expenses forreimbursement by the client eitherallotted or received.

(CASE Dictionary) Extensibility It isoften useful to add new elements,properties, and associations into theDictionary. This is achieved by afacility know as user extensibility.

External Business Function A businessfunction that is outside the scope of theapplication system, that acts as a sourceor recipient of dataflows.

External Entity An entity that is outsidethe scope of application system, thatacts as a source or recipient ofdataflows. An external entity might bea person, a business unit, anotherapplication system, or any other thingthat might provide or receiveinformation from a function within theapplication system; see also ENTITY.

External Process Step A process step thatis performed by an agent outside thebusiness area; see also INTERNALPROCESS STEP and PROCESS STEP.


F

Fee A charge, compensation, or paymentfor a service or product.

Feedback Response, includingcorrections, additions, and approval,elicited from users, stakeholders,sponsors, and others, to any deliverableor deliverable component.

Feedback Session A meeting organizedto present work in progress in order togain feedback; see also FEEDBACK.

FH see FUNCTION HIERARCHY.

Field A means of implementing an item ofdata within a file. It can be incharacter, date, number, or otherformat and be optional or mandatory.

File Transfer Protocol (FTP) The physicalmovement of data files betweenapplications, often across sites.

Finance A high-level business functionthat handles accounting and financialfunctions of a company; for example,corporate, division, and subsidiaryheadquarters; often synonymous with abusiness organization; see also BUSINESS

ORGANIZATION TYPE.

Financial Organization A businessorganization that performs one or morefinancial business functions. The datais segregated for organizationalmanagement or security. Whenmapped onto Oracle Applications, afinancial organization is required tohave a defined set of books. Thisconcept is more general than the set ofbooks. It is replacing the set of booksas the key financial applicationfunctional configuration parameter inreleases of Oracle Applications startingwith 10.6.

Flexfield A user-definable field in anOracle Application that is made up ofsegments. Each segment has a nameyou assign and a set of valid values.

Focus Area 1. A group of associatedactivities that define and establishprogram level deliverables, i.e.standards, configuration, andprocesses. These deliverables are usedby multiple projects creatingcommonality and reusability across theprogram. 2. A team of individualsworking within the Program Officeframework for a common family ofprocesses. These focus areas could alsobe referred to as Program OfficeProjects.

Focus Group A small group selected toprovide opinions and responses totopics or issues presented in a groupsetting; an assessment technique.

Foreign Key One or more columns in arelational database table thatimplement a many-to-one relationshipthat the table in question has withanother table or with itself.


Form A program for viewing or enteringinformation. Normally it refers to arectangular area of the screen, whichhas the appearance of a paper form,through which you can view ormanipulate information in a database.

Formal Build Construction of aninformation system by the wellestablished steps of specify, code, test,correct.

Format The type of data that an attributeor column may represent; for example,character, date, number, sound, orimage.

Fourth-generation ProgrammingLanguage (4GL) A language thatmanipulates high-level objects, such asscreen items and database tables, bydeclaring what is to be done to themrather than procedurally describinghow it is to be done, as in 3GLs.

FTP see FILE TRANSFER PROTOCOL.

Function see BUSINESS FUNCTION,ELEMENTARY BUSINESS FUNCTION, andSYSTEM FUNCTION.

Function Decomposition A technique formodeling business functions bydecomposing a single business functioninto a number of lower level businessfunctions, and then progressivelydecomposing these until theappropriate level of detail is reached.Function decomposition gives rise tofunctions arranged in groups orhierarchies known as a businessfunction hierarchy; see also ATOMIC

FUNCTION, ELEMENTARY BUSINESS

FUNCTION, and FUNCTION HIERARCHY.

Function Dependency The dependencyof one function's commencement uponthe completion of another function.

Function Dependency Diagram A visualmeans of recording dependenciesbetween business functions.

Function Hierarchy A grouping ofelementary business functions into oneor more hierarchical levels. Typicallythe highest level corresponds to thecompany organization, and the middlelevel corresponds to a grouping ofavailable application functions; see alsoBUSINESS FUNCTION and FUNCTION

DECOMPOSITION.

Function Label A unique ID, within anapplication system, used for a businessfunction.

Function Name A short, succinctsentence, starting with a verb,describing a business function; see alsoFUNCTION LABEL.

Function Point Analysis (FPA) Atechnique used to estimate system size.Using Function Point Analysis, you cancalculate system size based on thenumber of functional element types inthe system you are building, asadjusted by its general systemcharacteristics and your technologyproductivity factor; see alsoFUNCTIONAL ELEMENT TYPE.

Function Point Estimate (FPE) Anestimate of work effort produced usingFunction Point Analysis or anequivalent method.


Functional Currency The principlecurrency used to record most businesstransactions and maintain accountingdata while working within a particularOracle Application set of books.

G

Gantt Chart A scheduling tool used todisplay the status of a project’s tasks.A Gantt chart shows each task’sduration as a horizontal line. The endsof the lines correspond to the task’sstart and end dates.

Gap A Gap is a relationship between aRequirement and an ApplicationFunction where the standardApplication Function will not meet theRequirement.

Gap Analysis 1. The process ofdetermining, documenting, andapproving the variance betweenbusiness requirements and systemcapabilities in terms of packagedapplication features and technicalarchitecture. 2. The process ofdetermining and evaluating thevariance or distance between two itemsproperties being compared.

General Education Course A course thateducates the project team or users infundamental business concepts. Itexposes attendees to new businessapproaches practiced in industry andprovides them with a commonunderstanding of relevant businessissues.

Generator A mechanism for transformingthe specification of a module intoexecutable program code, also knownas a code generator.

Generator Template A skeleton or outlineprogram from which a generator canreuse common elements; for example,boilerplate information, window sizes,OK and Quit buttons.

Goal see BUSINESS GOAL.

Group Interview Any session whereusers, stakeholders, or sponsorscollectively discuss the requirements,priorities, design, or implementation ofa business solution system; see alsoFEEDBACK and WORKSHOP.

Guideline Text that provides instructionsand advice for performing a task andsuggests possible approaches.

H

Hardware Node A computer on anetwork; for example, clients andservers.

Help Desk A support system designed toassist end users with technical andfunctional questions and problems.

Helptext see METHOD HELPTEXT.

High-level Deliverable A deliverable thatspecifies a framework into whichfurther details can be added; see alsoDELIVERABLE, DETAILED DELIVERABLE,and INITIAL DELIVERABLE.


Human Resources The high-levelbusiness function involving themanagement of human resources andpayroll functions of a company; oftensynonymous with a businessorganization; see also BUSINESS

ORGANIZATION TYPE.

I

Impact Analysis The process ofunderstanding the complete effect of aparticular change; see also CHANGE

REQUEST.

Implementation Questionnaire A toolyou use to collect business and systeminformation during a business baselineinterview. It consists of a pre-built setof questions organized by businessfunction that are to be supplementedby the analyst with relevant companyterms and other characteristics beforeuse in driving the interview.

Index see DATABASE INDEX.

Information Access Model A model thatdepicts access to key process andorganization information for reportingand/or security purposes.

Information Flow Model A model thatvisually depicts information flows inthe business between businessfunctions, business organizations andapplications.

Information Model see DATA MODEL.

Information Systems (IS) A system formanaging and processing information,usually computer-based. Also, afunctional group within a business thatmanages the development andoperations of the business’ informationsystems.

Information Systems Strategies (ISS) Amethod that aligns informationtechnology priorities with businessstrategies and defines the approach totake to achieve those goals.

Information Warehouse see DATA

WAREHOUSE.

Initial Deliverable A deliverable is initialif it is intended to be updated later. Aninitial deliverable is usuallypreliminary and its content changeableby a later task when more informationis known.

IPO The Input-Process-Output techniqueis a generic modeling tool that wasdesigned for framing complete processspecifications by identifying: inputs,rules, process step descriptions, toolsand outputs.

Installation The loading of an instance ofan application system that is complete,tested, operational, and ready. Aninstallation includes all necessarysoftware, hardware (includingterminals, networks, etc.) anddocumentation, and includes allrequired data; see also APPLICATION

SYSTEM.

Instance see DATABASE INSTANCE.


Integration Fit Analysis A statement of fitand gaps for integration points betweenunique applications and installations ofthe same application.

Integration Test A sequence of steps orset of procedures to verify the inter-operability of various systemcomponents; see also SYSTEMS

INTEGRATION TEST.

Inter-company Transaction A transactionbetween two legal entities that sharecommon ownership, for example,under the same holding company. Thetwo companies usually have an accountrelationship (for example, an inter-company suspense or clearing account)that facilitates inter-companyaccounting.

Interface A linkage between systemswhich can be either automated (viasoftware programs) or procedural(manual).

Interface Programs A set of programsthat systematically link two or moresystems to each other.

Internal Process Step A process step thatis performed within the business area;see also EXTERNAL PROCESS STEPand PROCESS STEP.

Inventory Organization A fundamentalOracle manufacturing and distributionapplication functional configurationparameter. The inventoryorganizations are derived by mappinginventory or manufacturing businessorganizations onto Oracle Applications.Typically they will be manufacturingplants, warehouses, divisions, ordepartments.

IPO The Input-Process-Output techniqueis a generic modeling tool that wasdesigned for framing complete processspecifications by identifying: inputs,rules, process step descriptions, toolsand outputs.

IS see INFORMATION SYSTEMS.

ISS see INFORMATION SYSTEMS STRATEGIES.

Issue A situation or concern whichrequires a resolution. Some issues, ifnot addressed, could adversely impactthe success of a project.

Item Master The master list of all itemsavailable for transaction within aproduct group containing Oraclemanufacturing applications. It is also akey application functionalconfiguration parameter.

K

Key A way of accessing something. Anyset of columns used for retrieval ofrows from a table; see also COLUMN,PRIMARY KEY, and UNIQUE IDENTIFIER.

Key Deliverable A major deliverable thatis usually reviewed with the client,signed off, and placed under changecontrol; see also DELIVERABLE.

Key Performance Indicator (KPI) Asignificant measure used on its own, orin combination with other keyperformance indicators, to monitorhow well a business is achieving itsquantifiable objectives.


Key Resource A person with a widerange of skills or experiences who canbe effective in many types of tasks, or iscritical to the completion of a specifictask.

KPI see KEY PERFORMANCE INDICATOR.

L

Labor Cost see COST.

Labor Cost Rate The rate (internal cost)for each consulting grade level fordelivering services to a client.

Labor Fee see FEE.

Labor Fee Rate The rate (price) for eachconsulting grade level charged fordelivering services to a client.

Leaf Function An function that is notdecomposed at the bottom of a functionhierarchy. It may be a leaf functionbecause definition is incomplete.

Legacy Application Interface Aheterogeneous interface between OracleApplications and a pre-existing andpreserved legacy system.

Legacy System An existing systemrepository of information andprocesses.

Legal Entity A high level businessorganization that operates within thebounds of a specific set of legalrequirements (including currency),typically pertaining to tax regulationsand reporting requirements

Line of Business (LOB) Each servicewithin Oracle Services is a line ofbusiness. For example, CustomDevelopment, ApplicationImplementation, and Business ProcessReengineering are all lines of business.

Link Test A test to identify errors inlinked modules of an applicationsystem. Link testing is an extension ofmodule testing carried out on a numberof levels of detail. Examples include,linked modules of a program, linkedprograms of a functional area orsubsystem, and linked subsystems ofthe complete application system. Thelink test is usually a white box test; seealso MODULE INTEGRATION TEST.

Live Implementation process has endedand the solution is put into production.

LOB see LINE OF BUSINESS.

Local Currency The denomination ofcurrency used for transactions in aparticular local finance businesslocation.

Localization An enhancement ormodification necessary to supportspecific site requirements notaddressed by the base configurationhardware and software. It isdeveloped by and purchased fromOracle. These site specificrequirements generally satisfy agovernment or regulatory agencyrequirement, although localizations arenot limited to this purpose.

Localization Approval The agreement tomodify the company standard softwareand hardware configuration relative tothe site requirements.


Localization Tape A tape containinglocalization programs to be installed tothe applications software.

Location see BUSINESS LOCATION.

Logical Application Architecture Acomplete map of the applicationinstances required to support theapplications architecture.

Logical System Design The task ofdesigning a system to support businessneeds without making final decisionsregarding the physical implementation.The same logical design should beappropriate for many physicalimplementations using, for instance,different versions of a databasemanagement system.

Look and Feel The appearance andbehavior of a system facility asperceived by the end user. Thisincludes the data, the layout, and theuser interaction through menus,buttons, text editing, and other devices.

M

Management The process of planning,controlling, and completing theexecution of an undertaking.

Manual Function A business functionthat is not system-assisted; see alsoBUSINESS FUNCTION and SYSTEM-ASSISTED.

Manufacturing A high-level businessfunction responsible for manufacturingor assembling products; oftensynonymous with a businessorganization; see also BUSINESS

ORGANIZATION TYPE.

Mapping A technique for establishingapplication fit to businessrequirements, identifying gaps andproposing initial solutions. Also atechnique to define the relationshipbetween objects; see alsoAPPLICATION FIT and MATRIX

DIAGRAM.

Mapping Scenario 1. A plan for andrecord of business solution testingincluding: business processes involvedin the test, the business conditions thatare needed to test the applicationsystem, definition of test scriptexecution, support tools requiredduring execution of the test, and arecord of test actions. 2. A detailedstep by step description of how youwant team members to test thestandard Oracle software to see if itwill meet the needs of a RequirementsScenario; see also BUSINESS SOLUTIONTESTING

Mapping Team A group of peopleresponsible for the modeling, design ormapping for a particular businessprocess.

Margin Amount The difference betweenthe costs (labor, expenses, andoverhead) and revenue plus expensereimbursements expressed as acurrency amount.


Margin Percentage The ratio between themargin amount and costs, expressed asa percentage.

Marketing A high-level business functionresponsible for marketing functionswithin a company; often synonymouswith a business organization; see alsoBUSINESS ORGANIZATION TYPE.

Matrix Diagram A spreadsheet diagramwhere the axes represent twoassociated types of elements of interestto information systems developers. Amatrix diagram is used to express amapping.

Mechanism 1. A particular technique ortechnology for delivering a function.Examples might be a telephone, acomputer, or an electronic mail service.2. Resources that enable or facilitate thestep/sequence in a test scenario.

Method A structured organization oftasks, estimates, and guidelines thatprovide a systematic approach ordiscipline.

Method HelpText The automated form ofOracle Method’s handbooks includedwith every route. This may be accesseddirectly from the Windows desktopor from within Project Bridge Modeleror Project Workbench; also calledonline help.

MIPS Millions of Instructions Per Second-- a measure of computer processingcapacity.

Module A logical program unit.Examples include: forms, reports, userexits, C programs, PL/SQL procedures,and database triggers; see also PRIMARY

MODULE and SUPPORTING MODULE.

Module Integration Test A test of relatedmodules in an application system usingscenario test specifications.

Module Network A technical diagram ofmodules in an application system thatexpresses the possible execution pathsof business transactions.

Module Process Test Model A detailedtesting model for the development andexecution of testing. It is identical to theSystem Process Test Model, with theaddition of module references.

Module Test A procedure or sequence ofsteps that determines whether amodule functions properly in isolationfrom other system components, andconforms to project standards.

MoSCoW Must have, Should have, Couldhave, Won’t have, a way of classifyingand prioritizing facilities for inclusionin an information system; used intimeboxed development where thescope may need to be redefinedaccording to the rate of progress.

N

Near Real-time Interface An applicationinterface that supports asynchronoustransfer of data between applications.It transfers data with a sufficientlysmall time delay so as to leave theinterfaced applications in states that arevery close to synchronized.


Node A single computer, group ofcomputers, or mechanism for handlingsome communication traffic through aparticular point on a computernetwork.

Non-Billable Project Expenses Theproject expenses that are not billable toa client; see also PROJECT EXPENSES.

Non-Billable Utilization The utilizationthat is not billable to a client; see alsoUTILIZATION.

Non-revenue Entity A legal entity thatperforms services on behalf of anotherentity. Such services are usuallyperformed in exchange for an inter-company service fee.

Normalization A technique to eliminatedata redundancy.

Null The state of a data item indicating novalue. Null is not equivalent to zero.

O

Objective A statement of business intentthat may be measured quantifiably.

Object Orientation (OO) The perspectivethat systems should be constructedfrom objects, which themselves may beaggregations of smaller objects.

OC see ORGANIZATIONAL

COMMUNICATIONS.

OCM see ORGANIZATIONAL CHANGE

MANAGEMENT.

ODS see OPERATIONAL DATASTORE.

OLAP see ON-LINE ANALYTICAL

PROCESSING.

OM see ORACLE METHOD.

On-Line Analytical Processing (OLAP)On-line retrieval and analysis of data toreveal business trends and statistics notdirectly visible in the data directlyretrieved from a data warehouse. Alsoknow as multi-dimensional analysis.

OO see OBJECT ORIENTATION.

Operational Datastore (ODS) A datawarehouse that is a repository for nearreal-time operational data rather thanlong term trend data.

Oracle ID An account on a database,comprised of a database username andpassword.

Oracle Method (OM) Oracle Services'integrated service methodology whichconsists of workplans, handbooks, andtemplates used to provide enterprisebusiness system solutions.

Oracle Services An Oracle Corporationbusiness organization that providesprofessional services.

Oracle Survey Tool A customizabledatabase of questions used byOrganizational Change Managementsto generate surveys, data analyses, andgraphical reports for assessments.

Organization see BUSINESS ORGANIZATION.

Organization Type see BUSINESS

ORGANIZATION TYPE.


Organization Unit An element thatrepresents part of the structure of abusiness. An organizational unit canrepresent an entire business, a group ordepartment within the business, aperson within a group or departmentor a role; see also AGENT, BUSINESS

UNIT, and AGENT CHANNEL.

Organizational Change Management(OCM) An Oracle Services line ofbusiness providing changemanagement expertise to organizationsseeking to manage the human andorganizational factors involved withimplementing new technology.Organizational Change Managementsincludes five service areas:Organizational EffectivenessAssessments, OrganizationalCommunications, Human Performanceand Development, LeadershipDevelopment, and Custom Training;see also ORGANIZATIONAL

EFFECTIVENESS ASSESSMENTS,ORGANIZATIONAL COMMUNICATIONS,HUMAN PERFORMANCE AND

DEVELOPMENT, LEADERSHIP

DEVELOPMENT, and CUSTOM TRAINING.

Organizational Effort Any activity or setof activities implementedsystematically by an organization toachieve a particular goal.

OT see OBJECT TECHNOLOGY.

Outsourcing The practice of appointingan external organization to provide anyor all of the services of the ISdepartment or any other internalservice department.

Overhead The operating expensesassociated with delivering services,such as rent, light, heat, taxes and non-billable utilization.

Overhead Factor A rate multiplierassociated with a category of overhead,e.g., Corporate, Division, or Practice;see also OVERHEAD.

P

Partition need definition.

Part Master see ITEM MASTER.

PAT see PERFORMANCE ASSURANCE TEST.

Payment Milestone A significant projectevent at which time a payment is due.Payment milestones can be progresspoints, dates, the completion of a taskor the production of a deliverable.

Payment Terms The terms and conditionsupon which payments will be receivedfrom a client.

PBM see PROJECT BRIDGE MODELER.

PCM see PRACTICE MANAGEMENT.

Percentage Adjustment Estimate Totalestimate adjusted for organizationalfactors.

PGM see PROGRAM MANAGEMENT.

Phase A grouping of tasks that lead to amajor project deliverable or milestone.

Phase Completion The projectmanagement tasks which conclude andsecure client sign-off of a phase.


Phase Control The project managementtasks which execute concurrently withphase execution, and perform projectmonitoring, directing, and reportingfunctions during a phase.

Phase Execution The method executiontasks performed during a project phase.

Phase Management The projectmanagement tasks required to plan,control and complete the execution of aproject phase.

Phase Planning The project managementtasks which update project plans andprocedures for a phase and secureadditional resources necessary toexecute that phase.

Physical Application Architecture Acomplete map of the databaseinstances, their sites, and theapplication instances and Oracle IDsthat they support. This willincorporate aspects of the logicalarchitecture, and the high level designsfor security and interfaces.

Pilot An initial project which will serve asa model or template for future projects.

PJM see PROJECT MANAGEMENT.

Plan A scheme, method or design for theattainment of some objective or toachieve something.

Planned Response System The entire setof business processes in a businessarea that respond in a predeterminedway to a known set of events; see alsoAPPLICATION SYSTEM and EVENT.

(M&D) Planning A high-level businessfunction responsible for manufacturingand distribution planning for one ormore manufacturing and distributionbusiness units; often synonymous witha business organization; see alsoBUSINESS ORGANIZATION TYPE.

Policy A policy is a documented directivefrom enterprise management whichspecifies how some aspect of thebusiness is to be conducted.

Practice Management (PCM) Specifies theprocess, tasks, and responsibilitiesregarding the management of aconsulting practice. Specifically, thisincludes client management, projectportfolio management, and stafftraining, recruitment, and growth.

Predecessor A task that precedes anothertask and is related to it by a taskdependency; see also SUCCESSOR.

Prerequisite Something needed by a taskproduced by a previous task or anexternal source; see also DELIVERABLE.

Pre-sales Cycle The series of activitiesthat occur before the application wasselected.

Problem A perceived variance betweenthe expected and observed ability of anitem to fulfill its defined purpose.

Problem Statement A concise phrase,motto or goal-oriented explanation ofthe motivation behind buying a newapplication system.

Problem Report The mechanism by whicha problem is recorded, investigated,resolved and verified.


Procedure A written set of steps thatspecifies how to carry out a businessfunction. If the business function issystem-assisted, its correspondingprocedure will indicate how theapplication system carries out thatbusiness function; see also APPLICATION

SYSTEM and BUSINESS FUNCTION.

Process 1. The sequential execution offunctions triggered by one or moreevents. 2. A grouping of tasks within amethod based on common functions ordisciplines which lead to one or morekey deliverables; see also BUSINESS

PROCESS and SYSTEM PROCESS.

Process Analysis A component of abusiness requirements scenario thatfacilitates quantitative analysis andmeasurement of each process step andcompares the current to the proposedprocess in order to sell change tomanagement and to key businesspeople and systems users.

Process Characteristics Attributes thatdescribe a process and how it worksincluding descriptive narrative for itssteps, tools required, skill levelsrequired, controls, performancemeasures

Process Flow The passing of execution ofa process from one process step to thenext. It may include the passing ofinformation or materials from the firststep to the second.

Process Flow Diagram A diagram whichshows the triggering event(s),sequential flow of process steps,decision points, and deliverable oroutcome of a single process.

Process Label A unique reference, withinan application system, for a process.

Process Modeling A structured approachused to identify, define, and documentthe activity performed by a business toproduce business deliverables.

Process Narrative A reduction of a newbusiness process design down to a job-level description, thereby defining howthe work gets done and laying afoundation for development of a userguide, role-based user training anduser certification or other types ofreadiness testing. One ProcessNarrative should be written for eachbusiness process.; see also ROLE-BASED USER TRAINING

Process Owner The agent with overallresponsibility for a complete businessprocess; could be the customer of theprocess, or the supplier (person ororganization charged with fulfilling therequest).

Process Research A technique used intesting the feasibility of a processmodel and gathering facts in order tooffset doubters and naysayers. Theapproach involves answeringImplementation Questionnaires,reviewing current processdocumentation, gathering statisticsregarding volumes or frequencies,understanding policy statements andmeasures of performance, interviewingkey users to ascertain critical factors forsuccess.


Process Step An instance of the executionof a function as a step in performing aprocess. In a fully-analyzed businessprocess model, all process steps areinstances of elementary businessfunctions. A business process step isnormally composed of a series ofprocedure steps, where tools such asapplication screens, reports andinquiries are used. Once a processsteps begins, all of its procedure stepsmust be completed in order to achievean accurate and quality output.Business requirements are defined atthe process steps level, while jobdefinitions are at the procedure level.

Product Group Each separate applicationinstance of Oracle Application ObjectLibrary in an Oracle database. Aproduct group may contain anynumber of Oracle Applicationsproducts in addition to the singleinstance of Oracle Applications ObjectLibrary.

Production Environment The database,equipment, documentation, andprocedures used in support of livebusiness operations.

Profile Option An Oracle Applicationscontrol switch that a user can set togovern some aspect of systemprocessing or user interface.

Program 1. A set of coded instructionsthat a computer executes or interpretsto perform an automated task. 2. Ainterrelated group of projects that areeither being run concurrently orsequentially and that share a systemgoal. Individual projects may havedifferent goals, however the combinedset of projects will have a programgoal. 3. A data object in OraclesProgram Management Methodology(PGM).

Program Library The physical location ofall Program related deliverables, ,standards, tools, communications, etc.that support an entire Program. Itemswithin the Program Library areprogram level solutions

Program Management (PGM) A methodwhich defines how a program ismanaged when executed according tothe requirements of Oracle Method.

Program Office A project executed underthe sponsorship of programmanagement that establishescommonality and reuse across multipleprojects within a program.

Project A set of work processes, taskswith associated deliverables andresources executed over a specificperiod of time with predetriminedbudget and business objectives.

Project Bridge Modeler (PBM) AppliedBusiness Technology tool used to buildthe project planning and estimatingsystem. PBM allows project managersto select, edit, combine, and createproject workplans or routes, that bestfit the needs of the client.


Project Completion The third and finalpart of the PJM project life-cycle. Thesatisfactory conclusion of the projectand settlement of all outstanding issuesprior to hand over of the projectdeliverables to the client.

Project Earned Value A measure of thevalue of completed tasks in a project.There are various ways of measuringthe value of a task. These includepercentage on commencement,percentage on completion, and amountat milestone.

Project Execution The second part of thePJM project life-cycle. The carrying outof project plans determined duringplanning for a method approach.Project execution also encompasseselements of control which analyzeproject performance and take correctiveaction as needed.

Project Expenses Funds allocated or spentto cover incidental or non-labor costs ofa project.

Project Infrastructure The framework forstoring, maintaining, and referencingall implementation deliverables andsupporting materials including officespace, software tools, and standards.

Project Library 1. A system for storing,organizing and controlling alldocumentation produced or used bythe project. 2. The physical location ofall deliverables for a single project, plusadministrative and support materials.An administrative office that allmembers of a team should have accessto.

Project Life-cycle The organization of aproject according to its three majorparts: planning, execution andcompletion.

Project Management Method (PJM) Amethod which defines how a project ismanaged when executed according tothe requirements of Oracle Method.

Project Milestone A significant projectevent.

Project Objectives The set of criteria formeasuring a project’s success.

Project Office The management of theproject library for a specific project.

Project Partition Part of a project usuallyrepresenting a coherent set of facilitiesto be developed by a single developer,commonly organized and managed as asub-project.

Project Planning The first part of the PJMproject life-cycle. The definition of aproject with respect to scope, quality,time and cost. Project planning alsodetermines the appropriateorganization of resources andresponsibilities to execute a project.

Project Schedule A list of tasks to becarried out presented against atimetable for their completion.

Project Timeline A specification of workto be carried out together with thenumber of resources needed to achievea target duration; see also PROJECT

SCHEDULE.


Project Workbench (PW) AppliedBusiness Technology tool used toschedule, track, and analyze yourproject. PW provides work breakdownstructures based on the routes selectedin Project Bridge Modeler and providesthe capability to manage these plans.

Project Workplan A specification of thework to be performed for a project,expressed as a set of interdependenttasks with project resources allocatedover time.

Property Any detail that serves to qualify,identify, classify, quantify, or expressthe state of an element in a repository.

Prototype A facsimile of an end productused to demonstrate a concept rapidly,check feasibility, and/or gainacceptance.

Prototyping The construction of a partialsystem to demonstrate some aspect oraspects of the intended systembehavior in order to gain useracceptance or to establish technicalfeasibility.

Publish and Subscribe A datacommunication paradigm forimplementing the data flow betweentwo or more applications. An event ina source application causes theapplication to ‘publish’ a data object ormessage to the potentially interestedapplications who individually opt to‘subscribe’ to the data object ormessage. The subscription of theinterested applications to the dataobject or message causes a state changein the applications. Contrast Request-Reply.

PW see PROJECT WORKBENCH.

Q

Quality Audit An audit used to assess theadherence of the project team to plans,procedures, and standards.

Quality Management The means ofimplementing quality policy. On aparticular project this is achievedthrough quality planning, qualityassurance, quality control, and qualityimprovement.

Quality Review A review used to assessthe quality of a deliverable in terms offitness for purpose and adherence todefined standards and conventions.

Questionnaire A written or electronicsurvey instrument comprised of aseries of questions, designed tomeasure a specific item or set of items.

R

RBT see ROLE-BASED TRAINING.

RDBMS see RELATIONAL DATABASE

MANAGEMENT SYSTEM.

Real-time Interface An applicationinterface that supports synchronoustransfer of data between applications.

Real-time Support System (RTSS) Anelectronic information systemaccessible by Oracle and the client.


Real-time System A system in whichevents control actual mechanisms.Real-time systems often controlmachinery (for example, a controlsystem for an aircraft) and are oftentime- or safety-critical; see also EVENT

and STATE TRANSITION DIAGRAM.

Record In a non-relational databasesystem, a record is an entry in a file,consisting of individual elements ofinformation, which together providefull details about an aspect of theinformation needed by the system.Individual elements are held in fieldsand all records are held in files. Anexample of a record might be anemployee. Every detail of theemployee for example, date of birth,department code, or full names will befound in a number of fields. In arelational system record is an alternateword for row; see also ROW.

Record Type A predetermined set offields within a file.

Reference Materials Documents thatdescribe key aspects or samples for thecurrent business. These are normallycompiled before the project starts andmay have been used during the Pre-sales cycle.

Regression Test Specific assurance testingon an application system release, afterdefects have been corrected orenhancements have been completed.Regression testing is required to re-validate an application system,confirming that prior validations havenot regressed.

Relational Database Management System(RDBMS) A database managementsystem in which data can be viewedand manipulated in tabular form. Datacan be sorted in any order and tables ofinformation are easily related or joinedto each other.

Relationship 1. What one entity has to dowith another. 2. Any significant way inwhich two things of the same ordifferent type may be associated.

Release A baseline issued from the CMRepository for delivery to adestination. The destination may beinternal to the project environment,such as for testing, or external, such asto the client.

Reporting Database A database used byreporting applications. Reportingdatabases are often duplicates oftransaction databases used to off-loadreport processing from transactiondatabases.

Repository A mechanism for storing anyinformation about the definition of asystem at any point in its life-cycle.Repository services would typically beprovided for extensibility, recovery,integrity, naming standards, and awide variety of other managementfunctions.


Request for Proposal The formalmechanism by which a companyconveys its business requirementsduring the search for a new applicationsystem. Known as the RFP, thisdocument drives the Pre-sales cycleand provides valuable information intothe business requirements definitionprocess of the implementation; see alsoPRE-SALES CYCLE.

Requirement A requirement is a specific,detailed business need which is to becompared with Applicationfunctionality to determine if the needcan be met with the standard Oraclesoftware.

Requirements Scenario A RequirementsScenario is a formal statement ofdetailed business requirements for aProcess, the source of theRequirements, how these requirementswill be satisfied (either the application,manual Procedure, Workarounds, orother application solutions) and whatprototyping steps must be taken toprove the design.

Requirements Workshop A workshop,usually attended by project sponsor,stakeholders, and developers, toprovide a sufficiently detaileddefinition for a developer to commencebuild. The definition will be furtherdefined and refined duringdevelopment, particularly by userreviews; see also USER REVIEW andWORKSHOP.

Research and Development Thesebusiness organizations are responsiblefor the research and productdevelopment functions within acompany; see also BUSINESS

ORGANIZATION TYPE.

Resource Any persons, equipment, ormaterial needed to perform a task(s).

Resource Category see CONSULTING

GRADE LEVEL.

Resource Database A record of theresources available, primarily humanresources, including information aboutthe skills and experiences of theresources.

Revenue Income from services labor fees,training fees, licensed product salesand support fees.

Revision The authorized modification toa configuration item.

Risk The potential of an adversecondition occurring on a project whichwill cause the project to not meetexpectations. A risk requiresmanagement assessment and a strategyfor its mitigation.

Role 1. A skill set for resources assignedto a project. 2. A generic set ofactivities which may be assigned; seealso RESOURCE.


Role-Based Training(RBT) A usertraining approach that focuses ondeveloping curriculum based on OracleApplication responsibilities (i.e., roles)that have been defined and assigned tousers. Application responsibilities tie auser to a menu of functions that can beperformed. An RBT curriculum trainsa group of users on these specificfunctions, using client data andhighlighting client procedures.

Role Placeholder A fictitious resourcename with a resource categoryassigned to replace a role; e.g., Analyst1 - Principal, Analyst 2 - Senior.

Route A variation of a method containingall tasks required in order to deliver aservice; a dependency network.

Row An entry in a table that typicallycorresponds to an instance of some realthing, consisting of a set of values forall mandatory columns and relevantoptional columns. A row is often animplementation of an instance of anentity; see also COLUMN and TABLE.

RTSS see REAL-TIME SUPPORT SYSTEM.

Rule of 3-2-1 A rule of thumb used duringprocess research that stresses theimportance of “walking the floor” andother practical investigation overconference room interviews. It meansthat roughly 3 hours of research arenormally required for every 2 hours ofprocess design and 1 hour of formaldeliverable creation (like creating aBRS using a template or other tool); seealso PROCESS RESEARCH andBUSINESS REQUIREMENTSSCENARIO.

S

Sales Business organizations that handletypical sales functions, includinggenerating quotes and sales orders; seealso BUSINESS ORGANIZATION TYPE.

Sample A statistically-significant subsetselected and analyzed to estimate thecharacteristics of a larger group orpopulation; a set of individuals withinan organization assessed to provideinformation on the preferences,opinions, attitudes, and practices of thegroup they represent.

Scenario A discrete instance of a systemprocess; see also MAPPINGSCENARIO.

Scenario Test Specification A componentof a test script which defines the testexecution -- it is comprised of scenarioinformation, system processinformation, a series of test steps, andtheir associated data profiles.

Schema An information modelimplemented in a database. A schemamay be a logical schema, which willdefine, for example, tables, columns,and constraints, but which may notinclude any optimization. It may be aphysical schema that includesoptimization, for example, tableclustering.

Scope The boundaries of a projectexpressed in some combination ofgeography, organization, applicationsand/or business functions..


Scope Change A change to project scope.A scope change requires an adjustmentto the project workplan, and nearlyalways impacts project cost, scheduleor quality.

Scope Creep The common phenomenonwhere additional requirements areadded after a project has startedwithout reconsidering the resourcing ortimescale of the project. Scope creeparises from the misapprehension thatsuch small additions will not affect theproject schedule.

Scoping Workshop A workshop, usuallyattended by the project sponsor anddevelopers, with the objective ofdefining the boundaries of the scope foran intended project prioritizingrequirements within the scope; see alsoWORKSHOP.

Script 1. A sequence of codedinstructions executed or interpreted bycomputer programs. 2. A prescribedset of steps to follow when testing.

Security Profile A list of role-basedsecurity specifications.

Sequence A database object created suchas a table used to generate unique keys(sequence numbers).

Set of Books A company or group ofcompanies within Oracle Applicationsthat share a common chart of accounts,accounting calendar, and functionalcurrency. This concept is beingsuperseded by the concept of afinancial organization in releases ofOracle Applications starting with 10.6.

Shared Localization A customization toan application product required bymore than one country.

Sign-off Agreement with a client of thesuccessful completion of a project,project phase, or deliverable.

Site A uniquely identifiable geographiclocation or place from which one ormore business organizations may bewholly or partly operating.

Site Based Configuration Specificmodifications or enhancements madeto the company base configuration tosupport site requirements. The sitebase configuration must remainintegrated with the company baseconfiguration to maintain integrity ofthe company base configuration; seealso COMPANY BASE CONFIGURATION.

Site Configuration The definition andmanagement of the site baseconfiguration.

Skills Analysis The collection of datafrom groups and individuals targetedin a specific training situation, todetermine the existence and nature ofany performance gap(s); used in a skillsassessment to determine training needsand develop training goals andobjectives to be translated intolearningware recommendations.

Skills Database see RESOURCES DATABASE.


Software Management SoftwareManagement is composed of severaldifferent processes, that whencombined, perform the totalmanagement of all software in adistributed organization. Theprocesses within Software Managementare configuration management anddistribution management.

Solution A Solution is the resolution ofthe discrepancy between one or moreGaps and one or more standardApplication Functions. A solutionmake take the form of a Procedure,Policy or Customization.

Source Module A physical program unit.An application system’s repository ofsource code is controlled at the sourcemodule level.

SQL see STRUCTURED QUERY LANGUAGE.

Stakeholder A person, group, or businessunit that has a share or an interest in aparticular activity or set of activities.

Standard A set of rules for ensuringquality. Usually, standards are definedfor products deliverables or deliverablecomponents and processes.

State A recognizable or definablecondition that a system or an object canbe in at some point in its life-cycle.

State Transition A valid change of asystem or an object from one state toanother, modeled on a state transitiondiagram; see also STATE.

Store A collection of information ormaterials used in a process.

Storyboard A technique, borrowed fromthe film industry, for describing screendialogues. A storyboard consists of anordered series of pictures illustratingstages of the dialogue. The pictures areannotated with notes about logic anduser input.

Structured Query Language (SQL) TheANSI internationally accepted standardfor relational database systems,covering not only query but also datadefinition, manipulation, security, andsome aspects of referential and entityintegrity; see also ANSI.

Sub-function A business function thathas a parent function.

Sub-process A process performedentirely within another process.

Successor A task that follows another taskand is related to it by a dependencylink; see also PREDECESSOR.

Supporting Module A module that is notitself an entry point in an applicationsystem. Supporting modules aregenerally shared modules that providefunctionality used by multiple primarymodules. They are usually notreferenced independently in user-oriented documentation. All PL/SQLpackages, procedures, and databasetriggers are examples of supportingmodules; see also MODULE and PRIMARY

MODULE.

Support Profile A section of a testscenario that identifies support toolsrequired during execution of the test.

Swim Lane see AGENT CHANNEL.


Synonym 1. A name assigned to a tableor view that may then be used moreconveniently for reference. 2. Analternate name for an entity.

System A named, defined, and interactingcollection of procedures and processes,along with the organized deploymentof people, machines, variousmechanisms, and other resources thatcarry out those procedures andprocesses; see also APPLICATION SYSTEM.

System Architecture A representation ofthe structure of an application systemusually confined to essentials.

System-assisted Performed, eithercompletely or in part, with the aid of anapplication system; see alsoAPPLICATION SYSTEM and MANUAL

FUNCTION.

System Facility A part of an informationsystem that supports an identifiable setof business functions. A facility may bea single module or it may be a wholesub-system.

System Function Something a computersystem does in order to support one ormore business functions; see alsoAPPLICATION SYSTEM and BUSINESS

FUNCTION.

System Interface The mechanism used tocreate connectivity between twosystems.

System Operations Function A systemfunction that serves to support thecontinuing operations of theapplication system. Examples arebackup, recovery, audit; see alsoAPPLICATION SYSTEM, SYSTEM FUNCTION,and SYSTEM OPERATIONS PROCEDURE.

System Operations Procedure A step-by-step indication of the way in which anapplication system executes a systemoperations function. The SystemOperations Guide is a CDM deliverablethat is a compilation of all relevantsystem operations procedures; see alsoAPPLICATION SYSTEM.

System Process The response which anapplication system makes to an event.It comprises the sequential execution ofboth manually executed process stepswhich are instances of manualfunctions and process stepsautomatically executed by a computersystem which are instances of systemfunctions.

System Process Test Model The overallbasis for testing the functionalrequirements of a system. The SystemProcess Test Model contains scenarios,data profiles, and test specifications,but no module references.

System Test A project activity that testsan application system over its completelife-cycle, using scripts and associatingscenario test specifications intochronological sequences.

System Test Flow A set of steps or atransaction sequence used in system orbusiness process testing.


Systems Integration Test A projectactivity that consists of testing relatedapplication systems using sequences orscripts from two or more systemswhich interface.

T

Table A tabular view of data, on arelational database managementsystem, defined by one or morecolumns of data and a primary key. Atable populated by rows of data.

Table Constraint A set of rulesconstraining values in a combination ofone or more columns of a databasetable.

Tablespace A logical portion of adatabase used in allocating storage fortable data and table indexes.

TAR see TECHNICAL ASSISTANCE REQUEST.

Target Application The primary set ofnew application modules that arewithin project scope..

Task A unit of work that results in outputof a single deliverable. The mostelementary unit of work, tasks, providethe core of the work breakdownstructure. Each task produces one, andonly one, deliverable; see also WORK

BREAKDOWN STRUCTURE.

Task Dependency The relationshipbetween two tasks where the start orend date of the successor task isconstrained by the start or end date ofthe predecessor task.

Task Dependency Network A network oftasks and task dependencies whereeach node is a task and each link is atask dependency; see also CRITICAL

PATH METHOD (CPM) NETWORK.

Task Step A step within a task that mayproduce a deliverable component.

Technical Architecture The physicalhardware, network configuration, andsoftware tools that support the systemarchitecture.

Technical Assistance Request (TAR)Oracle’s name for recorded problems.A TAR number is a unique numberassigned by WWSUP to track theproblem.

Technical Platform Architecture Setuprules, guidelines, and principles thatdefine the structure, functions, andrelationships among the hardware,systems software, communications,and network facilities that act as thetechnical foundation for the BusinessProcess, Information, and ApplicationArchitectures. The Technical PlatformArchitecture specifies the common orshared facilities and function of thefacilities needed to support theapplications and data to meet the needsof the business. It supports suchestablished principles as data, devices,and location independence and formalinterfaces.

Technique A specific approach toperforming a task. A methodicalmeans of handling and communicatingcomplex details.

Test Data Profile Specific test data valuesfor performing a test.


Test Environment A combination ofsoftware and possibly hardware thatprovides a stable environment in whichto test newly developed softwarewithout elaborate preparation. A testenvironment might provide test data,data structures, test scripts, automatictest execution, test results recording,and test results analysis.

Test Specification A set of steps or atransaction sequence used in module,module integration, system, systemsintegration, or entity testing.

Test Scenario An instance of an event. Apoint-in-time sample of the businessconditions and processing environmentto be tested. Each scenario may includeusers working in multiple applications,performing online or batch processingbeing performed.

Test Script A document consisting of atest specification, a test data profile andinstructions for performing a test.

Test Sequence A series of test scripts,ordered chronologically, for testing theapplication system over time.

Third-generation Programming Language(3GL) A programming language thatuses procedural definitions to carry outtasks, and typically uses record-by-record processing of data. Procedural3GL language structures includeif....then....else, do....while statements andothers.

Third-party Application Interface Aheterogeneous interface between OracleApplications and the applicationproduct of another vendor or anapplication developed ‘in-house’.

Timebox A project managementtechnique that a fixes the duration andresources of a task, or set of tasks, andforces the scope of the project to beadjusted based on the time available tocomplete the task(s). The contingencyfor under-estimation of the work isprovided by a prioritized list offeatures left out if necessary. Thecontingency for over-estimation isprovided by a prioritized list offeatures that should be added in if timeallows.

Tool Software applications, deliverabletemplates or any other utility suggestedto facilitate the completion of aparticular task.

Top-down Estimate A high-level workeffort estimate. This type of estimate isderived by taking a total projectestimate and dividing it among theproject’s phases, activities, and tasks.

Topical Essay A high-level illustration ofhow to satisfy a business need. Asection of a design document thatspecifies business needs, majorfeatures, terms, and processingoverview.

Traceability The ability to trace anapplication system component to itsbusiness requirement.

Train-the-Trainer An approach towardtraining whereby inside resources takeownership of delivering training totheir peers and associates..

Transaction Database A database usedprimarily by transaction orientedapplications.


Transaction Interface An interface thattransfers transaction data betweensimilar or dissimilar applications.

Trigger 1. A database object that executesPL/SQL code based on a change to adatabase table. 2. An Oracle Formsfunction that is executed based on anevent in the Forms environment.

U

Uncontrolled Document A documentwhich is produced once for informationonly, and is not subject to formalapproval or change control.

Unique Identifier Any combination ofattributes or relationships that serves,in all cases, to uniquely identify anoccurrence of an entity.

Unit Test see MODULE TEST.

Usability That quality of a system thatmakes it easy to learn, easy to use andencourages the user to regard thesystem as a positive help in getting thejob done.

User A person who uses a system toperform a business function.

User Preferences In many circumstancesin computer systems there may bealternate ways a user can influence thebehavior of a utility, user interface, orother system process. Typically set byadjusting values in a set of userpreferences; for example, in a programgenerator, preferences may be set forstyle, performance, user interfacebehavior and code standards.

User Review A meeting at which some ofthe facilities of a system aredemonstrated to and reviewed by user.The objective of a user review is toelicit feedback on which to base futuredevelopment and improvement of thefacilities being reviewed.

Utility A program or system facility thatperforms a useful job for the users. Itdoes not require the user to provideany interaction other than perhapsinitially requesting the utility; see alsoGENERATOR and TRANSFORMER.

Utilization The amount of time a staffmember books to a project accountingsystem; see also BILLABLE UTILIZATION

and NON-BILLABLE UTILIZATION.

V

Vanilla 1. Standard or plain. 2. An icecream flavor.

Variance The difference between aplanned and an actual value; forexample, budgeted hours vs. actualhours.

Version The rendering of a configurationitem which incorporates all of itsrevisions starting from a given point.

Version Control A mechanism to managemultiple revisions of files, documents,programs, applications, or other itemsthat undergo change.

View A means of accessing a subset ofdata in a database.


W

Walkthrough Review of work inprogress, usually taking the form of apresentation by a developer to anaudience of stakeholders or fellowdevelopers who are encouraged tocomment and ask questions. Theobjective is to ensure that work isproceeding in the right direction.

WBS see WORK BREAKDOWN STRUCTURE.

White Box Test A test of all or part of anapplication system that requiresknowledge of the actual code beingtested. Module tests are usually whitebox tests; see also BLACK BOX TEST.

Workaround A way to circumvent asoftware problem.

Work Breakdown Structure (WBS) Anorganization of project tasks into ahierarchy for scheduling and reportingprogress.

Work Effort see EFFORT.

Work Estimate see ESTIMATE.

Work Schedule see PROJECT SCHEDULE.

Workshop 1. A meeting attended byusers and developers to create a plan,specification or other documentationthat can guide the developers in theirdevelopment tasks. 2. A meetingdesigned to facilitate interaction andthe exchange of information betweenindividuals or groups; see alsoREQUIREMENTS WORKSHOP, SCOPING

WORKSHOP, and USER REVIEW.

Workstep A step within a task that mayproduce a deliverable component.

Worldwide Support (WWSUP) Oracle’ssupport Organization.

WWSUP see WORLDWIDE SUPPORT.


AbbreviationsACCEPT acceptanceALT alternativeANAL analysisAPP applicationARCH architectureASSUMP assumptionBKP backupBLD buildBUS businessCERT certificateCOND conditionCONFIG configurationCONSID considerationCORR correctiveCTRL controlCURR currentDB databaseDEFN definitionDELIV deliveryDESC descriptionDESN designDESRD desiredDET detailedDEV developmentDFD dataflow diagramDIAG diagramDM data modelDOCN documentationENTY entityENV environmentEXG existingEXT externalFEAT featureFH function hierarchyFM function modelFOUNDN foundationFUNCN functionFUNCNL functional

FUNCNY functionalityHL high-levelHW hardwareINFO informationINIT initialINT internalINTERF interfaceINTGN integrationLEVL levelLOC locationMATX matrixMDU module data usageMECH mechanismMGMT managementOPERL operationalPERF performancePM process modelPRELIM preliminaryPROC procedurePRODN productionPROJ projectPRTZD prioritizedQLTY qualityRECOV recoveryREQ requirementRESPDNG respondingREVD revisedSPEC specificationST stateSTD standardSTRTGY strategySTRUCT structureSW softwareSYS systemTECHL technicalTRANS transition

Aim - Oracle Application Implementation

Documents

Transcript of Aim - Oracle Application Implementation