Systems Development Methodology– JAD and RAD
In today's business world, time is an essential resource, which if managed efficiently contributes towards achieving the goals of the organization. Time is essential in meeting customer needs and staying ahead of your competition. The right system in place provides management with proper information for good decision making necessary to meet client needs and stay competitive. As such, there is a great need for development methodologies that support shorter and effective development cycles.
Systems development methodology is defined as a standard process followed in an organization to conduct all the steps necessary to analyze, design, implement and maintain information systems.
The traditional methodology of the systems development life cycle (SDLC) follows highly structured steps; Project Identification and Selection, Project Initiation and Planning, Analysis, Design, Implementation and Maintenance. This traditional methodology is normally used on large projects and require extensive development periods, very often lasting well over a year. They are often complicated and the results do not always satisfy the needs of users. This makes this approach very expensive taking into consideration the money, time and effort put in. Making changes to the system also very expensive. Below are some industry statistics of the SDLC
· 60% of large systems projects have significant cost overruns
· 75% of completed systems are in need of constant maintenance
· 60% to 80% of errors originate in the user requirements and functional specifications.
These observations led to the development of methodologies that included more user input and utilized shorter development periods where the focus is more on the analysis and design of systems development. Joint Application Design (JAD) and Rapid Application Development (RAD) are two of such methodologies.
Joint Application Design (JAD)
JAD is a methodology that involves the client or end user in the design and development of an application through a succession of collaborative workshops known as JAD sessions or in other words, a group information gathering technique of systems development. JAD was developed by IBM in the late 1970s originally as a process for designing computer-based systems. JAD centers more on people than on technology. By following a structured method that utilizes group dynamics, electronic software, visual aids and software modeling tools, JAD encourages a partnership between business clients, management and IS personnel. The aim is to get all groups with a stake in the project to work together by getting the team together in meeting rooms with U-shaped or round tables, white boards, overhead projectors and audio-visual tools. This allows everyone in the room to talk and be heard. By hearing each other the team is able to produce the appropriate systems requirements. Therefore JAD sessions require the right mix of people actively participating in order to achieve the goals of the session. A typical JAD session can last between four days and an entire week and is usually held away from the main office. A typical JAD team is has five to eight roles depending on the project.
The roles are:
a. Facilitator or the Session Leader
This individual organizes the sessions and keeps the group focused on the task. The facilitator is impartial and should remain neutral throughout the duration of the session to be able to effectively mediate and resolve conflicts. The facilitator makes the rules and can therefore change them if he sees fit. A good knowledge of the business processes, good interpersonal skills and an outstanding ability to organize and lead group is a must.
b. Scribe or Documentation Expert
The scribe records and documents all the sessions. The scribe is to seek clarity in meaning and is allowed to ask questions but not in any way influence discussions. Skills necessary for this position word processors or CASE tools (development tools that are used for diagramming, form and report generating) for example.
c. Project Manager
The manager who is involved in the sessions provides the team with input that relates to the organizational direction and the impacts of the system on the organization as a whole.
d. End User or Client Representatives
The end user should have good knowledge and experience in the field, are responsible for input concerning system design and are the only participants with a clear idea of how the system will be used in the work environment. As such these representatives have to command the necessary authority and have great listening ability and authority.
e. Systems Analyst
The analyst attends to learn from the users and managers to be able to better analyze the entire system. More often than not the analyst does not have a prominent role in the team dynamics.
f. IT and/or IS Representatives
This is normally made up of programmers and other developers. This group is present to assess technical feasibility and learn about future plans. For this role, the representative should be able to listen as well communicate ideas and technical information.
g. Executive Sponsor
This is usually a high-level manager or executive, who charters the project. The sponsor makes the final decisions and finances the project. Commitment of the sponsor to the project is of utmost importance not only because of his role but also as a motivating force for the rest of the team.
h. Outside Observers
These members of the team are not allowed to participate in the workshop on any level. They are mainly there to observe and gain insight into the business area under investigation or become familiar with the workshop process.
The deliverables for the project are defined in the pre-workshop activities to be able to better plan the direction and discussions of the workshop. A period of about one to three weeks is normally required to prepare for a workshop.
Some of pre-workshop activities include:
· Identifying project objectives and limitations
It is important to have clear objectives for the workshop and the project. The scope of project has to be determined to avoid scope creep. The political sensitivity of the project should also be assessed. This answers questions such as whether this been tried before and how many implementation failures have occurred and why it failed?
· Identifying critical success factors
Planning for outcome assessment helps the team judge the effectiveness and the quality of the implemented system over its entire life.
· Defining project deliverables
In general, the deliverables from a project workshop are the documentation and a design. The level and form of detail of documentation of the workshop discussions has to be defined as well as tools needed for documentation.
· Selecting participants
This in part depends on the project to be tackled but in general the participants are business users, IS professionals and outside experts for a successful workshop session.
· Preparing workshop material
This is the responsibility of the project manager and the facilitator. They perform analysis and build a preliminary design to focus the workshop. The material consists of any and everything that will help the participants understand the business function under investigation.
· Organizing workshop activities and exercises
The facilitator must design workshop exercises and activities to provide interim deliverables that build towards the final output of the workshop. The pre-workshop activities help design the workshop activities.
· Prepare, inform and educate workshop participants
All the participants should be briefed on the objectives, limitations and expected deliverables of the workshop. This normally takes place a week to a day before the workshop begins and arms participants with the knowledge needed to go into the workshop and be effective.
· Coordinating workshop logistics
Workshops are normally held off-site to avoid interruptions. It is the responsibility of the facilitator to make sure that everything needed such as audio-visual tools and stationery and the appropriate venue are obtained and ready for the participants.
After the workshop is completed, there is a need to address any issues that were generated. These need to be resolved before the system is built or revised. The facilitator and the scribe work together to finalize the documentation. The documentation then moves through the organization to garner support and commitment from the appropriate personnel to begin the project if this phase is required. The next step is building a prototype or a generating a code. This may require additional workshops to evaluate and validate the prototype before implementation.
Workshops can be expensive especially if an off-site venue is required and the venue is not owned by the organization. However the benefits of JAD far outweigh this cost.
By conducting workshops in a dedicated environment, the sessions are very focused and are able to generate major requirements and interface. There is better cooperation between users and developers. JAD has proven to be an effective tool in searching for and correcting problems during systems analysis and improving design quality. It also reduces the overall life cycle costs by 20%, which is a significant reduction since cost is almost always a priority when developing a system.
Rapid Application Development (RAD)
This application development methodology goes further than JAD in reducing the time taken to develop an application, is not always as structured as the JAD and focuses more on software development than JAD.
Rapid Application Development is defined as a methodology created to radically decrease the time needed to design and implement information systems by relying on extensive user involvement, JAD sessions, prototyping, integrated CASE tools, and code generators (in particular, object-oriented programming).
RAD is based on the concept that systems can be developed faster and of higher quality by gathering requirements through workshops or focus groups, prototyping and early, reiterative user testing of designs, use of already existing software components and less formality in reviews and other team communication
The following diagram shows the dependency relationships between the stages in the Rapid Application Development Process phases that allow the cycle period to be shortened an help be more effective.
RAD uses small integrated teams of developers, end users and IT technical resources and short iterative development cycles to optimize its goals of speed, effective informal communication, unity of vision and purpose, and simple project management. This, when compared to the traditional SDLC is shorter in delivery and offers better interaction between users and developers. Below is a diagram comparing the cycles of the two methodologies.
A main advantage of RAD over SDLC is its focus on iteration because this allows for effectiveness and self-correction and this is important because it is not always easy to get the requirements right the first time around. An important function of iteration is that each cycle delivers a functional version of the final system.
RAD manages these iterations cycles by using Time Boxing to guarantee timely releases. Therefore if the entire development falls behind schedule the scope is changed and not deadlines saving time and meeting the goal of speed.
With such a shorten cycle it is hard to believe that some compromises are not made when using RAD. In fact there are a few, RAD methodology is clearly not for every project development. RAD depends on continuous high quality production and requires the absolute right mix of methodologies, tools, personnel and management to be successful. RAD is not suitable for exploring new territory since its focus is on speed of delivery. New ideas require comparably longer durations of exploration. Therefore RAD is more suitable for tackling existing or well-known problems with the system. It also harder to measure progress and less efficient because the code is not hand crafted. RAD also may reduce features because of time boxing and software reuse and reliance on third-party components may sacrifice needed functionality, add unnecessary functionality and unwanted features.
In conclusion both methodologies, JAD and RAD are able to work best if applied under the right conditions and to appropriate development projects. Information and system needs are not always clearly and well defined and as such a lot of planning and effort has to be put in to select the best methodology for a development project, to be able to optimize the results. To develop effective information systems the technical aspects of the information technology and the social aspects of the organization must be properly integrated and this helps in a better choice of methodology for the problem at hand.
It is important to note, there is no fast rule for the type of methodology that is suitable for categories or classification of problems. Each development project is unique and peculiar, and is dependent on the business, its processes and the organization, as a whole and the choice of methodology should take this into account.
