aim - oracle application implementation
TRANSCRIPT
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:
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
Tasks and Deliverables..................................................................... 3-13Task Dependencies ........................................................................... 3-16Managing Risks................................................................................. 3-20Tips and Techniques......................................................................... 3-23Estimating.......................................................................................... 3-28Scheduling ......................................................................................... 3-30Staffing............................................................................................... 3-34
C H A P T E R 4 Solution Design........................................................................................ 4-1
Overview.................................................................................................... 4-2
Objectives ............................................................................................ 4-2Critical Success Factors ...................................................................... 4-2Overview Table................................................................................... 4-3Prerequisites........................................................................................ 4-6Processes.............................................................................................. 4-8Key Deliverables ................................................................................. 4-9
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
Tasks and Deliverables..................................................................... 5-13Task Dependencies ........................................................................... 5-16Managing Risks................................................................................. 5-18Tips and Techniques......................................................................... 5-20Estimating.......................................................................................... 5-24Scheduling ......................................................................................... 5-26Staffing............................................................................................... 5-28
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
Objectives ............................................................................................ 7-2Critical Success Factors ...................................................................... 7-2Overview Table................................................................................... 7-3Prerequisites........................................................................................ 7-4Processes.............................................................................................. 7-5Key Deliverables ................................................................................. 7-5
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.
Oracle Method Introduction to AIM 1 - 3
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.
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-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
1 - 4 Introduction to AIM AIM Method Handbook
• Training
• Production Migration
Business Requirements Definition
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
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.
Application and Technical Architecture
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
Oracle Method Introduction to AIM 1 - 5
• 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
1 - 6 Introduction to AIM AIM Method Handbook
• 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
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
Oracle Method Introduction to AIM 1 - 7
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.
Business System Testing
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
1 - 8 Introduction to AIM AIM Method Handbook
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
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
Oracle Method Introduction to AIM 1 - 9
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.
1 - 10 Introduction to AIM AIM Method Handbook
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
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-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.
Oracle Method Introduction to AIM 1 - 11
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.
1 - 12 Introduction to AIM AIM Method Handbook
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.
Oracle Method Introduction to AIM 1 - 13
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.
1 - 14 Introduction to AIM AIM Method Handbook
If multiple deployment exists, Production will occur at different timesfor the various geographical sites and/or business units.
Oracle Method Introduction to AIM 1 - 15
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
1 - 16 Introduction to AIM AIM Method Handbook
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
Oracle Method Introduction to AIM 1 - 17
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
1 - 18 Introduction to AIM AIM Method Handbook
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.
Oracle Method Introduction to AIM 1 - 19
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.
1 - 20 Introduction to AIM AIM Method Handbook
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
Oracle Method Introduction to AIM 1 - 21
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.
1 - 22 Introduction to AIM AIM Method Handbook
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.
Oracle Method Introduction to AIM 1 - 23
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.
1 - 24 Introduction to AIM AIM Method Handbook
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.
Oracle Method Introduction to AIM 1 - 25
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)
Define FutureProcess and
Function Model(Payment
Processes)
CurrentBusinessBaseline
(ProcurementProcesses)
CurrentBusinessBaseline(Payment
Processes)
Define FutureProcess and
Function Model(ReceivingProcesses)
Defining Business
Scenarios
Define BusinessRequirements
Scenarios(ProcurementProcesses)
Define BusinessRequirements
Scenarios(ReceivingProcesses)
Define BusinessRequirements
Scenarios(Payment
Processes)
Map BusinessRequirements(ProcurementProcesses)
Map BusinessRequirements
(ReceivingProcesses)
Map BusinessRequirements
(PaymentProcesses)
Test BusinessSolutions
(ProcurementProcesses)
Test BusinessSolutions(ReceivingProcesses)
Test BusinessSolutions(Payment
Processes)
Figure 1-4 Repetitive Implementation Process Task Cycle Example
1 - 26 Introduction to AIM AIM Method Handbook
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.
Oracle Method Introduction to AIM 1 - 27
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.
1 - 28 Introduction to AIM AIM Method Handbook
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
Oracle Method Introduction to AIM 1 - 29
• 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
1 - 30 Introduction to AIM AIM Method Handbook
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.
Oracle Method Introduction to AIM 1 - 31
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:
1 - 32 Introduction to AIM AIM Method Handbook
• 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.
Oracle Method Introduction to AIM 1 - 33
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.
1 - 34 Introduction to AIM AIM Method Handbook
• 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.
Oracle Method Introduction to AIM 1 - 35
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.
Definition OperationsAnalysis
SolutionDesign
Build ProductionTransition
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 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.
Critical Success Factors
The critical success factors for Definition follow:
• clear definition of the business objectives to be addressed
• active participation by key management and knowledgeable 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
Oracle Method Definition 2 - 3
Overview Table
This table illustrates the prerequisites, processes, and key deliverablesfor Definition.
Process Prerequisites Key Deliverables
Business RequirementsDefinition
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
2 - 4 Definition AIM Method Handbook
Process Prerequisites Key Deliverables
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
Oracle Method Definition 2 - 5
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
2 - 6 Definition AIM Method Handbook
Processes
The processes used in this phase follow:
Business Requirements Definition
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.
Application and Technical Architecture
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.
Module Design and Build
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.
Oracle Method Definition 2 - 7
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.
2 - 8 Definition AIM Method Handbook
Deliverable Description
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.
Oracle Method Definition 2 - 9
Deliverable Description
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
2 - 10 Definition AIM Method Handbook
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
Oracle Method Definition 2 - 11
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
2 - 12 Definition AIM Method Handbook
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
Oracle Method Definition 2 - 13
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.)
2 - 14 Definition AIM Method Handbook
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.
Oracle Method Definition 2 - 15
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.
2 - 16 Definition AIM Method Handbook
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.
Oracle Method Definition 2 - 17
Business Requirements Definition
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.
Application and Technical Architecture
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
2 - 18 Definition AIM Method Handbook
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.
Module Design and Build
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.
Oracle Method Definition 2 - 19
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
2 - 20 Definition AIM Method Handbook
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.
Oracle Method Definition 2 - 21
This page intentionally left blank.
2 - 22 Definition AIM Method Handbook
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
Oracle Method Definition 2 - 23
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.)
2 - 24 Definition AIM Method Handbook
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.
Business Requirements Definition
An organization may want to implement the applications as quickly aspossible with minimal customizations and, if necessary, change the way
Oracle Method Definition 2 - 25
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.
Application and Technical Architecture
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
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?
2 - 26 Definition AIM Method Handbook
• 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)?
Oracle Method Definition 2 - 27
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
2 - 28 Definition AIM Method Handbook
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.
Business Requirements Definition
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.
Application and Technical Architecture
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.
Module Design and Build
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
Oracle Method Definition 2 - 29
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.
2 - 30 Definition AIM Method Handbook
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
Build ProductionTransition
Business Requirements Definition
Business Requirements Mapping
Module Design & Build
Documentation
Performance Testing
Training
Production Migration
Business System Testing
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.
Critical Success Factors
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
Oracle Method Operations Analysis 3 - 3
• 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.
Process Prerequisites Key Deliverables
Application andTechnical Architecture
Architectural Requirements
Architectural Strategy
Business Volume Requirements
Conceptual Architecture
Future Applications Deployment
Process and Mapping Summary
System Availability Strategy
Technical Architecture Baseline
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
3 - 4 Operations Analysis AIM Method Handbook
Process Prerequisites Key Deliverables
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
Oracle Method Operations Analysis 3 - 5
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
Application and TechnicalArchitecture
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 Standards andProcedures
Documentation
Documentation Requirements Documentation
Education and Training Plan Training
Financial and Operating Structure Business RequirementsDefinition
3 - 6 Operations Analysis AIM Method Handbook
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
The processes used in this phase follow:
Business Requirements Definition
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.
Business Requirements Mapping
Map business requirements to application functionality. Prove theviability and feasibility of proposed business processes and theirintegration. Map information flow and access needs by organization.
Oracle Method Operations Analysis 3 - 7
Application and Technical Architecture
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.
Production Migration
Prepare a transition strategy for migrating the company, systems, andpeople into the new enterprise system.
3 - 8 Operations Analysis AIM Method Handbook
Key Deliverables
The key deliverables of this phase follow:
Deliverable Description
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.
Oracle Method Operations Analysis 3 - 9
Deliverable Description
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.
3 - 10 Operations Analysis AIM Method Handbook
Deliverable Description
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.
Oracle Method Operations Analysis 3 - 11
Deliverable Description
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.
3 - 12 Operations Analysis AIM Method Handbook
Deliverable Description
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
Oracle Method Operations Analysis 3 - 13
Approach
This section describes the approach for Operations Analysis.
Tasks and Deliverables
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
3 - 14 Operations Analysis AIM Method Handbook
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
Oracle Method Operations Analysis 3 - 15
This page intentionally left blank.
3 - 16 Operations Analysis AIM Method Handbook
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
Map BusinessRequirements
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
Oracle Method Operations Analysis 3 - 17
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.)
3 - 18 Operations Analysis AIM Method Handbook
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
Figure 3-2 Operations Analysis Phase Task Dependencies (cont.)
Oracle Method Operations Analysis 3 - 19
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
Figure 3-2 Operations Analysis Phase Task Dependencies (cont.)
3 - 20 Operations Analysis AIM Method Handbook
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.
Oracle Method Operations Analysis 3 - 21
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.
3 - 22 Operations Analysis AIM Method Handbook
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
Oracle Method Operations Analysis 3 - 23
Tips and Techniques
This section provides tips and techniques for managing OperationsAnalysis. In addition, advice and comments on each process areincluded.
Business Requirements Definition
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.
Business Requirements Mapping
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.
3 - 24 Operations Analysis AIM Method Handbook
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.
Application and Technical Architecture
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
Oracle Method Operations Analysis 3 - 25
technical infrastructure. Even if the subprojects components arepurchased as pre-built packaged applications, significant integrationwork may be necessary to integrate them.
Module Design and Build
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.
3 - 26 Operations Analysis AIM Method Handbook
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.
Production Migration
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.
Oracle Method Operations Analysis 3 - 27
This page intentionally left blank.
3 - 28 Operations Analysis AIM Method Handbook
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
Project Management 13.2%PJM Manage Phase 13.2%
CONT Contingency 0.0%
100.0%
Table 3-6 Operations Analysis Phase Estimating
Oracle Method Operations Analysis 3 - 29
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.)
3 - 30 Operations Analysis AIM Method Handbook
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
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.
Business Requirements Definition
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.
Business Requirements Mapping
Schedule slippage for this process is often caused by:
Oracle Method Operations Analysis 3 - 31
• 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.
Application and Technical Architecture
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.
Module Design and Build
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.
3 - 32 Operations Analysis AIM Method Handbook
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?
Oracle Method Operations Analysis 3 - 33
Production Migration
The most important consideration is whether a multiple deploymentapproach will be used, since Production Migration must occur for eachdeployment.
3 - 34 Operations Analysis AIM Method Handbook
Staffing
This diagram illustrates a typical project organization for OperationsAnalysis.
Operations Analysis Organization
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
Team Members
Team Lead
Technical Architecture &Performance Testing
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
Oracle Method Operations Analysis 3 - 35
Staffing Suggestions
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.
Business Requirements Definition
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.
3 - 36 Operations Analysis AIM Method Handbook
Business Requirements Mapping
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.
Application and Technical Architecture
This process must be staffed by an experienced technical architect whois knowledgeable in hardware, network, and operating systemconsiderations.
Module Design and Build
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.
Oracle Method Operations Analysis 3 - 37
Training
By the end of this phase all major decisions regarding trainingdevelopment and delivery should be made.
Production Migration
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.
Definition OperationsAnalysis
SolutionDesign
Build ProductionTransition
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 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.
Critical Success Factors
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
Oracle Method Solution Design 4 - 3
• 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.
Process Prerequisites Key Deliverables
Business RequirementsMapping
Business Requirements MappingForm
Business Requirements Scenario
Financial and Operations Structure
Information Access Model
Applications Setup Document
Process Narrative
Security Profiles
4 - 4 Solution Design AIM Method Handbook
Process Prerequisites Key Deliverables
Application and TechnicalArchitecture
Architectural Requirements
Architectural Strategy
Business Volume Requirements
Conceptual Architecture
Future Applications Deployment
Process and Mapping Summary
System Availability Strategy
Technical Architecture Baseline
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 and Build Business Data Mapping Form
Customization Strategy
Master Report Tracking List
Solution Document
Build Standards
Design Standards
Database Extension Design
Module Function Design
Module Technical Design
Data Conversion Conversion Scope, Objectives, andApproach
Conversion Standards
Conversion Strategy
Current Business Baseline
Conversion Environment
Conversion Data Mapping
Conversion Program Design
Conversion Test Plan Procedures
Manual Conversion Strategy
Oracle Method Solution Design 4 - 5
Process Prerequisites Key Deliverables
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
Education and Training Plan
Performance Test Strategy
Transition Strategy
Detailed Transition andContingency Plan
Production Support Infrastructure
Table 4-1 Solution Design Phase Overview Table
4 - 6 Solution Design AIM Method Handbook
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
Architectural Strategy Application and TechnicalArchitecture
Business Data Mapping Form Business RequirementsMapping
Business Requirements MappingForm
Business RequirementsDefinition
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
Current Business Baseline Business RequirementsDefinition
Customization Strategy Module Design and Build
Documentation Prototypes andTemplates
Documentation
Oracle Method Solution Design 4 - 7
Prerequisite Source
Documentation Standards andProcedures
Documentation
Documentation Environment Documentation
Documentation Requirements Documentation
Education and Training Plan Training
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 Strategy 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
4 - 8 Solution Design AIM Method Handbook
Prerequisite Source
Technical Architecture Baseline Application and TechnicalArchitecture
Transition Strategy Production Migration
Table 4-2 Solution Design Phase Prerequisites
Processes
The processes used in this phase follow:
Business Requirements Mapping
Develop process narratives documentation that will serve as input intothe creation of training materials and user procedures. Finalizeapplication setups, security profiles, parameters, and user securitystructures.
Application and Technical Architecture
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.
Module Design and Build
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.
Oracle Method Solution Design 4 - 9
Business System Testing
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.
Production Migration
Develop the production support infrastructure, as well as contingencyand transition plans.
Key Deliverables
The key deliverables of this phase follow:
Deliverable Description
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.
4 - 10 Solution Design AIM Method Handbook
Deliverable Description
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.
Hardware and NetworkArchitecture
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.
Oracle Method Solution Design 4 - 11
Deliverable Description
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.
4 - 12 Solution Design AIM Method Handbook
Deliverable Description
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
Oracle Method Solution Design 4 - 13
Approach
This section describes the approach for Solution Design.
Tasks and Deliverables
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
4 - 14 Solution Design AIM Method Handbook
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
Oracle Method Solution Design 4 - 15
This page intentionally left blank.
4 - 16 Solution Design AIM Method Handbook
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
Oracle Method Solution Design 4 - 17
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.)
4 - 18 Solution Design AIM Method Handbook
TE.010
Develop TestStrategyTE.010
PM.020Design Production
SupportInfrastructure
PM.020
BUSINESS SYSTEM
TESTING
DOCUMENTATION
SolutionDesign
PERFORMANCETESTING
TRAINING
PRODUCTIONMIGRATION
A B
Figure 4-2 Solution Design Phase Task Dependencies (cont.)
Oracle Method Solution Design 4 - 19
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
Figure 4-2 Solution Design Phase Task Dependencies (cont.)
4 - 20 Solution Design AIM Method Handbook
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.
Oracle Method Solution Design 4 - 21
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.
4 - 22 Solution Design AIM Method Handbook
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
Oracle Method Solution Design 4 - 23
Tips and Techniques
This section provides tips and techniques for managing Solution Design.In addition, advice and comments on each process are included.
Business Requirements Mapping
Process Narratives are based on business process designs and 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.
Application and Technical Architecture
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
4 - 24 Solution Design AIM Method Handbook
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.
Module Design and Build
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.
Oracle Method Solution Design 4 - 25
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
Business System Testing
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
4 - 26 Solution Design AIM Method Handbook
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
Oracle Method Solution Design 4 - 27
users with a thorough introduction to their new responsibilities andprocedures.
Production Migration
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.
4 - 28 Solution Design AIM Method Handbook
Estimating
The following table indicates the typical percentage of effort required byeach task by role.
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
Oracle Method Solution Design 4 - 29
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.)
4 - 30 Solution Design AIM Method Handbook
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
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
Oracle Method Solution Design 4 - 31
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.
Module Design and Build
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
4 - 32 Solution Design AIM Method Handbook
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.
Production Migration
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.
Oracle Method Solution Design 4 - 33
• 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.
4 - 34 Solution Design AIM Method Handbook
Staffing
This diagram illustrates a typical project organization for SolutionDesign.
Solution Design Phase Organization
Project ManagementSupport Team
Administrative Assistant/Project Librarian
Functional Analysts
Functional Lead
Business Function(A)
Functional Analysts
Functional Lead
Business Function(B)
Business ProcessIntegration
Business FunctionSpecialists
Team Members
Team Leader
Custom Software Design& Build
Team Members
Team Lead
Technical Architecture &Performance Testing
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
Oracle Method Solution Design 4 - 35
Staffing Suggestions
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.
Business Requirements Mapping
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.
Application and Technical Architecture
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.
Module Design and Build
Experienced staff should develop the functional design specifications.Technical specifications may be developed by less experienced staff andreviewed by functional design developers.
4 - 36 Solution Design AIM Method Handbook
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
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
Oracle Method Solution Design 4 - 37
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.
Production Migration
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.
Definition OperationsAnalysis
SolutionDesign
Build ProductionTransition
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 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.
Critical Success Factors
The critical success factors of Build follow:
Oracle Method Build 5 - 3
• clear understanding of the business objectives being addressed bythe project
• effective participation by executive and user management
• sufficient time and resources
• accurate and complete design documentation
• a productive Build environment
• effective project management
• a productive team with appropriate skills
Overview Table
This table illustrates the prerequisites, processes, and key deliverablesfor Build.
Process Prerequisites Key Deliverables
Module Design and Build Application Setup Document
Approve Designs
Build Standards
Database Extension Design
Link Test Scripts
Module Functional Design
Module Technical Design
Physical Resource Plan
Unit Test Scripts
Custom Database Objects
Develop Environment
Installation Routines
Module Source Code
5 - 4 Build AIM Method Handbook
Process Prerequisites Key Deliverables
Data Conversion Conversion Data Mapping
Conversion Environment
Conversion Program Design
Conversion Testing Plans
Current Business Baseline
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
Oracle Method Build 5 - 5
Process Prerequisites Key Deliverables
Business System Testing Business Requirements Scenario
Process Narrative
Production Support Infrastructure
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
5 - 6 Build AIM Method Handbook
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
Current Business Baseline Business RequirementsDefinition
Database Extension Designs Module Design and Build
Design Standards Module Design and Build
Detailed Transition and ContingencyPlan
Production Migration
Documentation Prototypes andTemplates
Documentation
Documentation Standards andProcedures
Documentation
Documentation Requirements Documentation
Oracle Method Build 5 - 7
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
Application and TechnicalArchitecture
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
5 - 8 Build AIM Method Handbook
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
The processes used in this phase follow:
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.
Oracle Method Build 5 - 9
Business System Testing
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
The key deliverables of this phase follow:
Deliverable Description
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.
5 - 10 Build AIM Method Handbook
Deliverable Description
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.
Oracle Method Build 5 - 11
Deliverable Description
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.
5 - 12 Build AIM Method Handbook
Deliverable Description
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
Oracle Method Build 5 - 13
Approach
This section describes the approach for Build.
Tasks and Deliverables
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
5 - 14 Build AIM Method Handbook
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
Oracle Method Build 5 - 15
This page intentionally left blank.
5 - 16 Build AIM Method Handbook
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
Oracle Method Build 5 - 17
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.)
5 - 18 Build AIM Method Handbook
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.
Oracle Method Build 5 - 19
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
5 - 20 Build AIM Method Handbook
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
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
Oracle Method Build 5 - 21
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.
Business System Testing
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
5 - 22 Build AIM Method Handbook
• 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.
Oracle Method Build 5 - 23
This page intentionally left blank.
5 - 24 Build AIM Method Handbook
Estimating
The following table indicates the typical percentage of effort required byeach task by role.
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
Project Management 13.2%PJM Manage Phase 13.2%
CONT Contingency 0.0%
100.0%
Table 5-6 Build Phase Estimating
Oracle Method Build 5 - 25
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.)
5 - 26 Build AIM Method Handbook
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
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.
Module Design and Build
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.
Oracle Method Build 5 - 27
Business Systems Testing
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.
5 - 28 Build AIM Method Handbook
Staffing
This diagram illustrates a typical project organization for Build.
Build Organization
Project ManagementSupport Team
Administrative Assistant/Project Librarian
Business FunctionSpecialists
Oracle ApplicationsSpecialists
Team Members
Team Lead
Custom Software Design& Build
Team Members
Team Lead
Technical Architecture &Performance Testing
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
Oracle Method Build 5 - 29
Staffing Suggestions
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.
Module Design and Build
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.
5 - 30 Build AIM Method Handbook
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.
Business System Testing
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.
Definition OperationsAnalysis
SolutionDesign
Build ProductionTransition
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 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.
Critical Success Factors
The critical success factors of Transition follow:
• clear understanding of the business objectives
• effective participation by business management
• sufficient time and resources
• sufficient technical and application architecture
• available and committed support staff to implement the newsolutions
• committed user involvement and ownership
• successful performance acceptance testing
• successful completion of production readiness plan
• effective training
Oracle Method Transition 6 - 3
Overview Table
This table illustrates the prerequisites, processes, and key deliverablesfor Transition.
Process Prerequisites Key Deliverables
Data Conversion Conversion Program Design
Detailed Transaction andContingency Plan
Conversion Environment
Performance Testing Results
Validation Tested ConversionPrograms
Converted and Verified Data
Installed Conversion Software
Training Application Setup Document
Education and Training Plan
User Training Materials
Trained Users
User Training Environment
6 - 4 Transition AIM Method Handbook
Process Prerequisites Key Deliverables
Production Migration Hardware and NetworkArchitecture
Installation Routines
Integrated Tested Systems
Logical Application andDatabase Architecture
Online Help Text
Physical Database Architecture
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
Oracle Method Transition 6 - 5
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
Detailed Transaction andContingency Plan
Production Migration
Education and Training Plan Training
Hardware and Network Architecture Application and TechnicalArchitecture
Installation Routines Application and TechnicalArchitecture
Logic Application and DatabaseArchitecture
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
6 - 6 Transition AIM Method Handbook
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
Validation Tested ConversionPrograms
Data Conversion
Table 6-2 Transition Phase Prerequisites
Processes
The processes used in this phase follow:
Data Conversion
Install the data conversion software in the production environment,convert the legacy data to the Oracle Applications, and verify dataaccuracy.
Business System Testing
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.
Oracle Method Transition 6 - 7
Production Migration
Prepare the production environment, including entering applicationsetups. Implement the support infrastructure, assess productionreadiness, and execute production cutover.
Key Deliverables
The key deliverables of this phase follow:
Deliverable Description
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.
6 - 8 Transition AIM Method Handbook
Deliverable Description
Configured Applications Application ready for productionuse.
User Training Environment Environment to be used in trainingusers.
Table 6-3 Transition Phase Key Deliverables
Oracle Method Transition 6 - 9
Approach
This section describes the approach for Transition.
Tasks and Deliverables
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
6 - 10 Transition AIM Method Handbook
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
Oracle Method Transition 6 - 11
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.)
6 - 12 Transition AIM Method Handbook
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
Oracle Method Transition 6 - 13
Tips and Techniques
This section provides tips and techniques for managing Transition. Inaddition, advice and comments on each process are included.
Module Design and Build
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.
Business System Testing
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
6 - 14 Transition AIM Method Handbook
with the application will encourage confidence in their ability to use thesystem.
Production Migration
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.
Oracle Method Transition 6 - 15
This page intentionally left blank.
6 - 16 Transition AIM Method Handbook
Estimating
The following table indicates the typical percentage of effort required byeach task by role.
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
Oracle Method Transition 6 - 17
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.)
6 - 18 Transition AIM Method Handbook
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
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.
Oracle Method Transition 6 - 19
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.
Business System Testing
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
Production Migration
The production migration process will be repeated for each deploymentin a project with multiple deployment phases.
6 - 20 Transition AIM Method Handbook
Staffing
This diagram illustrates a typical project organization for Transition.
Transition Organization
Project ManagementSupport Team
Administrative Assistant/Project Librarian
Applications
Data Conversion
Data Base
Technical Architecture &Performance Testing
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
Oracle Method Transition 6 - 21
Staffing Suggestions
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.
Business Systems Testing
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.
6 - 22 Transition AIM Method Handbook
Production Migration
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.
Definition OperationsAnalysis
SolutionDesign
Build ProductionTransition
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 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.
Critical Success Factors
The critical success factors for Production follow:
• effective change control tools and procedures
• accurate compilation of volumes, transaction histories, and otherperformance drivers
• sufficient time and resources
• adequate staff and expertise
• effective participation by business management and users
• effective technical and application architecture
Oracle Method Production 7 - 3
Overview Table
This table illustrates the prerequisites, processes, and key deliverablesfor Production.
Process Prerequisites Key Deliverables
Production Migration Application FunctionalArchitecture
Application Security Architecture
Architectural Strategy
Architecture Scope and Objectives
Conversion Scope and Objectives
Data Conversion Strategy
Detailed Transaction andContingency Plan
Performance Risk Assessment
performance Testing Strategy
Process Narrative
Production System
System Capacity Plan
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
7 - 4 Production AIM Method Handbook
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
Architectural Strategy 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
Production Migration
Performance Risk Assessment Application and TechnicalArchitecture
Performance Testing Strategy Performance Testing
Process Narrative Business RequirementsMapping
Production System Production Migration
Oracle Method Production 7 - 5
Prerequisite Source
System Capacity Plan Application and TechnicalArchitecture
System Management Guide Documentation
Transition Strategy Production Migration
Table 7-2 Production Phase Prerequisites
Processes
The processes used in this phase follow:
Production Migration
Audit, refine, and maintain the production system, propose the futurebusiness and technical direction for the company, and decommissionthe former system.
Key Deliverables
The key deliverables of this phase follow:
Deliverable Description
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.
7 - 6 Production AIM Method Handbook
Deliverable Description
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
Oracle Method Production 7 - 7
Approach
This section describes the approach for Production.
Tasks and Deliverables
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
7 - 8 Production AIM Method Handbook
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
Oracle Method Production 7 - 9
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.
Module Design and Build
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.
7 - 10 Production AIM Method Handbook
• 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.
Production Migration
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.
Oracle Method Production 7 - 11
This page intentionally left blank.
7 - 12 Production AIM Method Handbook
Estimating
The following table indicates the typical percentage of effort required byeach task by role.
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
Project Management 22.2%PJM Manage Phase 22.2%
CONT Contingency 0.0%
100.0%
Table 7-6 Production Phase Estimating
Oracle Method Production 7 - 13
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.)
7 - 14 Production AIM Method Handbook
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
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.
Oracle Method Production 7 - 15
• 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.
7 - 16 Production AIM Method Handbook
Staffing
This diagram illustrates a typical project organization for Production.
Production Organization
Administrative Assistant/Project Librarian
Team Members
Team Lead
Technical Support
Team Members
Team Lead
Training andTransition Support
Project Management
Figure 7-3 Staffing Chart for Production
Staffing Suggestions
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.
Oracle Method Production 7 - 17
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
ID Task Name Deliverable
Oracle Method AIM Work Breakdown Structure A - 3
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
ID Task Name Deliverable
A - 4 AIM Work Breakdown Structure AIM Method Handbook
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
ID Task Name Deliverable
Oracle Method AIM Work Breakdown Structure A - 5
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
ID Task Name Deliverable
A - 6 AIM Work Breakdown Structure AIM Method Handbook
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
ID Task Name Deliverable
Oracle Method AIM Work Breakdown Structure A - 7
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
ID Task Name Deliverable
A - 8 AIM Work Breakdown Structure AIM Method Handbook
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
ID Task Name Deliverable
Oracle Method AIM Work Breakdown Structure A - 9
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.
Oracle Method AIM Roles B - 3
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.
B - 4 AIM Roles AIM Method Handbook
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
Oracle Method AIM Roles B - 5
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
B - 6 AIM Roles AIM Method Handbook
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.
Oracle Method AIM Roles B - 7
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.
B - 8 AIM Roles AIM Method Handbook
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).
Oracle Method AIM Roles B - 9
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.
B - 10 AIM Roles AIM Method Handbook
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
Oracle Method AIM Roles B - 11
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
Role Name ID Task Name %
Oracle Method Role Usages C - 3
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
Role Name ID Task Name %
C - 4 Role Usages AIM Method Handbook
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 *
Role Name ID Task Name %
Oracle Method Role Usages C - 5
B.BR.090 Confirm Integrated Business Solutions * B.BR.100 Create Process Narratives * B.MD.020 Define and Estimate Custom
Extensions*
B.RD.080 Determine Audit and ControlRequirements
*
B.RD.090 Identify Business AvailabilityRequirements
*
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
Role Name ID Task Name %
C - 6 Role Usages AIM Method Handbook
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
Database Architecture10
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 *
Role Name ID Task Name %
Oracle Method Role Usages C - 7
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.PM.030 Develop Detailed Transition andContingency Plan
*
C.TA.150 Design Physical Database Architecture * C.TA.160 Design Hardware and Network
Architecture*
C.TA.170 Develop System Capacity Plan * C.TA.190 Design System Management
Procedures*
D.MD.090 Prepare Development Environment * E.CV.130 Install Conversion Software * E.CV.140 Convert and Verify Data *
Role Name ID Task Name %
C - 8 Role Usages AIM Method Handbook
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
Role Name ID Task Name %
Oracle Method Role Usages C - 9
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
C.TA.170 Develop System Capacity Plan 10 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.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
Role Name ID Task Name %
C - 10 Role Usages AIM Method Handbook
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
Role Name ID Task Name %
Oracle Method Role Usages C - 11
C.PM.030 Develop Detailed Transition andContingency Plan
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
C.TA.170 Develop System Capacity Plan 20 C.TA.190 Design System Management
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
Role Name ID Task Name %
C - 12 Role Usages AIM Method Handbook
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
Role Name ID Task Name %
Oracle Method Role Usages C - 13
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
Role Name ID Task Name %
C - 14 Role Usages AIM Method Handbook
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
B.RD.090 Identify Business AvailabilityRequirements
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
Role Name ID Task Name %
Oracle Method Role Usages C - 15
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
Database Architecture30
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
Role Name ID Task Name %
C - 16 Role Usages AIM Method Handbook
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
Role Name ID Task Name %
Oracle Method Role Usages C - 17
A.TR.050 Prepare Project Team Training 25 B.TR.060 Train Project Team 90 C.TR.070 Develop User Training Materials 25 E.TR.080 Prepare User Training Environment 10 E.TR.090 Train Users 90
User A.CV.010 Define Conversion Scope, Objectives,and Approach
*
A.CV.020 Prepare Conversion Strategy * A.DO.010 Prepare Glossary * A.RD.020 Conduct Current Business Baseline * A.RD.030 Develop Future Process Model * A.RD.040 Develop Future Business Function
Model*
A.RD.060 Gather Business Volumes * B.BR.040 Conduct Integration Fit Analysis * B.BR.050 Develop Information Flow Model * B.BR.060 Develop Information Access Model * B.BR.070 Conduct Reporting Fit Analysis * B.DO.050 Produce Documentation Prototypes
and Templates*
B.PT.030 Identify Performance Test Scenarios * B.RD.070 Create Business Requirements
Scenarios*
B.RD.080 Determine Audit and ControlRequirements
*
B.RD.090 Identify Business AvailabilityRequirements
*
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.
Oracle Method AIM 2.0 Data Model D - 3
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
D - 4 AIM 2.0 Data Model AIM Method Handbook
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.
Oracle Method AIM 2.0 Data Model D - 5
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.
D - 6 AIM 2.0 Data Model AIM Method Handbook
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.
Oracle Method AIM 2.0 Data Model D - 7
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.
D - 8 AIM 2.0 Data Model AIM Method Handbook
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.
Oracle Method AIM 2.0 Data Model D - 9
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.
D - 10 AIM 2.0 Data Model AIM Method Handbook
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.
Oracle Method AIM 2.0 Data Model D - 11
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.
D - 12 AIM 2.0 Data Model AIM Method Handbook
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
Oracle Method AIM 2.0 Data Model D - 13
• 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.
D - 14 AIM 2.0 Data Model AIM Method Handbook
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.
Oracle Method AIM 2.0 Data Model D - 15
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
D - 16 AIM 2.0 Data Model AIM Method Handbook
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.
Oracle Method AIM 2.0 Data Model D - 17
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.
Oracle Method Glossary G - 3
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.
G - 4 Glossary AIM Method Handbook
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.
Oracle Method Glossary G - 5
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.
G - 6 Glossary AIM Method Handbook
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.
Oracle Method Glossary G - 7
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.
G - 8 Glossary AIM Method Handbook
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.
Oracle Method Glossary G - 9
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.
G - 10 Glossary AIM Method Handbook
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.
Oracle Method Glossary G - 11
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.
G - 12 Glossary AIM Method Handbook
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.
Oracle Method Glossary G - 13
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.
G - 14 Glossary AIM Method Handbook
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.
Oracle Method Glossary G - 15
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.
G - 16 Glossary AIM Method Handbook
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.
Oracle Method Glossary G - 17
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.
G - 18 Glossary AIM Method Handbook
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.
Oracle Method Glossary G - 19
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.
G - 20 Glossary AIM Method Handbook
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.
Oracle Method Glossary G - 21
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.
G - 22 Glossary AIM Method Handbook
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.
Oracle Method Glossary G - 23
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.
G - 24 Glossary AIM Method Handbook
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.
Oracle Method Glossary G - 25
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.
G - 26 Glossary AIM Method Handbook
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.
Oracle Method Glossary G - 27
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.
G - 28 Glossary AIM Method Handbook
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.
Oracle Method Glossary G - 29
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.
G - 30 Glossary AIM Method Handbook
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.
Oracle Method Glossary G - 31
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.
G - 32 Glossary AIM Method Handbook
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.
Oracle Method Glossary G - 33
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.
G - 34 Glossary AIM Method Handbook
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..
Oracle Method Glossary G - 35
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.
G - 36 Glossary AIM Method Handbook
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.
Oracle Method Glossary G - 37
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.
G - 38 Glossary AIM Method Handbook
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.
Oracle Method Glossary G - 39
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.
G - 40 Glossary AIM Method Handbook
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.
Oracle Method Glossary G - 41
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.
G - 42 Glossary AIM Method Handbook
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