Dr. Paul Dorsey, Dulcian, Inc.

Tom Coen, Oracle Consulting

Using a structured systems development methodology is one of the critical success factors in a systems development project. CADM (CASE Application Development Method), as described in the Oracle Press Designer/2000 Handbook and CDM (Custom Development Method), Oracle Consulting’s development method are both project management methodologies. Both methods are adaptive, each having customized versions to support large and small application development and data warehousing. The CADM method is described, at a high level, in the Designer/2000 Handbook. The complete version is available through Dulcian, Inc. CDM Advantage is a product sold by Oracle Consulting available through Oracle sales representatives.

CDM was designed and built by an international team of consultants to support the way that Oracle Consulting plans and manages projects. Oracle Consulting is the largest Oracle services organization in the world, successfully managing hundreds of projects worldwide. CADM evolved as the development method used by Dr. Paul Dorsey of Dulcian, Inc. and Peter Koletzke of Millenia Vision Corporation in their consulting experience. Both methods have been successfully employed on a large number of projects.

The two methods have much in common. They are both detailed descriptions of the SDLC adapted for the Oracle environment. However, there are some significant differences in both philosophy and approach. There have been many questions concerning how these two methods compare. This paper will attempt to clear up the confusion and describe the similarities and differences between the two methods.

CADM is based upon a few core concepts. First, an engineering manufacturing approach to software development was used. This approach pays careful attention to quality control points, identifying where in the SDLC these points occur and what types of checks are necessary to ensure that each phase is successfully completed before the project is ready to move into the next phase. Explicit quality control points are included, such the formal model defense after the data model is complete. Conversely, within CADM, quality control points were eliminated where unnecessary due to implicit controls. For example, performing data migration helps to validate many aspects of the physical database design.

A second major philosophical component of CADM is an audit trail for system requirements. We included the ability to track a requirement throughout the SDLC from its initial gathering during analysis to its impact on user acceptance testing at the end of the process.

Seamless integration with Designer/2000 and Developer/2000 was a third concept viewed as essential to the underlying philosophy of CADM. One of the problems for many methodologists is the fact that the available tools greatly influence the way systems are built. Even the basics of the development process are influenced by the tools selected. For example, the current Rapid Application Development (RAD) thrust is driven by the ability to quickly generate prototypes. As a result, in developing CADM, we assumed that teams would be using both Designer/2000 and Developer/2000. Everything about the CADM method is built around these products. At each phase, CADM describes how Designer/2000 is best used at that point in the process.

The data migration phase of a project can consume up to 50% of the total project resources. Typically, the amount of attention paid to it in existing methodologies is very small. CADM includes a specific migration strategy that, because of space limitations, was only cursorily described in the Desginer/2000 Handbook 1^st Edition, but will be greatly expanded in the 2^nd Edition.

Finally, the advent of Oracle8 and object-oriented thinking being incorporated into Designer/2000 and Developer/2000 products is greatly influencing the way systems are being built. CADM is designed to maximize the amount of reuse within and between projects. For more details on this, see the paper "Advanced Object Oriented Development in Developer/2000" by Paul Dorsey also included in these proceedings.

CADM is described in detail in the Designer/2000 Handbook. However, just as Designer/2000 has evolved, so has CADM. The most significant changes from the first version are the combining of the Design and Build phases into a single Development phase even for large projects and the explicit addition of a planning phase before each major development phase.

The phases included in the CADM method are the following:

