Dr. Paul Dorsey

Dulcian, Inc.

Peter Koletzke

A & Z Software Shop, Inc.

There is no magic about the Systems Development Life Cycle (SDLC). It has been documented in every book on analysis and design for the last 20 years. With the exception of a few radical shifts such as prototyping methodology in the mid 1980s, there hasn’t been a fundamental shift in the SDLC since it was described decades ago.

Since the Designer/2000 product is an Oracle product, many of you will be familiar with the systems life cycle development steps as outlined by Barker and known as the CASE method. The basic phases in Barker’s method are: Strategy, Analysis, Design, Build, Documentation, Transition and Production. Not all tasks in the various phases of the CASE method are fully supported by the Designer/2000 tool. We decided to modify and enhance the CASE method to reflect this and make the best use possible of Designer/2000.

We found the basic steps of the CASE design process too broad. Therefore, we have added the transition steps of Pre-Analysis and Pre-Design to the basic methodology as well as including Implementation in the overall process. We have named our expanded CASE method, CADM (CASE Application Development Method), pronounced "cad-em,"as Figure 1 at the end of this paper diagrams this new expanded method .

This paper will provide an overview of CADM describing the most important aspects of each phase including the major deliverables in the systems development process and ways of assisting the process using Designer/2000.

The goal of the Strategy phase is to gain a clear understanding of the business area’s objectives, processes, direction and needs in order to structure and document the vision of a project. The major deliverable in this phase is the Strategy Document which outlines the scope of a project and defines an agreement about what the project is committed to deliver. It also includes the estimated budget, time frame, resources, controls and standards within which the project must be completed. It is the foundation for moving forward and preparing detailed plans. It is important to deliver a high-quality Strategy Document that includes the following parts: Strategy Entity Relationship Diagram (ERD), top-level Requirements Document, analysis of the political environment, work flow plan, strategy-level process flows, and strategy evaluation. At its core, the Strategy Document is a contract. There must be a meeting of the minds if the contract is to make sense and be honored.

Designer/2000 supports all the diagramming work you perform in the Strategy phase as Table 1 shows.

These two diagrammers represent the functions and data in the system and are excellent tools for communicating with users and the development team and checking whether your understanding of what the system should do is complete and accurate.

The goals of Pre-Analysis are to plan the Analysis phase and to begin to set standards. Users and developers together must create a strategy that ensures that the analysis will be performed correctly. The Pre-Analysis deliverable should include the following: Analysis Plan, plan for implementing CASE analysis standards, and Pre-Analysis evaluation.

Pre-Analysis is finished when everyone agrees that there is an appropriate plan for gathering all user requirements. As with other phases, both users and developers have to agree that the Pre-Analysis is complete.

Since Pre-Analysis is basically a preparation phase, there are a limited number of activities you perform or consider in Designer/2000. These are outlined in Table 2.

The goal of the Analysis phase is to capture all of the user specifications for the project and to completely detail all business processes that will be involved. This is the most important step in systems design. We have broken the Analysis phase into two parts: Information Gathering and Requirements Analysis.

As the Analysis phase begins, the ERD and functional hierarchy are built. The existing business processes, the legacy system, and the users themselves are all sources of the requirements information. The Analysis Document consists of the following parts: Analysis ERD, logical process flows, Requirements Document, and Analysis evaluation.

Designer/2000 offers you considerable support in the Analysis phase, and you can produce many of the main deliverables directly from the tools and diagrammers. Table 3 lists the diagrammers and utilities that are most useful for the information gathering part of the Analysis phase.

A carefully prepared Requirements Document is one of the major keys to system success. With a Requirements Document, it is possible to cross-reference requirements by entity model, function model, and source. Then a tool can be constructed that enables both client and consultants to validate the information transfer. By mapping system requirements to the Designer/2000 deliverables, the ERDs and functional hierarchies can be cross-checked. The Requirements Document should include the following: analysis function hierarchy, legacy system documentation, business rules, and requirements mapped to the function hierarchy.

Designer/2000 supports many of the activities you do in the Requirements Analysis step in the Analysis phase. Its Systems Modeller diagrammers and some of the repository utilities assist in your efforts to capture, analyze, manage and process the information you have gathered about the business and represent it with repository definitions. Table 4 shows the diagrammers and utilities that you typically would use in the Requirements Analysis part of the Analysis phase.

In the phase between Analysis and Design, the rest of the project is planned. The Pre-Design phase includes the following: Design Plan, process flows (physical), design standards, screen concept prototype, and Pre-Design evaluation. The plan for the Design phase must move comfortably from logical design to physical design. The plan should start with the logical process flows, then specify the results of consultation with the users regarding what will be part of the new system and what will remain as a manual process. Next, iteratively develop prototypes of the system with screen designs that are supported by physical level process flows then go back to the functional hierarchy and redo it at the physical level. Finally, the designers should identify elemental functions in preparation for generation of modules. 

