Prototyping with Designer/2000 – Using CADM to Support RAD

Dr. Paul Dorsey, Dulcian, Inc.

                                                                                                           

Overview

In the CASE Application Development Method (CADM) from The Designer/2000 Handbook, Peter Koletzke and I expanded the original CASE method and outlined how large systems development projects should be done. The process that we described was methodical, very detailed and involved a lot of care with respect to Analysis, Documentation and Quality Control. Meticulously followed, such a process virtually guarantees that the system built will meet system requirements to the best of the abilities of the designers and developers. This process minimizes the risk of project failure but does not minimize cost. The CADM method implicitly assumes that, at project initiation, little is known about the final system requirements of how the system should work. It is an extension of the traditional SDLC intended for large project development and legacy system redesigns.

CADM represents the conceptual foundation for how to build and design systems. Within it, we identify a way of thinking about systems design, the objectives associated with each phase and how the development team can prove to themselves and the user community that the project is moving forward successfully. It is not, and should not, be considered a road map that is slavishly adhered to for every system.

There are four different criteria with corresponding goals that must be managed in any project development strategy:

Criteria

Goal
  1. Cost

Low cost

·  Time to complete system

Fast development time

·  Quality (features, bugginess)

High quality

·  Failure risk

Low risk of failure

 

These criteria interact with and influence each other. The most important thing to recognize is that it is not possible to achieve all four goals simultaneously. In the best of all possible worlds, you can, at most, manipulate three variables, thus determining the fourth. For example, as long as cost is constrained on a project (as it almost always is), you must accept that either you will not have a firm completion date or settle for a lesser quality system. If both fast development time and high quality are required, the likelihood of project failure is greatly increased. There is no way to avoid any of these four criteria on any project, large or small.

In CADM, we took the approach of minimizing risk and maximizing quality at the expense of cost and development speed. Realistically for most projects, of the four factors involved, only two goals are able to be achieved. The RAD (Rapid Application Development) CADM method discussed in this paper applies to small to medium sized projects with the main goal of the fastest possible development time and sometimes concurrently, lowest cost. However, this assumes more risk and the likelihood of accepting lower quality than with a traditional systems development approach. The chart below demonstrates the relationship among the criteria.

 

Chart 1 – Relative Relationship of RAD-CADM and CADM Criteria

 

Of course, this is a generalization. In general, what will be described here is an approach that optimizes development speed.

 

What is a RAD-CADM approach?

The RAD-CADM approach greatly abbreviates the Analysis phase of system development. Instead, an iterative development process is used to determine the requirements. This assumes that the development cost is low enough to justify building a substantial portion of the system two or three times for a lower cost than that of doing a full Analysis phase. Thus, instead of performing a full-blown Analysis phase, RAD-CADM amounts to building a series of system prototypes.

One of the problems with traditional Analysis documents is that you can ask users what they want the system to do, they tell you; but there is no guarantee that what they tell you is really what they need. It isn’t until users can actually see the system in prototype that they can intelligently assess whether the system will meet their needs. RAD-CADM overcomes this problem.

 

When can a RAD-CADM approach be used effectively?

RAD-CADM is effective when the system being built is not very large or complex. You cannot intelligently use a RAD approach with multiple complex systems interacting over a centralized generic data model. Where a RAD-CADM approach is best applied is for small to medium sized systems when doing a "rehost," i.e. porting a legacy system on a different platform to an Oracle system where similar functionality in the new system is acceptable.

Another instance where RAD is appropriate is when the new system has been recently attempted and has failed one or more times. In this situation, Analysis may have already been done. Although the existing Analysis documentation is inadequate, the users and any remaining developers who already worked on the failed system have just been through the process. They will have thought through the difficult analysis issues. The quality of the user resources has therefore been enhanced. Their knowledge can act as the analysis document.

A final instance where RAD is useful is for small systems with a small number of users. Again, the users themselves can act as surrogates for the Analysis document.

RAD-CADM is a high-risk strategy for a number of reasons:

  1. The system requirements are not laid out on paper. When a user rejects a prototype, there is no way to determine how much of that rejection is due to either:
  1. Without a formal Analysis document, user requirements may continue to change without a written document to place limits on them. The ultimate danger is building an infinite number of prototypes with no external standard by which to measure system completion. Since system scope and standards have not been clearly defined or documented, the project can go on indefinitely.
  2. Since there is no written Analysis Document to refer to, requirements can be easily forgotten. If an omitted requirement can’t be easily added to a completed system, fundamental changes to the data model will be required adding both time and cost to the entire project.

In order to avoid this situation, the following steps can be taken:

In summary, it is possible to limit the time allowed for the project by defining a finish date, use cost to limit the number of prototype iterations, and provide a model (existing legacy system) for the expected quality of the new system. These constraints will help to reduce the risk of project failure when using a RAD-CADM approach.

 

Limitations to RAD-CADM

Because we are not capturing requirements in written form, but instead, are relying on informal notes and quick application development, developers will invariably forget things that users have told them. This means that users may have to be re-interviewed about the same material multiple times. The development team may discuss a particular requirement with users and inadvertently omit it from the system. Also, users will occasionally make decisions about requirements and limitations that they are willing to accept that they will later deny. Such disagreements are inherent in the RAD-CADM approach and should be anticipated.

 

Critical Success Factors for Making RAD-CADM Work