1. Pre-Strategy: This phase involves ascertaining the high-level scope of project and creating a plan for the Strategy phase including the initial contract and available resource planning based on initial assumptions.
2. Strategy: The main goal of the Strategy phase is the creation of the Strategy Document which describes the common vision of users and developers as to what the completed system should do.
3. Pre-Analysis: In this phase, all of the Analysis phase planning is laid out. A workplan for Analysis is created, the project environment is documented along with data collection strategies and the format and contents of the Requirements Document.
4. Analysis - Information Gathering: Information about the legacy system and user requirements is gathered through interviews, questionnaires, JAD sessions, user walkthroughs of the legacy system and documentation reviews. ERD’s, Function Hierarchies and prototypes are created.
5. Analysis: Requirements Analysis: All of the information collected in the first part of Analysis is organized into a Requirements Document. This document outlines the needs of the users for the entire system. This document should include a function hierarchy, full legacy system documentation, report audit, business objectives and critical success factors for relevant business areas, Analysis ERD and business function process flows.
6. Pre-Development: The deliverables for this phase include a complete set of Design standards (GUI, Coding and naming conventions), conceptual design of applications (storyboards, module structure, requirements mapping, functional module descriptions) and a Design Plan for both database and applications
7. Database Development: At this point in the process, the following steps are taken in database design – specifying tables, determining primary keys, implementing dependencies, assigning attributes to tables, implementing complex business rules, creating redundant columns, summary and aggregation tables, views, code description tables, and tracking history. The phase ends when the database is physically configured, data migration is complete and tuning is done and unit level testing is performed. An audit of the database design is performed.
8. Application Development: In this phase, modules are mapped to the database at the column level, database design is completed and the design book (including screen and report mockups, encapsulation of all design level analysis) is finalized. Unit level testing must also be performed on each module.
9. Data Migration: Data migration is a major component of many projects. It has its own SDLC and is properly viewed as an interlocking phase with Development. A full discussion of data migration is beyond the scope of this paper. (A more complete discussion may be obtained from the paper "Data Migration Methodology" and the papers describing DataMIG, the tool built by Dulcian, Inc. for automating the process at www.dulcian.com).
10. Documentation: This is a very important part of the whole system development process. Documentation should include system documentation, user documentation, training materials, help and helpdesk functions.
11. Test: A test plan is developed for each of the major deliverables (Strategy Document, Requirements Document, Design Book). The system itself undergoes integration, transaction flow, stress, backup and recovery test. Decisions must be made about change control, and enhancement requests. User acceptance testing is performed at this point.
12. Implementation: Decisions about whether to implement all at once, perform a phased implementation or run the old and new systems in parallel are made at this point in the CADM process.
13. Maintenance: Maintenance continues throughout the life of any system. At some point a decision is made about versioning the system are based upon careful consideration of approval and prioritization of enhancement requests.

Oracle’s Custom Development Method (CDM) was developed as part of a system of methods known as Oracle Method that support the entire span of services that Oracle Consulting provides to its clients. These services include Information Services Strategy, Business Process Reengineering, Enterprise Architecture and Change Management as well as traditional software engineering services such as custom application development. Oracle Method acts as a repository of Oracle Consulting’s best practice that includes methods for planning and executing projects, deliverable standards, task guidelines and tools for creating and managing deliverables.

The Software Engineering Institute’s (SEI) maturity model was very influential on the thinking of the Oracle Method development team. The goal of Oracle Method is to establish a defined and repeatable approach to the project lifecycle that can be implemented consistently across a large, global consulting organization. Meeting this goal allows Oracle Consulting to achieve level 3 (out of 5) on the SEI maturity scale and also plays a key role in Oracle’s ISO9000 certification program.

Oracle Method’s architecture is a deliverable based. The essence of Oracle Method’s philosophy is that a well-defined set of deliverables are the foundation on which a project is planned and executed. Each deliverable must have a task in the plan to create it and each task must have a deliverable. By establishing deliverable standards and guidelines, Oracle Method provides an objective way to measure completeness and quality of the project results.

Another key concept of Oracle Method is that related asks are organized into processes, for example Business Requirements Definition or Technical Architecture. Processes may span the entire lifecycle of project or several phases within the lifecycle. The tasks within a process tend to share competencies which facilitates staffing and organization of projects into teams of specialists. Processes can also be tailored or eliminated according to the circumstances of a project. For example, Data Conversion may not be required so the entire thread of related tasks can be dropped from the project plan without jeopardizing its success. In concept, processes are designed to be reusable across methods, providing the "glue" on large projects involving, multi-disciplinary teams.

