Classical Methodology

The Waterfall methodology is used when the customer has a detailed understanding of the system requirements, and it is possible to create a System Specification within a reasonable effort, and therefore cost.  Systems built with this methodology are usually billed hourly in the Requirements/Analysis phases.  The project can be billed fixed cost from the creation of the System Specification Document (SSD - the System Architecture and Design) through the later phases that lead to final delivery of the system and ending with System Test.  The SSD will usually contain the details required to build the system including a proposed cost and schedule.

Advantages of Classical Methodology:

1. Known cost and schedule after creation of the System Specification Document (SSD).
2. The SSD documents the system as designed.  This may be very important for companies needing to list assets for purposes of company buyouts, annual reports, etc.
3. There is ample documentation on how to proceed with this methodology.  It has a long history of success in the computer industry.

Disadvantages of Classical Methodology:

1. Changes and additions are contractual changes requiring formal customer approvals and contract revisions. Costs must be renegotiated if changes are made after construction has begun. 
2. Users must wait until the end of the project, or at least until a major portion of it is complete, before seeing the results.
3. The early phases of the project may take longer than the RAD approach (defined below) due to the time required to generate the detail necessary in the SSD for a software group to create the system.

RAD Methodology

The graphic below illustrates a typical chain of RAD process events.  Note that the left side dotted line from 'Object Creation' through 'Return to Brainstorm, Requirements, Analysis' is optional.  If the system designers are well versed on the system requirements then the first RAD deliveries may not have to be redesigned.

Image Courtesy of James P. Greichen

RAD is the process of creating a new software system by involving the user community in all phases of the system creation.  It implies a user driven design.  Deliveries of the system are broken into several milestones, each containing more system components than the previous milestone delivery.  The first delivery is usually a prototype of the complete system to include system flow from form to form to report, etc.  All appropriate users have a chance to review each delivery before work commences on the remainder of the system.  User input to changes is a core requirement to the success of this methodology.  RAD facilitates early user acceptance, and ensures that all important users of the system have input to system functionality before its final delivery.  RAD development is an important tool in the risk management of a custom software system.

RAD is a manifestation of Vilfred Pareto's law known as the 80 - 20 Rule.  It states that 80% of XX is caused by 20% of YY.  More specifically, 80% of the costs of a complete system are due to 20% of the features included in the system.  Conversely, 20% of the system costs are due to 80% of the system features.  RAD methodology allows the most important 80% of the system features to rise to the top of the list and be integrated into the system - at a cost of 20% of the complete system.

RAD lends itself to an hourly billing, however, it can also be used in a fixed cost environment if the customer agrees to a limited amount of RAD deliveries and repetitions (hours).

The following further describes the RAD Methodology:

• It is important that a contract that is agreeable and beneficial to both sides is signed before any work begins.  If the project does not present a 'Win - Win' situation for both parties, then it is not in the best interests of at least one party to proceed further.
• Once the contract is signed, the Brainstorm, Requirements, and Analysis steps may be repeated until enough information is known to create a prototype. 
• The prototypes are mock ups at this stage, and may be completely thrown out if necessary.  Code is not deliverable quality.  The prototypes will usually change significantly after user feedback, and the impact of these changes are minimized if the prototypes are bare bones - for visual and navigational demonstration only.
• The Object Creation and User Review steps can be repeated multiple times until the system is correct and accepted by the user community.  Objects might include data entry forms, high profile management reports, engineer reports, etc.  In order to meet tighter schedules, it is important for the group of users that are reviewing the prototypes to commit to timely feedback.  In this methodology, the project schedule is often driven by the time taken by the user community to review deliveries.
• Optionally, if the User Review step results in fundamental changes in the direction of the system, the Brainstorm, Requirements, and Analysis steps can be repeated as depicted in the diagram above.
• Once all of the above steps are completed to the acceptance of the user community, the system code is finalized in preparation for final delivery.
• The system is delivered (with all documentation ), installed, and configured.   Users are trained, and the system moves into maintenance mode.

Advantages of the RAD methodology:

1. Flexible and adaptable to changes.
2. Prototyping applications gives users a tangible description from which to judge whether critical system requirements are being met by the system.  Report output can be compared with existing reports.  Data entry forms can be reviewed for completeness of all fields, navigation, data access (drop down lists,checkboxes, radio buttons, etc.).
3. RAD generally incorporates short development cycles - users see the RAD product quickly.
4. RAD involves user participation thereby increasing chances of early user community acceptance.
5. RAD realizes an overall reduction in project risk.
6. Pareto's 80 - 20 Rule usually results in reducing the costs to create a custom system.

Disadvantages of RAD methodology:

1. Unknown cost of product.  As mentioned above, this problem can be alleviated by the customer agreeing to a limited amount of rework in the RAD process.
2. It may be difficult for many important users to commit the time required for success of the RAD process.

Methodologies Glossary

Contract - projects always begin with this step.   A contract is necessary to protect both parties entering into the new business relationship.  The contract used by 21st Century Technologies, Inc. is very straightforward, and incorporates the experience of many business relationships, projects, etc.  Just email us for a copy of the contract to create a custom software system for your company.

Brainstorm - this part of a project is the most important in terms of the overall feature set of a system.  All ideas are thrown onto the table, and all interested parties are invited to provide input.  No ideas are removed in this stage since the complete system picture has not yet been decided upon.   There will be a time to pare out features from the system, but this is not the time to do it.

It is extremely critical that all users of the system participate in this step of the system design process.  Many times important personnel are left out, and it isn't until system deliveries are made that their input is requested.  This may mean that major changes or additions have to be made to the system due to the lack of proper user input.  The RAD methodology described above helps to alleviate this problem.

It is the Brainstorm phase where all information about the system's desired components is gathered.  Hardcopy reports, hand drawings of desired user data entry forms, existing algorithms (salesperson commission structures, Product Yield calculations, etc.), desired charts, performance criteria (15 messages per second, no more than 20 images per report, etc.) are all gathered here for later organizing.

Requirements - this phase results in a formal list of features that the new system will contain.  These features are usually contained in a System Requirements Document (SRD).  This document is used as the baseline for creation of the System Specification Document (SSD) described below.  The Requirements phase (and the SRD) is very important in the RAD methodology since a System Specification Document will probably not be created.

Analysis - this phase of a project is where algorithms are refined, data structures are investigated, options are reviewed and prioritized, relative complexities (and therefore costs) are reviewed.  The results of this effort will drive the outcome of the eventual system architecture defined in the Specification step below.  See our Checklist page for a list of items to kickstart this effort.

Specification - this phase of a project formalizes the system as determined by all previous steps, resulting in a System Specification Document (SSD).  It is the system design and architecture.  The quality of this document will determine the resulting quality of the system itself.  The RAD methodology doesn't incorporate this step since the system requirements themselves may be in a state of flux.  The system architecture is determined through user interaction rather that through a formal document.

Coding - this is where the system engineers, programmers, network engineers, etc. create the system.  They are given discrete tasks to create specific parts of the system.  This step is tightly woven into the next step...

Module Test - code created by the programmers is tested at the module, or procedure level.  A module is a discrete set of code that (ideally) performs one specific task.  All procedures will be tested as stand-alone units, and all interfaces with other units will be tested as much as possible.   Although much testing will be performed here, the System Testing step is the most critical to the success of a new software system.  It is described below.

System Test - this is where all individual code units are placed into a cohesive system and tested in the real- world environment.   Many problems inherent in the real-world cannot be simulated in the programmers test environment.  For this reason, the system is not considered to be delivered after the Module Test phase.  System Test is the final phase of testing of the new system.   Depending on the level of complexity of the new system, the external interfaces to other software or operating systems, hardware dependencies, users involvement in the previous stages of the project, etc. this part in the process may require more time than the coding and module test phases.   Documentation is written after this step is completed and the system is delivered after System Testing is complete.

Maintenance - can be done by 21st Century Technologies, Inc. or by the customer themselves.   Many times the customer wants to make their own changes to the delivered software system.   If the customer desires that  21st Century Technologies, Inc. do all changes to the delivered system, then a separate maintenance contract can be signed for this purpose.