A Quick Tour of CDM
Building Systems that Work
I need a recipe that
tells me …and a tool that
… what to do
…and how to do it
An Approach to Building Systems
What do you do? How do you do it?
• Process modeling
• Entity modeling
• Cross checking
Can you automate it?
What is CDM?
The Oracle Custom Development Method
(CDM) is Oracle’s full lifecycle method for
delivering custom computer application
It is a roadmap for successful systems
CDM includes the CDM Standards and
Guidelines library, containing detailed
guidelines and standards for the use of
Oracle Tools in custom development
What Do You Do?
http:// Action Edit Block Filed
CDM is part of Oracle Method — Oracle’s methodology for defining and
delivering information systems solutions that add business value.
Why Use CDM?
•Best Practices — Globally
•You Know What You Are Getting
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.
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
Essential Terminology (Cont)
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.
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.
Essential Terminology (Cont)
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.
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.
CDM 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.
Business Requirements Definition (RD)
The objectives of the Business Requirements Definition
•Determine the business objectives for the application
•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
Existing Systems Examination (ES)
The objectives of the Existing Systems Examination
•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
•Gather existing capacity figures and document the
existing technical architecture.
Technical Architecture (TA)
The objectives of the Technical Architecture process
•Define the hardware, network and non-application
software that are required for the application software
•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.
Database Design and Build (DB)
The objectives of the Database Design and Build process
•Produce a design that meets the functional requirements,
within the technical constraints.
•Optimize the database to meet design standards and
•Deliver technical documentation for future maintenance.
Module Design and Build (MD)
The objectives of the Module Design and Build process
•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
•Deliver well written and tested source modules for
handover to the test team.
•Optimize source modules and database to meet the
•Deliver technical documentation for future maintenance.
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
• Build the necessary modules and test cases to convert
and migrate the legacy data to the planned database.
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
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
•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 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 Transition process are:
•Install the application system and set up support
•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.
Post-System Support (PS)
The objectives of the Post-System Support process are:
•Fulfill project warranty obligations.
•Monitor application performance and make corrections, if
•Log problems and make corrections, if necessary.
•Provide agreed levels of user support.
•Propose and plan future application enhancements.
Elements of CDM Classic
CDM Classic Phases
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 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 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 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 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
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
Custom Development Life-Cycle Overview
Action Edit Block Filed
The Business Layer
The goal of the
business layer is to
deliver the business
consists of context,
and data models.
The Logical Layer
Work done in the
reuse of the business
models, and delivers
and the logical
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.
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
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
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.
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
through testing, and
business alignment by
executing test scripts
from recycled and
processes (that were
first developed in the
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
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
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.
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
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.
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