11

A Quick Tour of CDMA Quick Tour of CDM

22

Building Systems that WorkBuilding Systems that Work

I need a recipe that tells me

… what to do

…and a tool that automates the

process.

…and how to do it

33

An Approach to Building SystemsAn Approach to Building Systems

Tools

Method

What do you do?What do you do? How do you do it?How do you do it?

Can you automate it?Can you automate it?

CDM

Techniques

• Process modeling

• Entity modeling

• Cross checking

. . .

44

What is CDM?What is CDM?

The Oracle Custom Development Method (CDM) is Oracle’s full lifecycle method for delivering custom computer application solutions.

It is a roadmap for successful systems development.

CDM includes the CDM Standards and Guidelines library, containing detailed guidelines and standards for the use of Oracle Tools in custom development engagements.

The Oracle Custom Development Method (CDM) is Oracle’s full lifecycle method for delivering custom computer application solutions.

It is a roadmap for successful systems development.

CDM includes the CDM Standards and Guidelines library, containing detailed guidelines and standards for the use of Oracle Tools in custom development engagements.

55

What Do You Do?What Do You Do?

AnalyzeAnalyze

Browser:

http://

HollywoodHollywood

XX

Action Edit Block Filed

++Customers:

DesignDesign

BuildBuild

Req.

66

CDM is part of Oracle Method — Oracle’s methodology for defining and delivering information systems solutions that add business value.CDM is part of Oracle Method — Oracle’s methodology for defining and delivering information systems solutions that add business value.

77

Why Use CDM?Why Use CDM?

•No Guesswork

•Best Practices — Globally

•You Know What You Are Getting

•Built-In Flexibility

•Saves Time

•Increases Quality

•No Guesswork

•Best Practices — Globally

•You Know What You Are Getting

•Built-In Flexibility

•Saves Time

•Increases Quality

88

Essential TerminologyEssential Terminology

Deliverable

A deliverable is a tangible outcome that is produced during the course of a project. Each deliverable in CDM has a specific name and ID, and is measurable for QA. Most deliverables are prerequisites for other tasks.

Task

A task is a unit of work that results in the output of a single deliverable. Tasks are the most elementary unit of work that one would put into a project plan — they provide the basis of the work breakdown structure.

Deliverable

A deliverable is a tangible outcome that is produced during the course of a project. Each deliverable in CDM has a specific name and ID, and is measurable for QA. Most deliverables are prerequisites for other tasks.

Task

A task is a unit of work that results in the output of a single deliverable. Tasks are the most elementary unit of work that one would put into a project plan — they provide the basis of the work breakdown structure.

99

Essential Terminology (Cont)Essential Terminology (Cont)

Dependency

A dependency between two tasks indicates that the latter task needs something from the former task in order to be started or completed. In most cases, these prerequisites are specific deliverables of previous tasks.

Process

A process is a series of tasks that results in one or more critical project deliverables. The tasks in a process are usually highly dependent upon one another, and often span much of the project. Major project objectives are achieved by processes.

Dependency

A dependency between two tasks indicates that the latter task needs something from the former task in order to be started or completed. In most cases, these prerequisites are specific deliverables of previous tasks.

Process

A process is a series of tasks that results in one or more critical project deliverables. The tasks in a process are usually highly dependent upon one another, and often span much of the project. Major project objectives are achieved by processes.

1010

Essential Terminology (Cont)Essential Terminology (Cont)

Phase

A phase is a set of tasks that are performed during a specific period of time. Projects are usually delivered in a series of phases.

Standard

These are numbered working methods that specify how to use a specific tool. An example is: OMS-30531: Avoid underscores, punctuation marks, and symbols in entity names.

Phase

A phase is a set of tasks that are performed during a specific period of time. Projects are usually delivered in a series of phases.

Standard

These are numbered working methods that specify how to use a specific tool. An example is: OMS-30531: Avoid underscores, punctuation marks, and symbols in entity names.

1111

CDM Classic ProcessesCDM Classic Processes

Developing custom applications almost always means doing certain things, such as defining business requirements, converting data and testing. CDM Classic includes eleven distinct processes to handle these standard activities. These processes can be included or excluded in a project, depending upon the requirements and the needs of the specific development project.

Developing custom applications almost always means doing certain things, such as defining business requirements, converting data and testing. CDM Classic includes eleven distinct processes to handle these standard activities. These processes can be included or excluded in a project, depending upon the requirements and the needs of the specific development project.

1212

Business Requirements Definition (RD)Business Requirements Definition (RD)