Lastly, processes and tasks are organized into a phased lifecycle in order to provide appropriate management and control of the project. The actually phasing (or "approach") that a project selects is based on the size, complexity and risk of the project. CDM currently supports three different phasing options—CDM Classic (a traditional full lifecycle), Fast Track (a RAD approach) and Lite (small, low risk projects).

CDM projects are executed under the control of Oracle’s Project Management Method (PJM), available commercially as PJM Advantage. PJM defines the processes and tasks for planning, estimating, controlling and completing any software engineering project such as developing a custom system, implementing a packaged application or building a data warehouse. There are five processes within PJM—Control and Reporting, Work Management, Resource Management, Quality Management and Configuration Management. These processes are tightly "wrapped" around the CDM phases, tasks and deliverables in the project plan to ensure that the project scope, time, cost and quality are managed properly.

Oracle recognizes that its current methods are constrained by the limitations of paper and single-user tools such as Microsoft Office. Part of Oracle Method’s vision is to achieve level 5 on the SEI maturity model where our methods and best practices are part of a continuous improvement cycle. To move closer to this vision, we are embarking on a series of projects to migrate Oracle Method to a shared repository with a web-enabled workflow interface. In this new environment, project teams will be able to tailor Oracle Method to requirements of their project, create and manage all deliverables in a repository, and have access to best practice from other project teams throughout Oracle via the Intranet. Ultimately, we hope to make our knowledge base available directly to our clients to support the effective implementation of Oracle centric solutions.

CDM is described in detail in the CDM Advantage handbooks. CDM is periodically updated to incorporate best practice from Oracle’s Consulting organization. There are three significant updates currently underway to 1) update the standards and guidelines to support Designer 2000 V2.0 and Oracle8; 2) incorporate object oriented development tools and techniques; and 3) support the Dynamic Systems Development Method (DSDM) Consortium’s rapid application development standard.

CDM tasks are organized into 11 processes that may be scaled up or down depending on the project’s requirements:

1. Business Requirements Definition: The Business Requirements Definition process defines the business needs of the application system. The analysis team first builds a Business Process Model that indicates all of the business events and subsequent responses that the application must support. The team then constructs a Business Data Model to represent the business’ information needs, and a Business Function Model that details each of the business functions indicated by the process model. Once the business requirements are defined, the analysis team then adds technological requirements to the models such as user interface, response time, etc. In this way, the team transforms the business requirement models into system requirement models.
2. Existing Systems Examination:. A significant requirement in many custom development projects is to replace the functionality of an existing system or to work with an existing technical architecture. The Existing Systems Examination process seeks to meet this need. Many of the tasks in this process may be eliminated if the project is not a functional replacement of an existing system. This process can be greatly expedited if up-to-date documentation of the existing system’s functionality and technical details exists.
3. Technical Architecture: The Technical Architecture process specifies elements of the technical foundation of the development project. It assumes that a larger information system strategy already exists and that these elements will fit within that strategy. Starting with an Initial Capacity Plan, analysts develop an Initial Technical Architecture. As more detailed information become available, the team transforms this deliverable into two parts: the Hardware and Software Foundation Definition, and the Distribution Architecture. This process also provides strategies for security and control, user interface and backup and recovery. One of the last deliverables of this process is the final Capacity Plan, which can be used as input to measure the performance of the application system.
4. Database Design and Build: The Database Design and Build process begins with the creation of the Logical Database Design from the System Data Model, and ends with the creation of the Production Database DDL. The process of designing and building a relational database includes specifying an index design and a scheme for implementing database object security. The physical database design uses both the Capacity Plan and the Distribution Architecture deliverables as primary inputs.
5. Module Design and Build: The Module Design and Build process is the heart of the CDM project. Designers use the System Process Model, the System Data Model, and the System Function Model along with the technical architecture, to first design the system architecture and the Module Process Model, and then to specify the functional and technical details of each module. Programmers then use the design documentation and/or prototypes to construct the Application Code. The management and control strategy of this process can vary greatly, depending upon the overall project approach. For instance, in a highly iterative development approach, you may duplicate the entire process for each functional area or build. A very complex application may call for all design documentation to be completed and approved before any actual programming is done.
6. Data Conversion:.. The objective of the Data Conversion process is to migrate, convert and test all legacy data that is necessary for testing and for the operation of the new application. The first step of this process is to explicitly define the data that is required to be converted, along with its sources. This data may be needed for system testing, systems integration testing, training and acceptance testing as well as production. Following this, the project team determines an overall strategy to meet those requirements, including both automated and manual methods. The process includes designing, coding and testing any conversion modules that are necessary and, of course, performing all actual conversions themselves.
7. Documentation: The Documentation process centers on producing high quality textual deliverables. It produces all of the user, technical, and training documentation for the project. The two primary user-oriented types of documentation are the User Guide and the User Reference. The User Guide is based on the Module Process Model, and seeks to guide each user role in using the application to carry out business processes. The User Reference is a reference guide that specifies the functionality of each module of the application.
8. Testing: The Testing process is an integrated approach for testing the quality of all elements of the application system. It includes both functionally-oriented module testing and business-oriented module integration, system, systems integration and acceptance testing. All business-oriented testing is driven by the process model to establish firm traceability back to business requirements. The Testing process emphasizes a common planning approach to all types of testing. It advocates the re-use of testing scripts to test successively larger and larger portions of the application system.
9. Training: The objective of the Training process is to create users and administrators that are adequately trained to take on the tasks of running the new application system. The team may also train future maintenance personnel and the acceptance test team.
10. Transition: The Transition process begins early in the project by defining the specific requirements for cut-over to the new application system. It then includes tasks to carry out the elements of that strategy such as developing the Installation Plan, preparing the Production Environment, performing the cut-over, and decommissioning any legacy systems.
11. Post-System Support: The four objectives of the Post-System Support process are to monitor and respond to system problems via a help desk, to upgrade the application to fix errors and performance problems, to evaluate the system in production, and to plan enhancements.