The following factors are necessary if a RAD-CADM approach is to be successful:

  1. Carefully manage user expectations - Make sure that users are aware of the strengths and weaknesses of the approach and the reasons for using RAD-CADM. Users should be aware of the risks inherent in this type of system development. It is possible that the system will be brought to completion at which point a critical missing element is discovered. Users should also be aware of the dangers of forgetting requirements and arguing about them later as discussed above.

This management of user expectations is the key critical success factor for RAD-CADM development. It is vitally important that users are fully engaged in the development process. If the relationship between developers and users becomes less than cordial or even antagonistic, the probability of project success is greatly diminished.

  1. Highly skilled and experienced developers – RAD development should not even be attempted by an inexperienced team. This is inherently a "fly by the seat of your pants" approach. Developers must have a clear sense of the steps required to bring a project to completion. Without a certain level of developer maturity and experience, the project will lack focus, get sidetracked and not reach completion.
  2. Formal GUI, coding and development standards – For a RAD approach to be effective, it is crucial to have formal GUI, coding and development standards in place before the start of the project. Otherwise, developers must spend time making coding, user interface, etc. decisions while trying to build prototypes. This cancels out any time gains from using a RAD methodology in the first place.
  3. Know when to declare version 1 of the system complete – The whole point of RAD is to achieve version one of the system quickly. It is very important not to use a particularly high user acceptance standard. When prototypes are acceptable and functioning, the project must move forward. As long as all critical functionality has been met, version 1 is complete. At this point, user comments and suggestions should be deferred and placed into a system modification log to be used for future versions. They should not be analyzed or prioritized at this point. Version 1 should be achieved as quickly and efficiently as possible.

 

Details of the RAD-CADM Process

The following steps outline the RAD-CADM system development process:

  1. Abbreviated Strategy Phase:

Even though we are attempting to work as quickly as possible, we still need to prepare a basic Strategy Document outlining the scope, problem, approach, team roles, etc. of any project. This Strategy Document is just as critical in a RAD project as any other. The CADM concept is that the Strategy Document acts as a contract between all interested parties. For a complete discussion of the Strategy phase and Document, see The Designer/2000 Handbook by Dr. Paul Dorsey and Peter Koletzke.

  1. Analysis:

In a RAD-CADM approach, we do not prepare an Analysis Document. Instead we go directly to building the logical data model. For this to be effective, a highly skilled data modeler must be a part of the development team. Ideally, the data modeler should be able to accurately model 20 or more entities (unattributed) per day. A 100-table data model should be able to be completed in approximately one week. The attribution of such a model should take an additional week.

It is crucial to be able to complete this model quickly since it is the first deliverable presented to the users. There has been much debate about whether a data model should be delivered to a non-technical user. Users should not simply be shown the data model and asked to comment. The data model should be used as a guide for discussion of the system. Developers can describe how various business entities relate and what the limitations of the model are. They can also discuss the kind of information that can be stored.

Finally, the data model is derived from a process flow. Even if the process flow is not drawn for time constraint reasons, it can be described to the users. As part of Analysis, you may also want to create the first set of screen prototypes.

  1. Physical Data Model:

In CADM, we create a full prototype of the system prior to doing the physical design of the database. In RAD-CADM, we use our intuition about what the ultimate system design will be to move directly to the physical database design. Since we actually prototype the application, we may do further database tuning and denormalization. However, if the RAD project is going to stay on schedule, it is necessary to create an accurate data model at this point in the process.

  1. Legacy Data Migration:

If the project is a legacy system redesign, legacy system migration should begin immediately at this point so that the forms and reports will have some data to use as sample data. If the project is not a legacy system redesign, no sample data is used at this stage. Sample data will be created by prototype applications as part of the testing process. Again, it is key to be able to migrate the legacy data quickly using some type of data migration tool. In order to facilitate migration, we looked at the available tools on the market and were not satisfied. We therefore wrote our own migration utility. (A complete discussion of this tool can be found in Joseph Hudicka’s paper #103 "Data Migration and Designer/2000" also presented at this conference.)

  1. Prototyping:

Both forms and reports must be prototyped. If a legacy system redesign, report modules should be prototyped first since this will validate both the data model and the data migration. If there is no legacy data, then forms modules should be prototyped first. There are two alternatives for generating prototype modules:

Both approaches have merit and can be used effectively. The decision about which approach to use should be based upon the skills of the development team.

Developers should be able to build a form or report prototype in a few hours to one day. The idea in the early prototypes is not to include extensive functionality in modules until user feedback is obtained. Usually, the approach should be to develop a very primitive prototype without much functionality. If users are not satisfied with the first prototype, a second primitive prototype should be developed. Once users are satisfied with the basic functionality, the prototype should be built to production. Users should then be allowed a maximum of one more opportunity to critique the module. After this point, the only work that should be done is debugging.

  1. Testing and Implementation

Testing is a RAD-CADM environment is no different from that of a traditional system development life cycle with the inherent risks and decisions to be made. For a complete discussion of Testing and Implementation, see The Designer/2000 Handbook by Dr. Paul Dorsey and Peter Koletzke.

 

Conclusion

RAD-CADM provides an effective alternative to a full CADM process for small to medium-sized projects as long as the development team is skilled and has a good understanding of what the system should do before the project is started and the risks are understood and willing to be assumed. If all of these conditions are met, then RAD-CADM can be used to bring a system to production relatively quickly at a lower cost than a traditional SDLC.

©1997 Dulcian, Inc.