The objectives of the Business Requirements Definition process are:

•Determine the business objectives for the application system.

•Determine the organizational structure of the business.

•Obtain a detailed understanding of the business areas that the application system is to support, through the construction of models of the processes that the business performs, the functions performed in those processes and the data that the business uses.

•Determine operational requirements and constraints, such as hours of availability, that must be satisfied by the application system.

The objectives of the Business Requirements Definition process are:

•Determine the business objectives for the application system.

•Determine the organizational structure of the business.

•Obtain a detailed understanding of the business areas that the application system is to support, through the construction of models of the processes that the business performs, the functions performed in those processes and the data that the business uses.

•Determine operational requirements and constraints, such as hours of availability, that must be satisfied by the application system.

1313

1414

Existing Systems Examination (ES)Existing Systems Examination (ES)The objectives of the Existing Systems Examination process are:

•Examine the existing information systems, current business processes and information needs related to the project’s defined business objectives.

•Identify the problems and opportunities related to the existing systems, business processes and information needs to provide a sound foundation for moving forward and addressing the problems and opportunities to ultimately architect, design, develop and implement a new quality application system.

•Gather and catalog existing documentation and reference material.

•Gather existing capacity figures and document the existing technical architecture.

The objectives of the Existing Systems Examination process are:

•Examine the existing information systems, current business processes and information needs related to the project’s defined business objectives.

•Identify the problems and opportunities related to the existing systems, business processes and information needs to provide a sound foundation for moving forward and addressing the problems and opportunities to ultimately architect, design, develop and implement a new quality application system.

•Gather and catalog existing documentation and reference material.

•Gather existing capacity figures and document the existing technical architecture.

1515

1616

Technical Architecture (TA)Technical Architecture (TA)

The objectives of the Technical Architecture process are:

•Define the hardware, network and non-application software that are required for the application software being developed.

•Provide an architecture that is consistent with the business’ strategic direction.

•Provide an architecture that supports the interfaces required to other systems.

•Determine Capacity Plan.

1717

1818

Database Design and Build (DB)Database Design and Build (DB)

The objectives of the Database Design and Build process are:

•Produce a design that meets the functional requirements, within the technical constraints.

•Optimize the database to meet design standards and performance requirements.

•Deliver technical documentation for future maintenance.

The objectives of the Database Design and Build process are:

•Produce a design that meets the functional requirements, within the technical constraints.

•Optimize the database to meet design standards and performance requirements.

•Deliver technical documentation for future maintenance.

1919

2020

Module Design and Build (MD)Module Design and Build (MD)

The objectives of the Module Design and Build process are:

•Produce a module design that meets the functional requirements, within the technical constraints.

•Document the module design in an accessible way, facilitating and supporting future maintenance of the system.

•Deliver well written and tested source modules for handover to the test team.

•Optimize source modules and database to meet the design standards.

•Deliver technical documentation for future maintenance.

The objectives of the Module Design and Build process are:

•Produce a module design that meets the functional requirements, within the technical constraints.

•Document the module design in an accessible way, facilitating and supporting future maintenance of the system.

•Deliver well written and tested source modules for handover to the test team.

•Optimize source modules and database to meet the design standards.

•Deliver technical documentation for future maintenance.

2121

2222

Data Conversion (CV)Data Conversion (CV)

The objectives of the Data Conversion process are:

•Define the needs for the conversion and migration of existing legacy data to the planned database.

•Design the strategy, programs, and test procedures needed to convert and migrate the legacy data to the planned database.

• Build the necessary modules and test cases to convert and migrate the legacy data to the planned database.

The objectives of the Data Conversion process are:

•Define the needs for the conversion and migration of existing legacy data to the planned database.

•Design the strategy, programs, and test procedures needed to convert and migrate the legacy data to the planned database.

• Build the necessary modules and test cases to convert and migrate the legacy data to the planned database.

2323

2424

Documentation (DO)Documentation (DO)

The objectives of the Documentation process are:

•Produce an instructional reference to support the application (User Reference, Online Help Text).

•Produce an operational set of procedures for using the application (User Guide).

•Produce documents for the maintenance staff describing the technical details of the application (Technical Reference).

The objectives of the Documentation process are:

•Produce an instructional reference to support the application (User Reference, Online Help Text).

•Produce an operational set of procedures for using the application (User Guide).

•Produce documents for the maintenance staff describing the technical details of the application (Technical Reference).

2525

2626

Testing (TE)Testing (TE)

