Rapid Application Development (rad) Methodology Background



Download 75 Kb.
Date02.02.2019
Size75 Kb.


Rapid Application Development (RAD) Methodology
Background:

Today's business organizations have to cope with shorter product life cycles and demands for higher customer service levels. Firms that take too long to deliver products or provide products of unacceptable quality are doomed to failure. As a business (within a business), the IS department's primary function is to manufacture and support products called information systems for its customers called users. The manufacturing process: planning, analysis, design, development, and maintenance - traditionally has been called the "systems development life cycle."


The classical systems development life cycle specifies the sequence of activities required to take an IS application concept through design and development to successful deployment. The traditional software development cycle follows a rigid sequence of steps with a formal sign-off at the completion of each. 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.
In "real life" systems development, time and effort are heavily skewed towards coding. There is an apparent need to get on writing the code so that the project can get done in time to allowed, with the system debugged before it is implemented. This often results in poor planning, feeding inadequate design that does not meet business needs and requires major revisions and difficult maintenance over the life of the system. To complicate matters, there are often application systems that have been in production, in some cases, for over 15 years. Each year those creaky old systems get harder and harder to maintain and modify.
Computer-Aided Software Engineering (CASE) tools are available today to help develop applications very quickly. Along with the tools, the industry has evolved new views of the traditional systems development life cycle. The Information Engineering (from which RAD has evolved) proponents have re-defined and simplified the life cycle to 4 phases: Planning, Analysis, Design, and Construction. Other methodologies have defined similar phases. The one thing all of today's development methodologies agree upon is the need to improve the quality of the input - the user requirements. Requirements must be defined and specified in a consistent, repeatable, and structured way.
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. Encouragement and exploitation of these strengths is what is sought in RAD, rather than fight it through SSADM.
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 iteration might deliver 100% of 10%, the second iteration 100% of 25%, etc.


Joint Application Design (JAD)
Joint Application Design, or JAD, is a process originally developed for designing a computer-based system. It is mostly thought of as being a part of RAD but could be used in a number of different methodologies. It brings together business area people (users) and IT (Information Technology) professionals in a highly focused workshop. The advantages of JAD include a dramatic shortening of the time it takes to complete a project. It also improves the quality of the final product by focusing on the up-front portion of the development lifecycle, thus reducing the likelihood of errors that are expensive to correct later on.
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 ¹.

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. But eventually, having documented everything possible, the leader translates copious notes into a personal terminology. That’s 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. But 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 feedback 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 around a structured workshop session and the JAD team is the very heart of the JAD process so the selection and inclusion of individuals are critical to the overall success of a JAD project. The team consists of a mixture of skills from a variety of individuals. 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 are:

1.Very focused

2.Conducted in a dedicated environment

3.Quickly drive major requirements and interface "look & feel"

4.JAD participants typically include:

Facilitator – facilitates discussions, enforces rules

End users – 3 to 5, attend all sessions

Developers (IS experts) – 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 & technology
JAD Facilitator: The JAD facilitator is the key person in the team and is responsible for the planning, execution and managing the project- the guardian of the process. Choosing a facilitator is the first important step. He /she should be a respected, skillful leader with a good reputation within the organization – an unbiased leader who has no ties to the project. He can come from some other department or from outside the company. JAD facilitator skills do not happen by chance and the skills may have to be learnt. JAD experience is also necessary. The ideal facilitator is an individual who is excited by working with people. (That would include only between 10% and 15% of senior systems analysts.) It is not a position to be entered into lightly and not for the faint-hearted. Choosing a poor JAD facilitator may mean the difference between a good project and a poor one. It is essential that the facilitator be given the authority as well as the responsibility and will work closely with the Management sponsor to achieve the objectives of the JAD project. The facilitator will know how to handle people, to be able to get the best out of them. In addition to an aptitude for working with people, the facilitator must have the skills required to achieve the level of analysis detail expected from the workshop. That means training in the following areas: the methodology, group dynamics, basic selling skills, issue recognition, and listening skills. Good facilitators listen, recognize issues as they arise, and provide the leadership and direction to help people come together. The facilitator is responsible for ensuring that each person is heard and has an equal opportunity to influence the decision. The facilitator is also responsible for ensuring that the participants in the workshop construct a solution that everyone can live with.

