2read application design ibm interview jad joint participatorydesign plm productmgt projectmanagement requirements requirements_engineering requisitos software_development systemdevelopment usability

My tags:

From Wikipedia, the free encyclopedia

Joint Application Development (JAD) is a process used in the Systems Development Life Cycle (SDLC) to collect business requirements while developing new information systems for a company. "The JAD process also includes approaches for enhancing user participation, expediting development, and improving the quality of specifications." It consists of a workshop where “knowledge workers and IT specialists meet, sometimes for several days, to define and review the business requirements for the system.1” The attendees include high level management officials who will ensure the product provides the needed reports and information at the end. This acts as “a management process which allows Corporate Information Services (IS) departments to work more effectively with users in a shorter time frame.2”

Through JAD workshops the knowledge workers and IT specialists are able to resolve any difficulties or differences between the two parties regarding the new information system. The workshop follows a detailed agenda in order to guarantee that all uncertainties between parties are covered and to help prevent any miscommunications. Miscommunications can carry far more serious repercussions if not addressed until later on in the process. (See below for Key Participants and Key Steps to an Effective JAD). In the end, this process will result in a new information system that is feasible and appealing to both the designers and end users.

"Although the JAD design is widely acclaimed, little is actually known about its effectiveness in practice." According to Journal of Systems and Software, a field study was done at three organizations using JAD practices to determine how JAD influenced system development outcomes. The results of the study suggest that organizations realized modest improvement in systems development outcomes by using the JAD method. JAD use was most effective in small, clearly focused projects and less effective in large complex projects.

Contents 1 Origin 2 Key participants 3 9 Key Steps 4 Advantages and disadvantages 5 References 6 External links

[edit] Origin

“Joint Application Design (JAD) was developed by Chuck Morris of IBM Raleigh and Tony Crawford of IBM Toronto in the late 1970’s. In 1980 Crawford and Morris taught JAD in Toronto and Crawford led several workshops to prove the concept. The results were encouraging and JAD became a well accepted approach in many companies. In time, JAD developed and gained general approval in the data processing industry^{[citation needed]}. Crawford defines JAD as an interactive systems design concept involving discussion groups in a workshop setting. Originally, JAD was designed to bring system developers and users of varying backgrounds and opinions together in a productive and creative environment. The meetings were a way of obtaining quality requirements and specifications. The structured approach provides a good alternative to traditional serial interviews by system analysts.

[edit] Key participants

Executive Sponsor: The executive who charters the project, the system owner. They must be high enough in the organization to be able to make decisions and provide the necessary resources and support for the project. They must be at the meetings daily to ensure the group remains on course and de-conflict any arguments early which can not be solved by the facilitator.

Project Leader/Manager: Generally the leader of the application development team answers questions about the project regarding scope, time, coordination issues and resources. They may contribute to the sessions as long as they do not inhibit the participants. They will remain in contact with the Executive Sponsor daily.

Facilitator/Session Leader: Chairs the meeting and directs traffic by keeping the group on the meeting agenda. The facilitator is responsible for identifying those issues that can be solved as part of the meeting and those which need to be assigned at the end of the meeting for follow-up investigation and resolution. The facilitator serves the participants and does not contribute information to the meeting.

Scribe/Modeller/Recorder/Documentation Expert: Records and publish the proceedings of the meeting and does not contribute information to the meeting.

Participants: Customers in the business area directly or indirectly being affected by this project, who are experts in their field and can make decisions about their work. They are the source of the input to the session. They must be experienced in their fields for at least 5 years with expanded knowledge.

Observers: Generally members of the application development team assigned to the project. They are to sit behind the participants and are to silently observe the proceedings.

[edit] 9 Key Steps

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.
2. 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.
3. 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 diagramming support right from the start. Most of the available tools have well to great diagramming capabilities but their narrative support is generally weak. The narrative is best produced with your standard word processing software.
4. 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.
5. Select the participants These are the business users, the IS professionals, and the outside experts that will be needed for a successful workshop. These are the true "back bones" of the meeting who will drive the changes.
6. Prepare the workshop material Before the workshop, the project manager 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.
7. 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.
8. Prepare, inform, 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.
9. 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.2

The workshops need enough computers to ensure the right personnel have the means to validate or dispute any discussions.

[edit] Advantages and disadvantages

Compared with traditional methods, JAD may seem more expensive and can be cumbersome if the group is too large relative to the size of the project. Many companies find, however, that JAD allows key users to participate effectively in the requirements modeling process. When users participate in the systems development process, they are more likely to feel a sense of ownership in the results, and support for the new system. When properly used, JAD can result in a more accurate statement of system requirements, a better understanding of common goals, and a stronger commitment to the success of the new system.

A drawback of JAD is that it opens up a lot of scope for inter-personal conflict.

[edit] References

1. Haag, Stephen; Maeve Cummings, Donald J. McCubbrey, Pinsonneult, and Donovan (2006). "Phase 2: Analysis". Information Management Systems for the Information Age. McGraw-Hill Ryerson. ISBN 978-0072819472. 
2. Jennerich, Bill (November 1990). "Joint Application Design: Business Requirements Analysis for Successful Re-Engineering". http://www.bee.net/bluebird/jaddoc.htm. Retrieved on 2009-02-06. 
3. Yatco, Mei C. (1999). "Joint Application Design/Development". University of Missouri-St. Louis. http://www.umsl.edu/~sauter/analysis/JAD.html. Retrieved on 2009-02-06. 
4. Soltys, Roman; Anthony Crawford (1999). "JAD for business plans and designs". http://www.thefacilitator.com/htdocs/article11.html. Retrieved on 2009-02-06. 
5. Dennis, Alan R.; Glenda S. Hayes, and Robert M. Daniels, Jr. (Spring 1999). "Business process modeling with group support systems". Journal of Management Information Systems 15 (4): 115-142. http://www.jmis-web.org/articles/v15_n4_p115/index.html. 
6. Botkin, John C.. "Customer Involved Participation as Part of the Application Development Process". http://wwwsgi.ursus.maine.edu/gisweb/spatdb/amfm/am94001.html. Retrieved on 1999-11-09. 
7. Moeller, Walter E.. "Facilitated Information Gathering Sessions: An Information Engineering Technique". http://principlepartners.com/html/articles.html#facilinfo. Retrieved on 1999-11-09. 
8. Bill Jennerich "Joint Application Design -- Business Requirements Analysis for Successful Re-engineering." 18:50, 26 June 2006 (UTC)[1] Last update time unknown. Accessed on Nov. 14, 1999.
9. Gary Rush "The History of JAD -- MGR Consulting Newsletter." July 2006 [2]
10. Davidson, E.J. (1999). Joint application design (JAD) in practice. Journal of Systems & Software, 45(3),215-223. Retrieved from Scienc Direct Database.

• Wood, Jane and Silver, Denise; Joint Application Development, John Wiley & Sons Inc, ISBN 0-47104-299-4

[edit] External links

• "JAD" a description of JAD
• "[3]" Definition of JAD