The objectives of the Testing process are:

•Establish an approach to testing that naturally leverages testing requirements in related project activities.

•Introduce testing activities earlier in the software development life-cycle.

•Build-on and re-use testing deliverables in all phases of the testing process.

•Produce higher quality and better tested systems.

The objectives of the Testing process are:

•Establish an approach to testing that naturally leverages testing requirements in related project activities.

•Introduce testing activities earlier in the software development life-cycle.

•Build-on and re-use testing deliverables in all phases of the testing process.

•Produce higher quality and better tested systems.

2727

2828

Training (TR)Training (TR)

The objectives of the Training process are:

•Gain company wide acceptance of the new application.

•Provide users with the skills and knowledge to use the features and functions within their respective job roles.

•Achieve a smooth transition from the old application to the new application.

The objectives of the Training process are:

•Gain company wide acceptance of the new application.

•Provide users with the skills and knowledge to use the features and functions within their respective job roles.

•Achieve a smooth transition from the old application to the new application.

2929

3030

Transition (TS)Transition (TS)

The objectives of the Transition process are:

•Install the application system and set up support functions.

•Prepare users to use the new system.

•Prepare support personnel to support the new system.

•Verify the new system meets all acceptance criteria.

•Take the new system into production.

The objectives of the Transition process are:

•Install the application system and set up support functions.

•Prepare users to use the new system.

•Prepare support personnel to support the new system.

•Verify the new system meets all acceptance criteria.

•Take the new system into production.

3131

3232

Post-System Support (PS)Post-System Support (PS)

The objectives of the Post-System Support process are:

•Fulfill project warranty obligations.

•Monitor application performance and make corrections, if necessary.

•Log problems and make corrections, if necessary.

•Provide agreed levels of user support.

•Propose and plan future application enhancements.

The objectives of the Post-System Support process are:

•Fulfill project warranty obligations.

•Monitor application performance and make corrections, if necessary.

•Log problems and make corrections, if necessary.

•Provide agreed levels of user support.

•Propose and plan future application enhancements.

3333

3434

Elements of CDM ClassicElements of CDM Classic

CDM Classic PhasesCDM Classic Phases

3535

DefinitionDefinition

The goal of the Definition phase is to determine the business and information systems high-level requirements necessary to meet a set of defined business objectives. The Definition phase results in a clear and workable definition of a project’s scope. The final goal of the Definition phase is to obtain management approval to proceed with the Analysis phase.

The goal of the Definition phase is to determine the business and information systems high-level requirements necessary to meet a set of defined business objectives. The Definition phase results in a clear and workable definition of a project’s scope. The final goal of the Definition phase is to obtain management approval to proceed with the Analysis phase.

3636

3737

AnalysisAnalysis

The goal of the Analysis phase is to formulate the detailed requirements for the computer application system. The Analysis phase investigates the business area previously defined by the Definition phase. The analysis team members gain a thorough understanding of the business area by producing an accurate set of models and descriptions of what the business area does and the information which it uses. It then transforms these into models specifying the detailed requirements for a computer application system, defines a technical architecture to run that system and proposes strategy for transition to that system from any current systems.

The goal of the Analysis phase is to formulate the detailed requirements for the computer application system. The Analysis phase investigates the business area previously defined by the Definition phase. The analysis team members gain a thorough understanding of the business area by producing an accurate set of models and descriptions of what the business area does and the information which it uses. It then transforms these into models specifying the detailed requirements for a computer application system, defines a technical architecture to run that system and proposes strategy for transition to that system from any current systems.

3838

3939

4040

DesignDesign

The goal of the Design phase is to take the requirements from the Analysis phase and translate them into detailed system specifications, taking into account the technical architecture and available technology.

The goal of the Design phase is to take the requirements from the Analysis phase and translate them into detailed system specifications, taking into account the technical architecture and available technology.

4141

4242

4343

BuildBuild

The goal of the Build phase is to code and test the application, using appropriate techniques. These techniques depend on the type of source modules involved, but may range from conventional development to a series of quick builds using incremental development.

The goal of the Build phase is to code and test the application, using appropriate techniques. These techniques depend on the type of source modules involved, but may range from conventional development to a series of quick builds using incremental development.

4444

4545

4646

TransitionTransition

The goal of the Transition phase is to install the new application system, prepare client personnel to use and administer the application system, and then “go production.” The transition team performs the installations, trains personnel, supports the acceptance tests and puts the application system into production. Transition should not generate new documentation or code but should instead be a phase in which existing code, documentation and data are put into production use.