Management Sponsor: For any computer project to succeed will require the backing of management. It is very important for the JAD team to have a management sponsor. The person may be a divisional head or manager of the business area that the JAD project is addressing. The sponsor must be high enough in the organization to be able to clear the calenders of the people required in the workshop. The sponsor does not have to actively participate in every JAD session but might provide motivation for commitment through a short speech at the opening of the workshop. It might be advisable to attend not only the first but also the final JAD session to review the results and make comments. The sponsor should be available throughout the period of the JAD development to solve any serious problems or issues that may arise. The JAD facilitator will work closely with the management sponsor and be kept fully briefed on progress. The sponsor can be from the end user community but also equally it may be CIO or an End user Vice President. The sponsor and has to be available for strategic direction and scoping information during the pre-workshop phase.
Information Specialists: Information specialists are there to assist the end users and develop a design according to the end users' needs. Under the direction of the JAD facilitator, Information specialists, after discussing the requirements, will need to create prototypes. So detailed knowledge is required of prototyping software. The workshop is trying to establish rapport and communications among stakeholders - including IS. Systems people need to be there to know the constraints so they can advise the business people regarding hardware and software under discussion. A good rule of thumb is one systems person for every four users. They can also advise end users on new technology or hardware that can assist in the technical implementation. They need to understand the organization and the business area involved. Information specialists should be good listeners and be able to empathize with end users. Experienced systems analysts who can use software have been excellent in this role.
Scribe: The scribe has a particularly important role in the JAD team. He/she is responsible for documenting the JAD sessions. This most be done in an interactive fashion and the scribe must work closely with the JAD facilitator. Many ideas, suggestions will be discussed. The scribe must learn to capture the important decisions made, who made them and why. It is a record of the what was discussed. Because of the skills needed to process this information laptop computers are particularly useful as they are portable. During JAD sessions it important to encourage end users to call on the scribe to "make sure that point is documented". The scribe does not have to be a DP person but requires a logical approach to handling documentation. It is the responsibility of the scribe to distribute the documentation at the end of each JAD session. It is a difficult task and not to be underestimated.
End Users: The role of end users in designing and agreeing systems is now widely accepted as essential to its ultimate success. Without end user involvement JAD will not succeed. The whole point of JAD is to bring end users and Data Processing people together in a structured environment. End users are in the workshop because of their business expertise. Business users fall into 2 categories: real end users - the people who are actually going the have to use the screens and reports to do their jobs; and representative end users - the people who think they know what's going on in the field. They are responsible for standards and methodology for the business functions they represent. It is important to get both types of users into the workshop. End users rapidly gain a sense of involvement and ownership in systems where JAD is used. This is vital to its overall success. Most important, end users get the system they want, not one which has been designed frequently so poorly for them. End users will invest the time and effort when they can see positive results. At all costs there is a need to avoid the catastrophic projects of the past with cost and budget overruns. Almost without exception every Data Processing department has at least one example of a software horror story. In the future, sound practical techniques like JAD may mean these stories will become distant memories.
Outside Experts: Outside experts are business consultants or technology consultants who can provide the expertise that may not be available in-house. For example, the workshop may need support from outside consultants for manufacturing, distribution, marketing, prototyping, organizational dynamics, and change management.
Observers: Observers are not allowed to participate in the workshop in any way. They may observe to gain some insight into the business area under investigation or to become familiar with the workshop process.
Human performance for solving a task is directly related to how a task is understood by the people attempting to solve it. Concentration on techniques to increase the understanding will increase performance. Also performance is influenced by personality and intelligence. Something can be done about intelligence by providing training. Changing a personality is much more difficult and personalities may be more easily dealt with in the open in JAD sessions than in a series of more private meetings. When JAD is introduced motivation and performance improve dramatically, because JAD focuses on analyzing the task and providing a solution, leading to the benefits in performance and motivation of the individuals taking part. This is due to the following factors:

  • Being involved in the detailed planning

  • Group dynamics

  • Obtaining results

  • Solving problems for other people