At this point in the CADM process, decisions must be made concerning the following design standards:

• Screen layout (including colors, fonts and buttons)
• Navigation tools (including menus and buttons)
• Help systems
• Documentation
• Functionality
• Coding standards
• Naming conventions

One of the best strategies for developing design standards is to create several archetypal applications and then to reverse engineer the standards into Designer/2000 templates. Archetypal applications should include coding and description, large tables, master details, many-to-many relationships, and several complex implementations. This task must be performed knowing how Designer/2000 will generate applications. The goal is to produce standards that are easily generated by Designer/2000.

The Pre-Design phase is complete when users are happy with the screen prototypes and process flows. Both users and developers should approve the design standards and Design Plan.

Designer/2000 assists your work in the Pre-Design phase by providing a foundation for the steps you perform in preparation for the Design phase. Table 5 shows the supported Pre-Design activities or deliverables and the Designer/2000 tool that handles them.

Other than the GUI design standards, the main deliverable in Pre-Design that Designer/2000 supports is the storyboard or conceptual application design. The storyboard is really a prototype of the complete system that you can use to communicate your ideas to users or clients. The main steps to create and process this storyboard in Designer/2000 follow:

1. Map attributes to functions if you did not do that in the Analysis phase using the Function/Attribute Matrix Utility.
2. Create a first-cut set of table definitions with the Database Design Wizard.
3. Create a first-cut set of modules and a module network with the Application Design Wizard.
4. Run the Server Generator to create scripts for the tables. Then run these scripts in SQL*Plus to create the tables.
5. Generate screens and reports from the first-cut modules using the Forms and Reports generators.
6. Refine the forms and reports using Developer/2000 and rearrange the module setup on paper--a non-Designer/2000 step.
7. Integrate changes in table design from storyboard process into the repository.
8. Integrate modified modules and module network structure to the repository using Reverse Engineering utilities and Module Structure Diagrammer.
9. Map requirements to modules using the API or the RON.

The Design phase is where the blueprints are drawn for building the system. Every detail should be laid out before generation. The Design phase is divided into two parts: Database Design and Application Design.

Database Design

Database Design involves the designing of the tables and columns along with the detailed specification of domains and check constraints on the columns. Also, Database Design includes the de-normalization of the database to improve performance along with the associated triggers to support that de-normalization.

The Design table diagram is the final pre-build ERD.

 Here is where any necessary de-normalization takes place. Low-level details should be considered; and table designs should be rigorously, logically tested with sample data before implementation.

The main objective of the Database Design part of the Design phase is to completely refine the definitions for all database objects needed in the system. You need to have a good start on the database design before you can begin the application design because the modules you work on in the Application Design phase rely on the tables you defined in the Database Design phase.

This is an iterative process, though, so you will be defining tables as you are defining modules. The idea is to have as close a set of table definitions as possible before you start the Application Design part of this phase. Designer/2000 provides support for this work in its diagrammers and utilities as Table 6 details.

Note that there is no mention of the Database Design Wizard in this section although its name implies that it might be useful in this phase. The Pre-Design phase uses it extensively to create the tables needed for the storyboard process. However, you may find it useful to refine entities and rerun this utility for a certain subset of tables after you find out more about the database in the Design phase.

In addition to the design of specific applications and reports, Application Design involves decision making about what product will be used for those designs, i.e. Visual Basic, Forms, HTML, or C++. In doing screen design, a full system prototype should be built based only upon screen layouts. You should not go directly to Designer/2000 generation without first developing a prototype. Prototypes can be created in Designer/2000 or using Developer/2000 application development tools or any other GUI tools.

Screen designs should be built according to what will realistically be generated using Designer/2000. Efficient system design is predicated upon staying as close as possible to what Designer/2000 will generate for free. There is no point in showing users a prototype that will be inferior to the final system.

During the Application Design phase, the Design Book must be completed. Each module to be generated should have a set of information associated with it including the information associated with the tool as well as functions and requirements that should be documented. The goal here is to generate a folder for each application that fully describes that application. This folder acts as the primary unit testing document. The tester need only ensure that the forms application meets the specifications listed in the folder. In addition, the physical process flows should be a part of the Design Book to assist in system testing.

Design is complete when the design documents can be handed over to another team to build, with each application having its own screen (or report) design, list of detailed functionality, and create-retrieve-update-delete (CRUD) report.

In the Application Design part of the Design phase, you fully define the modules (screens, reports, menus) that make up the finished application. Designer/2000 helps you enter these definitions in an organized and methodical manner so you can be more complete in the details needed. The Designer/2000 definitions serve as the program specifications from which you generate the final application in the Build phase.

Another important activity in this part of the Design phase is the cross-checks of the database design. You want to be sure that the data elements you defined in the Database Design part of Design are fully utilized and included in the set of modules you produce.