The goal of the Transition phase is to install the new application system, prepare client personnel to use and administer the application system, and then “go production.” The transition team performs the installations, trains personnel, supports the acceptance tests and puts the application system into production. Transition should not generate new documentation or code but should instead be a phase in which existing code, documentation and data are put into production use.

4747

4848

ProductionProduction

The goal of the Production phase is to provide application support, monitor the application, make sure the application runs smooth, and plan for future functional enhancements.

The goal of the Production phase is to provide application support, monitor the application, make sure the application runs smooth, and plan for future functional enhancements.

4949

5050

Application

Business RequirementsBusiness RequirementsBusiness Requirements

Custom Development Life-Cycle OverviewCustom Development Life-Cycle Overview

ProcessProcess InformationInformation

Business Layer

Logical Layer

Browser:

http://

HollywoodHollywoodXX

Action Edit Block Filed

++Customers:

Physical Layer

5151

The Business Layer

The goal of the business layer is to deliver the business model, which consists of context, process, function, and data models.

The Logical Layer

Work done in the logical layer emphasizes heavy reuse of the business

models, and delivers system architecture, odule specifications, and the logical database.

5252

1. Context Process Model

You create the context process model to identify key processes that the business performs. You identify primary triggering events, major process flows and high-level business units. Interfaces to other systems are also documented.

2.Top-layer Business Functions

Create the top-layer functional hierarchy to show a high-level business functional grouping of the primary functional areas within the organization.

3.Business Process Model

In the Business Process Model you document business events and processes. Detail each process with process steps, process flows, business decision points, organizational units, triggering events and outcomes. A process step at its lowest level, becomes an elementary business function. The business process model is concerned with documenting what is to be done without regard to how it will be accomplished.

1. Context Process Model

You create the context process model to identify key processes that the business performs. You identify primary triggering events, major process flows and high-level business units. Interfaces to other systems are also documented.

2.Top-layer Business Functions

Create the top-layer functional hierarchy to show a high-level business functional grouping of the primary functional areas within the organization.

3.Business Process Model

In the Business Process Model you document business events and processes. Detail each process with process steps, process flows, business decision points, organizational units, triggering events and outcomes. A process step at its lowest level, becomes an elementary business function. The business process model is concerned with documenting what is to be done without regard to how it will be accomplished.

5353

4. Business Function Model

In the Business Function Model you organize elementary business functions under functional area hierarchies. Also add non-processbased functions, such as maintenance functions and single-step functions, to the function hierarchy. Map elementary business functions to entities and attributes, and detail their functionality with pseudo-code.

5. Business Data Model

In the Business Data Model you document the business data requirements. You create business entities and entity relationships and identify primary attributes.

6. Entity/Attribute to Function Matrix

To complete the business function model you map business entity and attributes from the business data model to business functions.

4. Business Function Model

In the Business Function Model you organize elementary business functions under functional area hierarchies. Also add non-processbased functions, such as maintenance functions and single-step functions, to the function hierarchy. Map elementary business functions to entities and attributes, and detail their functionality with pseudo-code.

5. Business Data Model

In the Business Data Model you document the business data requirements. You create business entities and entity relationships and identify primary attributes.

6. Entity/Attribute to Function Matrix

To complete the business function model you map business entity and attributes from the business data model to business functions.

5454

7. System Process Model

The System Process Model identifies how the processes will be performed by indicating which process steps are screens, reports or batch.

8. System Function Model

The System Function Model includes all of the functions needed to support the application system. Elementary business functions are now mapped to entities and attributes, and documented with pseudocode language detailing their functionality.

9. System Data Model

The System Data Model includes all of the entities needed to support the application system.

10. Entity/Attribute to Function Matrix

To complete the system function model you map system entity and attributes from the system data model to system functions.

7. System Process Model

The System Process Model identifies how the processes will be performed by indicating which process steps are screens, reports or batch.

8. System Function Model

The System Function Model includes all of the functions needed to support the application system. Elementary business functions are now mapped to entities and attributes, and documented with pseudocode language detailing their functionality.

9. System Data Model

The System Data Model includes all of the entities needed to support the application system.

10. Entity/Attribute to Function Matrix

To complete the system function model you map system entity and attributes from the system data model to system functions.

5555

The Physical Layer

In the physical layer, the team produces the custom application and

database by exploiting application and server DDL generators. The

team verifies the physical application through testing, and documents final business alignment by executing test scripts developed directly

from recycled and extended business processes (that were first developed in the business layer).