A major advantage of the JAD approach is that it allows for the simultaneous gathering and consolidating of large amounts of information. Moreover, discrepancies are resolved immediately with the aid of the facilitator. They can also provide useful information for the work


The power of JAD is in the integration of behavioral and group dynamics techniques within the structure of a soundly engineered methodology. A JAD workshop is not just a nice meeting. The workshop has a highly structured agenda with clear objectives including a mechanism for resolving open issues that often bog down the design process. The deliverables are clearly defined during the pre-workshop activities (see below) so that there can be a smooth and successful transition to the next phase in the life cycle - application design or acquisition. At a workshop at least the following components should be present:

  • Organizational mission, goals and objective statements

  • Scope

  • Known problems list

  • Improvement suggestions

Workshops are effective at all levels: enterprise, business area, application, and implementation project management. Workshops are commonly used for strategic business planning, strategic IS plans, IS architecture definition, re-engineering business processes, detailed system design, process and data modeling, and project management. The workshop may use the following techniques: risk assessment, business process modeling, workflow diagramming, prioritization, problem definition, problem/symptom reduction, enterprise modeling, affinity analysis, interviewing techniques, project scoping techniques, cost/benefit analysis and requirements definition. Some of the tools used might be: diagramming tools, spreadsheets, word processors, CASE, data dictionary.



This positive, team-building environment gives people a chance to learn from each other and to understand each other's needs and concerns. The participants will develop a common view of the project and a common language to discuss the project issues. The common language developed in the facilitated JAD workshop helps all the participants communicate and understand each other's needs so that IS can build systems that more effectively support the company's higher-level information needs.
The following is a list of activities which might occur in a JAD session, especially one oriented towards Business Process Re-engineering:

  • Assess and revise business goals and strategies

  • Create high-level process model of business

  • Identify environmental and social dependencies

  • Prioritize business functions based on mission

  • Overlay organizational chart on process model

  • Define process and interface ownership

  • List all internal and external interfaces

  • Develop workflow diagrams

  • Design quality measurement criteria

  • Agree on testing, training and change management plans

  • Define business problems and opportunities

  • Create high-level data model of major business entities

  • Level process models

  • Evaluate impact of emerging technologies

  • Evaluate potential project scopes

  • Define first-cut project scopes and initial estimates

  • Scope project

  • Expand process model

  • Collect, analyze and document problem statements

  • Determine problem causes based on process models

  • Define benefits of solving problems

  • Define project objectives

  • Generate new system requirements

  • Create problem statement/requirement statement matrix

  • Evaluate existing system for "Quick Fixes"

  • Evaluate organizational standards and guidelines

Pre-Workshop Activities