Designer/2000 facilitates this type of checking as well. Table 7 shows the activities and which Designer/2000 tool you use for them in the Design phase.

The work you do in this part of Design with the Data Schema Diagrammer is similar to the work you did in the Database Design. The main reason to use these two tools in this part of Design is to add to or modify database definitions you created earlier in the life cycle. This may happen because of something you learned or thought of when defining modules. You may also need to visit the properties windows for the database elements to more fully define the display characteristics of the columns.

The work you perform with the Module Logic Navigator in this phase consists of filling in properties for the PL/SQL module definitions. This activity can also be carried out in the Module Structure Diagrammer along with refining other types of modules since the module definition window is the same in both of these tools.

The Build phase involves two areas: the database and the application. If all of the preceding steps have been performed carefully and thoroughly, this phase should proceed smoothly. Database building involves direct generation using Designer/2000. All triggers and data structures can be kept within the physical model in Designer/2000, so the building of the database is a straightforward operation.

About the only specific work to be done at this point is final decision making regarding table space sizes and physical disk locations. Also, a final decision needs to be made as to how many copies of the database will be used. It is common practice to use three (develop, test, and production). We believe that there should be a total of five copies: one for developers to experiment with, a second copy for testing, and a third copy for production. A fourth and fifth copy can be used for additional testing. One of these would be used for small-scale testing and another for full production testing.

After generation, you should make careful use of the form-specific templates to support as many form-specific features as possible. This effort minimizes the need for additional modifications after regeneration.

Before you finish the Build phase, you must subject the system to a first-pass unit-level test. Then immediately pass the system to a tester to check that the system meets the Design Book specifications and that functionality from the user standpoint is working properly. The testing process should be meticulous, using test data, automated testing scripts, code walkthroughs, and interviews with the system developer. You also must perform overall database-level checks.

Testing is one of the most important but usually most poorly conducted phases in the system design process. The key to proper testing is to use multiple tests. No single test, no matter how carefully conducted, will find all of the errors in a system. It is better to perform several different tests less carefully; these usually catch more errors at less cost to the organization.

By the time you reach the Test phase of the development process, you should not need to audit the logical or physical design of the database. This should already have been done at the end of the Analysis and Design phases. The first goal at this stage is to audit the correctness of the applications: do they meet the requirements?

The second goal of the test phase is to perform user acceptance testing. Give users the applications to work with and perform real (not sample) transactions using the new system. Also, perform a final validation check on the user interface.

While the Test phase contains tasks that are mostly done outside the scope of Designer/2000, there are some key activities that the repository can help with. These are listed in Table 9 with the supporting Designer/2000 tools or utilities.

At some point, the finished system needs to be turned over to the users and brought into production (after user training on the new system, of course, has taken place). There are various schools of thought on implementation. The first is the "Big Bang" approach. The second is phased implementation.

The "Big Bang" approach entails pulling the plug on the old system and bringing up the new system and insisting that everyone use it. In this approach, there is no turning back. If you use this approach, it is critical that the system is well tested.

The second, more common, approach is phased implementation. Various portions of the new system are brought up one at a time, either by subject or by class of users. In most cases, running the new system in parallel with the legacy system requires double entry into both systems while the bugs are being worked out. Such an approach is clearly more costly than the "Big Bang" approach, but if something goes wrong, there is always the legacy system to fall back on.

Other important parts of the Implementation phase include devising an implementation schedule and a user training strategy. Options include training manuals, classes, and the creation of a computer-based training system (CBT). However, for all but the largest organizations, the creation of a CBT is too slow and much too costly to be effective. As the system evolves and changes, modification of the CBT is expensive and time consuming.

While there are no special activities that occur in the Implementation phase from the Designer/2000 standpoint, you can produce huge volumes of documentation of all sorts using the Repository Reports tool as well as reports you come up with based on the Designer/2000 API views. This documentation as well as the online repository can become part of the help desk reference material or even serve as part of the user documentation. The help table or files you produce in Designer/2000 can also be sources for material in this documentation. This is summarized in Table 10.

In order to ensure system success, there are several factors to keep in mind:

1. Don’t cut corners, methodologically. In the long run, this results in system failure or an inadequate system that doesn’t meet the users’ needs.
2. Audit each major deliverable and step along the way for accuracy and correctness.
3. Present deliverables to users throughout the process for feedback and approval.
4. Carefully formulate and enforce a consistent policy for change control and security.
5. Cultivate and encourage user participation throughout the process and provide adequate user support when the new system is implemented.
6. It is often easier and more efficient to design and implement several smaller system projects than one very large one.

Keeping all of these things in mind, Designer/2000 can be easily integrated with the entire CADM process presented here as it is truly a full life-cycle product. This should make system development using Designer/2000 faster, easier, more efficient, and more effective. The ultimate result will be satisfied developers, clients, and users.