5656

11. Module Process Model

The Module Process Model (a component of the Application Design deliverable) represents the way specific modules support the business process.

12. Module Definition

In module definition you map elementary business functions to primary modules, and map detailed table and column usages.

Develop function logic, module layouts, and constraints, and apply user interface standards.

13. Database Definition

In developing the database definition you design tables and columns, develop primary and foreign key definitions, and design sequences and indexes. Develop validation rules, resolve super- and subtyping issues, and create derivation and denormalization columns.

11. Module Process Model

The Module Process Model (a component of the Application Design deliverable) represents the way specific modules support the business process.

12. Module Definition

In module definition you map elementary business functions to primary modules, and map detailed table and column usages.

Develop function logic, module layouts, and constraints, and apply user interface standards.

13. Database Definition

In developing the database definition you design tables and columns, develop primary and foreign key definitions, and design sequences and indexes. Develop validation rules, resolve super- and subtyping issues, and create derivation and denormalization columns.

5757

14. Module Generation

Employ Oracle Designer™ generators to generate forms, reports and server triggers. Use Oracle Developer™ tools to customize your application, as required. You can choose to re-engineer changes back into Designer and regenerate, or to continue full Developer utilization using the generated application as a starting point for customizations.

15. Database Generation

Use Oracle Designer server generators to create scripts that define tablespaces and rollback segments, assign database objects to tablespaces, and calculate extents, percent free, and percent used.

Determine size and number of data files for each tablespace, and define redo log files for each database. Execute the scripts to build the application database and its objects.

14. Module Generation

Employ Oracle Designer™ generators to generate forms, reports and server triggers. Use Oracle Developer™ tools to customize your application, as required. You can choose to re-engineer changes back into Designer and regenerate, or to continue full Developer utilization using the generated application as a starting point for customizations.

15. Database Generation

Use Oracle Designer server generators to create scripts that define tablespaces and rollback segments, assign database objects to tablespaces, and calculate extents, percent free, and percent used.

Determine size and number of data files for each tablespace, and define redo log files for each database. Execute the scripts to build the application database and its objects.

5858

VerificationVerification

5959

16. Module Testing

Perform module testing on each module of the application as it becomes available. Design module tests to exercise functionality based on elementary business functions, validation, calculations, errorhandling, module security, user-interface behavior, help text, and layout.

17. Module Integration Testing

Perform module integration testing on modules responding to the same business event and process within a functional area. A module integration test verifies the linkage and integration between modules.

16. Module Testing

Perform module testing on each module of the application as it becomes available. Design module tests to exercise functionality based on elementary business functions, validation, calculations, errorhandling, module security, user-interface behavior, help text, and layout.

17. Module Integration Testing

Perform module integration testing on modules responding to the same business event and process within a functional area. A module integration test verifies the linkage and integration between modules.

6060

VerificationVerification

6161

18. System Testing

System testing verifies the entire application system by testing the integration between processes. System tests are specifically designed to test database journaling, security, documentation, manual data, converted data, process integration, legacy system reconciliation, job streams, backup and recovery, and data archival. Execute concurrent scenarios to test server load. Test table and row locking, as well.

19. Systems Integration Testing

Systems integration testing verifies the co-existence and integration of the application system with neighboring application systems. Design systems integration tests to test module integration or interfacing across application systems. To test network load, simulate timeperiod based user loads by executing multiple concurrent scenarios.

18. System Testing

System testing verifies the entire application system by testing the integration between processes. System tests are specifically designed to test database journaling, security, documentation, manual data, converted data, process integration, legacy system reconciliation, job streams, backup and recovery, and data archival. Execute concurrent scenarios to test server load. Test table and row locking, as well.

19. Systems Integration Testing

Systems integration testing verifies the co-existence and integration of the application system with neighboring application systems. Design systems integration tests to test module integration or interfacing across application systems. To test network load, simulate timeperiod based user loads by executing multiple concurrent scenarios.

6262

20. Acceptance Testing

Acceptance testing verifies that the new application system meets user acceptance criteria. The acceptance test simulates live production and is performed in a production-like environment with end users executing system test scripts on recently-converted data. If key users have been involved in system and systems integration testing, acceptance testing can be perfunctory.

20. Acceptance Testing

Acceptance testing verifies that the new application system meets user acceptance criteria. The acceptance test simulates live production and is performed in a production-like environment with end users executing system test scripts on recently-converted data. If key users have been involved in system and systems integration testing, acceptance testing can be perfunctory.