CDM tasks are organized into the phases to provide appropriate management and control checkpoints. Each phase executes task associated with one or more processes that execute in parallel. The CDM Classic phases are:

1. Definition: The goal of the Definition phase is to determine the high-level business and information system requirements necessary to meet a defined set of business objectives. The result is a clear definition of a project’s functional scope and the time, cost and resources to complete.
2. Analysis:. During the Analysis phase, the project team investigates the detailed requirements of the application system. The key deliverables are the process, function and data models that describe what each area of the business does and the information it uses.
3. Design: The goal of the Design phase is to take the requirements from the Analysis phase and translate them into detailed system specifications, while taking into account the technical architecture and available technology. The objectives are to produce a design that meets the specified functional requirements, within the technical constraints of the project and to facilitate and support future maintenance of the system.
4. Build: During the Build phase, the application system is coded and tested following rigorous techniques. During this phase, data conversion modules are also created along with complete user documentation. The Build phase is not complete until the client is provided with documentation showing how the application system supports each business process within the functional scope of the project.
5. Transition: 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.
6. Production: Once the application has been implemented successfully, it is necessary to provide operational support, monitor the performance and stability of the application, and plan for future functional enhancements.

Each systems development project is different. When creating a methodology, an attempt is made to encompass as many generalizations in the projects encountered as possible. Oracle Consulting sees certain types of projects whereas Paul Dorsey of Dulcian, Inc. and Peter Koletzke of Millennia Vision Corp. see different types of projects. The largest difference between the two methods is that CADM is built around small to medium-sized development teams so that the amount of precise individual control is less. CDM, with its itemized checklists, is more focused on projects with large development teams where more detailed coordination and its inherent costs and overhead are required. CADM’s careful attention to an audit trail and quality control points compensate for the smaller quantity of physical checklists. Another major difference between CADM and CDM is CADM’s collapsing of the Design and Build phases. The CADM authors firmly believe that, even for large systems, the processes of designing and building cannot be broken apart. Any demarcation between these two phases is purely artificial. The authors of CDM believe that collapsing Design and Build into a single phase is only appropriate for small and medium-sized systems but should remain separate for large projects.