Good preparation is key to success. There is between one and three weeks of work required to prepare for a workshop. That preparation is required to:


  1. Identify project objectives and limitations: It is vital to have clear objectives for the workshop and for the project as a whole. The pre-workshop activities, the planning and scoping, set the expectations of the workshop sponsors and participants. Scoping identifies the business functions that are within the scope of the project. It also tries to assess both the project design and implementation complexity. The political sensitivity of the project should be assessed. Has this been tried in the past? How many false starts were there? How many implementation failures were there? Sizing is important. For best results, systems projects should be sized so that a complete design - right down to screens and menus - can be designed in 8 to 10 workshop days.




  1. Identify critical success factors: It is important to identify the critical success factors for both the development project and the business function being studied. How will we know that the planned changes have been effective? How will success be measured? Planning for outcomes assessment helps us judge the effectiveness and the quality of the implemented system over its entire operational life.




  1. Define project deliverables: In general, the deliverables from a workshop are documentation and a design. It is important to define the form and level of detail of the workshop documentation. What types of diagrams will be provided? What type or form of narrative will be supplied? It is a good idea to start using a CASE tool for diagraming support right from the start. Most of the available tools have good to great diagraming capabilities but their narrative support is generally weak. The narrative is best produced with your standard word processing software.




  1. Define the schedule of workshop activities: Workshops vary in length from one to five days. The initial workshop for a project should not be less than three days. It takes the participants most of the first day to get comfortable with their roles, with each other, and with the environment. The second day is spent learning to understand each other and developing a common language with which to communicate issues and concerns. By the third day, everyone is working together on the problem and real productivity is achieved. After the initial workshop, the team-building has been done. Shorter workshops can be scheduled for subsequent phases of the project, for instance, to verify a prototype. However, it will take the participants from one to three hours to re-establish the team psychology of the initial workshop.




  1. Select the participants: These are the business users, the IS professionals, and the outside experts that will be needed for a successful workshop.




  1. Prepare the workshop material: Before the workshop, the project manager (possibly the management sponsor) and the facilitator perform an analysis and build a preliminary design or straw man to focus the workshop. The workshop material consists of documentation, worksheets, diagrams, and even props that will help the participants understand the business function under investigation.




  1. Organize 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 those workshop exercises. For example, for a Business Area Analysis, what's in it? A decomposition diagram? A high-level entity-relationship diagram? A normalized data model? A state transition diagram? A dependency diagram? All of the above? None of the above? It is important to define the level of technical diagramming that is appropriate to the environment. The most important thing about a diagram is that it must be understood by the users. Once the diagram choice is made, the facilitator designs exercises into the workshop agenda to get the group to develop those diagrams. A workshop combines exercises that are serially oriented to build on one another, and parallel exercises, with each sub-team working on a piece of the problem or working on the same thing for a different functional area. High-intensity exercises led by the facilitator energize the group and direct it towards a specific goal. Low-intensity exercises allow for detailed discussions before decisions. The discussions can involve the total group or teams can work out the issues and present a limited number of suggestions for the whole group to consider. To integrate the participants, the facilitator can match people with similar expertise from different departments. To help participants learn from each other, he can mix the expertise. It's up to the facilitator to mix and match the sub-team members to accomplish the organizational, cultural, and political objectives of the workshop. A workshop operates on both the technical level and the political level. It is the facilitator's job to build consensus and communications, to force issues out early in the process. There is no need to worry about the technical implementation of a system if the underlying business issues cannot be resolved.




  1. Prepare, inform and educate the workshop participants: All of the participants in the workshop must be made aware of the objectives and limitations of the project and the expected deliverables of the workshop. Briefing of participants should take place 1 to 5 days before the workshop. This briefing may be teleconferenced if participants are widely dispersed. The briefing document might be called the Familiarization Guide, Briefing Guide, Project Scope Definition, or the Management Definition Guide - or anything else that seems appropriate. It is a document of eight to twelve pages, and it provides a clear definition of the scope of the project for the participants. The briefing itself lasts two to four hours. It provides the psychological preparation everyone needs to move forward into the workshop.




  1. Coordinate workshop logistics: Workshops should be held off-site to avoid interruptions. Projectors, screens, PCS, tables, markers, masking tape, Post-It notes, and lots of other props should be prepared. What specific facilities and props are needed is up to the facilitator. They can vary from simple flip charts to electronic white boards. In any case, the layout of the room must promote the communication and interaction of the participants.



Post-Workshop Activities


After the workshop, it is important to address and resolve the open issues generated by the workshop. A three-day workshop typically generates about 20 open issues, most of which are business issues. It is critical to get these issues out on the table for discussion and resolution before any code gets written. The facilitator and the scribe work together to finalize the workshop documentation. The project manager (management sponsor) is the client who receives the deliverables. The documentation moves forward through the organization to continue to enroll support and approvals for the development project if necessary. The design moves forward either for inclusion in a request for proposal for application software acquisition or towards a prototype or a code generation phase. It may contain details such as screen layouts and menus. The data model will contain volumes and capacities. The process model will specify transaction volumes.
If the design is taken into a prototype, there should be a series of ½-day or one-day workshops to evaluate and validate the prototype.

