Software Development

Spectrum utilizes a Rapid Application Development (RAD) methodology combined with a Joint Application Design (JAD) process. RAD is a methodology for compressing the analysis, design, build, and test phases into a series of short, iterative development cycles. This has a number of distinct advantages over the traditional sequential development model. RAD projects are typically staffed with small-integrated teams comprised of developers, end users, and IT technical resources. Small teams, combined with short, iterative development cycles optimizes speed, unity of vision and purpose, effective informal communication and simple project management.

The traditional software development cycle follows a rigid sequence with a formal sign-off at the completion of each step. A complete, detailed requirements analysis is done that attempts to capture the system requirements in a Requirements Specification. Users are forced to 'sign-off' on the specification before development proceeds to the next step. This is followed by a complete system design and then development and testing.

But, what if the design phase uncovers requirements that are technically unfeasible, or extremely expensive to implement? What if errors in the design are encountered during the build phase? The elapsed time between the initial analysis and testing is usually a period of several months. What if business requirements or priorities change or the users realize they overlooked critical needs during the analysis phase? These are many of the reasons why software development projects either fail or don’t meet the user’s expectations when delivered.

Rapid Application Development, or RAD

RAD is a methodology for compressing the analysis, design, build, and test phases into a series of short, iterative development cycles. This has a number of distinct advantages over the traditional sequential development model.

Iteration allows for effectiveness and self-correction. Studies have shown that human beings almost never perform a complex task correctly the first time. However, people are extremely good at making an adequate beginning and then making many small refinements and improvements. RAD interactive development further capitalizes on this concept.

RAD projects are typically staffed with small-integrated teams comprised of developers, end users, and IT technical resources. Small teams, combined with short, iterative development cycles optimizes speed, unity of vision and purpose, effective informal communication and simple project management.

An important, fundamental principle of iterative development is that each iteration delivers a functional version of the final system. It is a properly engineered, fully working portion of the final system and is not the same as a prototype. For example, the first site ration might deliver 100% of 10%, the second iteration 100% of 25%, etc.

Joint Application Development, or JAD

The JAD process does for computer systems development what Henry Ford did for the manufacture of automobiles (a method of organizing machinery, materials, and labor so that a car could be put together much faster and cheaper than ever before – the assembly line). The goal in systems development is to identify what the users really need and then set up a system or process that will provide it. Traditional methods have several built-in delay factors that get worse as more people become involved. The following description of the Traditional Systems Design process is from 'Joint Application Development' by Jane Wood and Denise Silver. It may sound familiar.

In most organizations, the systems development life cycle begins with the identification of a need, assignment of a project leader and team, and often the selection of a catchy acronym for the project. The leader pursues a series of separate meetings with the people who will use the system or be affected by it. The leader continues these meetings over time. Often the key people involved are not so easy to reach. However, eventually, having documented everything possible, the leader translates copious notes into a personal terminology. That is when it becomes apparent that the requirements from, say Accounting, don’t mesh with what the Sales department wants. So the leader calls Sales and finds out the contact there is in the field and will not be back until tomorrow. Next day the leader reaches Sales, gets the information, calls Accounting, and of course the person in Accounting is now out of the office, and so on.

When everyone is finally in agreement, alas, the leader discovers that even more people should have been consulted because their needs require something entirely different. In the end, everyone is reluctant to 'sign off' on the specifications.

Other times, signing off comes easily. However, when the system is delivered, it often has little to do with what the users really need:. 'A user sign off is a powerless piece of paper' when matched against the fury of top management.

Slow communication and long response time is one reason the traditional process is so time-consuming. You can see why the communication problem grows worse as more people must be brought into consensus.

JAD centers on a structured workshop session. Everyone gets together in a room and talks it out. Everyone hears what the rest of the group has to say. There’s no delay between question and answer, no 'telephone tag' or waiting for memos to come back. JAD eliminates many of the problems with traditional meetings. Meetings are not well regarded as a productive form of work. JAD turns meetings into workshops. They are less frequent, more structured, and more productive. An agenda provides the structure, a facilitator directs the process, visual aids clarify concepts being discussed and the group dynamics, with constant feedback, stimulates creativity.

JAD Sessions

JAD sessions are:

• Very focused
• Conducted in a dedicated environment
• Quickly drive major requirements and interface 'look and feel'

JAD participants typically include:

• Facilitator – facilitates discussions, enforces rules
• End users – 3 to 5, attend all sessions
• Developers – 2 or 3, question for clarity
• Tie Breaker – Senior manager. Breaks end user ties, usually doesn’t attend
• Observers – 2 or 3, do not speak

Subject Matter Experts – limited number for understanding business and technology.

© 2002 Spectrum Informatics, Inc All Rights Reserved.