Workshop Benefits


  1. Builds consensus and ownership: The workshop approach will quickly achieve consensus and commitment among users - the customers of the IS function.




  1. Improves design quality: The workshop improves the quality of the deliverable of the design phase because it forces a definition of that deliverable in advance. During the workshop the participants are all focused on a common goal. Users in the workshop will have a better understanding of the business issues, the systems issues, and the volume of work to be done.




  1. Project teams get focused and stay focused: In the workshop, the participants will build a common view of the project and a common language to discuss the issues. These elements will stay with the team for the life of the project.




  1. Maximises potential of power tools: A natural partnership with modern development tools JAD helps realize the full potential of today's powerful development tools by providing high-quality input requirements quickly.




  1. 20% reduction in overall life cycle costs: In 1989, computer industry productivity expert, Capers Jones, studied 60 development projects and found:

  • Without JAD, 35% of the functionality was missed and that had an impact on at least 50% of the code - core functionality was missed.

  • With JAD, less than 10% of the functionality was missed and that had a minimal impact on the code - indicating that the core functionality was good but refinement was going on. JAD doesn't stop refinement - it helps manage it better. Those projects that used JAD combined with prototyping, did even better!



Conclusion on JAD


The information needs of our top executives are not well defined. The business climate is uncertain and changing. There is no single right answer, there is no single right system. Progressive systems departments are taking advantage of new tools and new techniques to re-engineer the way they build systems. There are new development tools, new methodologies and supporting techniques such as Joint Application Design for developing the requirements specifications for the systems our users need. To develop effective information systems today we must take the time to integrate the technical aspects of information technology and the social aspects of the organization. That's what facilitated workshop requirements analysis is all about!

Joint Requirements Planning Meetings


A combination of Joint Requirements Planning (JRP) and Joint Application Design (JAD) session can lead to high quality requirements definitions and user interface designs. Both methods use similar formats, but the objectives differ. JRP sessions may be referred to as JAD Planning sessions in other contexts.


The purpose of a Joint Requirements Planning session is to generate a complete list of the requirements for a project. The JRP group will normally include a session leader, a client executive sponsor, an end user representative, senior developers, and a scribe. One of the keys to success of JRP is to make sure that a representative of each group that holds a stake in the project is present. Every person who is a member of the JRP team must attend each meeting of the session. The meetings are normally held every day and last from two to three hours. The JRP session should accomplish each of the following goals:

  • limiting the system scope

  • defining the high-level requirements

  • defining responsibilities for each of the major pieces of the solution

  • setting a schedule of JAD sessions

  • possibly defining the project lifecycle and timeline

The JRP process produces time savings by bringing together each of the key decision makers into one room and working quickly towards very defined goals.


JRP works in coordination with JAD sessions. JAD sessions utilize rapid screen and report prototyping by the development personnel to facilitate discussion. JAD sessions confront one of the riskiest portions of custom software development: the user interface.
Both JRP and JAD sessions will produce design documents as a product of the sessions. These documents need to be prepared and should be approved by the JRP and JAD participants at the end of the sessions. These documents then feed directly into system design and code production.

JAD:

Advantages:

  • saves time

  • allows rapid development

  • improves ownership of the IS

  • can lead to creative development of design


Disadvantages:

  • requires large block of time for 18-20 people over a 2-4 day period

  • all variables need to be correct and together at the same time.



References:

http://www.creativedata.com/research/rad.html

http://www.creativedata.com/research/jad.html

http://www.franz.org/bb12.htm

http://www.bee.net/bluebird/jaddoc.htm

http://www.thehathaway.com/JPE.html

http://www.valiantsys.com/jrpjad.htm

Wood, J. & Silver, D. Joint Application Development. 2nd Ed. NY, Wiley 1995



Wetherbe, James C. "Executive Information Requirements: Getting It Right". MIS Quarterly, March 1999, p51


RAD-JAD.doc UQI116S3



Share with your friends:


The database is protected by copyright ©sckool.org 2019
send message

    Main page