This action might not be possible to undo. Are you sure you want to continue?
No JAD JAD is not quality-centered, but more communication-focused. JAD expects improving the communication processes will result in higher product quality the customer must be able to visualize the product as they are inti directly participating in it's design JAD is user centred design JAD need directly communication with user To use JAD, the customer has to be able to visualize the software since they participate directly Joint Application Design is goal driven QFD QFD is "an overall concept that provides a means of translating customer requirements into the appropriate technical requirements for each stage of product development and production QFD, the customer is seen solely as a source of initial requirements. QFD is quality centred design QFD doesn’t need direct communication with the user. This isn’t necessarily true for QFD. Quality Function Deployment (QFD) tries to apply the concept of total quality management to software development QFD results in documented requirements
Similarities Both the JAD and QFD approaches use group session techniques, however they are only a component of QFD. As with any group session approach, they both require facilitators to make the team interactions successful. As well both concentrate on customer involvement during the RE stages of the project • Both are group session techniques • Both require facilitators • Both require the project team to work with the customer • JAD differs from QFD in that it is not quality-centered, but more communicationfocused.JAD expects improving the communication processes will result in higher product quality. QFD on the other hand, makes quality an explicit goal, rather than a byproduct of the process. • Unlike QFD, JAD is specifically designed for the development of large computer systems. The goal of JAD is to involve all stakeholders in the design phase of the product via highly structured and focused meetings. Typical participants in the
session include a facilitator, end users of the product, main developers, and observers. In the preliminary phases of JAD, the requirements-engineering team is tasked with fact finding and information gathering. Typically, the outputs of this phase, as applied to security requirements elicitation, are security goals and artifacts. The actual JAD session is then used to validate this information by establishing an agreed-upon set of security requirements for the product. • Allows key users to participate effectively • 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 Disadvantages • More expensive and can be cumbersome if the group is too large relative to the size of the project Guidelines for successful JAD • Use experienced and skilled facilitators • Get Executive sponsor’s commitment and support • Get the right person to participate • Set clear, well understood and obtainable goals • Plan detailed agenda and stick with it • Define deliverables clearly in advance • Keep technical jargon to minimum • Produce final document quickly Roles in JAD • Session Leader (Facilitator) Expert at and committed to the process Excel at group processes (forming, norming, storming, performing) Needs to be trained – first choice, not last • Scribe Ensures comments, issues, facts, decisions, questions are recorded (verbatim where possible) Excels at the tools – CASE, Word Active participant – seeking clarity on wording and meaning • User Representatives Must have knowledge, authority, experience Good listener • IT Representatives Good listener Contributes technical information • Executive Sponsor Pays the bills Makes the final decisions on issues •
HOW JAD TEAM SELECTED • Selecting an Executive Sponsor Right personality Strong influence in the organization Must have authority to make decisions Not afraid to make decisions Selecting a Facilitator o Must be impartial o For system development project, the facilitator ideally comes from neither the user area nor the programming department. Ex. IBM’s concept called the Development Center or place JAD staff in a group separate from IS. o Communicate well o Lead groups Selecting a Scribe • Good working knowledge of the business area Good analytical skills Expertise in JAD documentation tool Good notes taking skills Good technical writing skills Clear handwriting
Selecting Participants Commitment is essential It’s a balancing act Want enough people to have full representation and decision power in all areas but at the same time must keep the session small enough to be productive. For systems development project, a suggested ratio is five users to two IS people. Selecting Observers Should not be involved in any of the decision making Allow them to answer questions, but nothing more. Muzzle them completely.
Five Phases of JAD
1. JAD Project Definition 2. Research
3. Preparation 4. The Session 5. The Final Document When is JAD used According to Hathaway & Associates the JAD can be used in Requirements gathering Business rules Data Modeling Process Engineering Business Analysis Workflow Modeling Quick Fix Design Test Case Identification Test Planning JAD TASKS 1. Identify all stakeholders and clarify executive goal. 2. Scope out the general requirements (project mission and product features) from each of the users' perspectives (business abstract). 3. Reconcile each user's view of the product with the executive goal into one summary (project abstract). 4. Define the interaction of the product with users, other products or systems, and the organization (context diagram). 5. Concur on business justification, time box, and cost box for project (preliminary business plan). 6. Define the ways in which the users will interact or use the new product (use cases). Collect samples of desired inputs and outputs from users. Stick to business processes first, then drill down for data needed and known ("knows and does" list) 7. Prioritize the use cases by collective user preference and risk (Delphi technique). 8. Validate and review the use case scenarios. 9. Organize the use cases, constraint, assumptions, and other requirements into a rigorous Software Requirements Specification (SRS). 10. Design (with technical help) the screen and report layouts. Prototypes are handy for this. • • • WEAKNESS Could require more than one JAD sessions Strong, opinionated users could dominate Not suitable for highly computational systems Requires key users to attend STRENGTH Reduces cost and saves time •
• Simultaneous input from key users • Conflicts and discrepancies can be identified • A sense of system ownership • Suits projects with tight timelines and schedules • Improved System quality and productivity Enhanced communication and relationship between business users and IT professionals Quality Function Deployment (QFD) QFD is uses the method of 'House of Quality’, which is centered, around a matrix that shows the relationship between the customer requirements and the proposed product features. In QFD the customer requirements provide a central theme and are used as a basis for setting targets for the design and implementation. QFD is split into 4 iterative phases in software engineering: product planning, design planning, process planning, production planning. For phase 1, the steps of putting the planning matrix together are: • State the product requirements in customer terms. • List the 'product features' across the top row of the matrix. • Develop the 'relationship matrix'. • Add the market evaluation. • Produce a comparison of the final product control characteristics against the performance of the competition. • Use the analysis from step 5 and the customer importance rating from step 4 to identify the selling points for the proposed product. • QFD team identifies the actual measurable targets, which must be achieved. • Select product control characteristics that are to be deployed through the remainder of the QFD process. Difference between JAD and PD S.No JAD PD PD has a strong usability focus Limitations of PD • It’s good for in-house design but it faces significantly greater challenges and obstacles in the development of mass-produced off-the-shelf software applications and systems. existing organizational structures may not support development practices
PD also is concerned with handling issues that arise within the workplace such as employee -
JAD is a structured process JAD represents a movement toward more collaborative practices to enhance the viability of given goals. Users are information source in JAD JAD vs. PD •
management communication and power structures PD is learning by doing PD represents a movement toward more technical practices to enhance the viability of given social goals Users are critical role in PD
Similarities Support direct communication between designer and user User centered design
PD Participatory Design (PD) is a set of diverse ways of thinking, planning, and acting through which people make their work, technologies, and social institutions more responsive to human needs. The Purpose of PD • Give users a voice in the design process • Enable technical and non-technical participants to participate equally • Provide an opportunity for developers to meet, work with and understand their users • Provide a forum for identifying issues • Provide an opportunity to get or enhance user buy-in • Increase the productivity Communication in PD User's Present Work New System Technological options
1 Relevant structures of users’ present work UNDN
2 Visions and design proposals UNDN
3 Overview of technological options DN
4 5 Concrete experience with users’ present Concrete experience with new work system UHDN UN
6 Concrete experience with technology options DHUN
PD in North America • PD is not widely used in North America Organization Structure Culture High initial costs and time • ETHICS (Effective Technical and Human Implementation of Computer-based Systems) 12 steps approach covers the whole life of a development project • Specify Work Mission • Describe Present Work Activities and Needs • Consider Job Satisfaction • Decide what needs to change • Set Efficiency, Effectiveness and Job Satisfaction Objectives • Consider Organizational Options • Reorganize: Principles for good organizational design • Choose a Computer System • Train Staff • Redesign Jobs • Implementation • Evaluation Research in the 1990s on how to facilitate a participatory design process in which endusers can influence the system focus on user involvement in the actual design process. Guidelines for PD (1) • Respect the users of technology, view every participant in a PD project as an expert in what they do, as a stakeholder whose voice needs to be heard. • Recognize that workers are a prime source of innovation • View systems as networks of people, practices, and technology embedded in particular organizational contexts. • Understand the organization and the relevant work on its own terms, in its own settings. • Be conscious of one's own role in PD processes; try to be a "reflective practitioner." • Address problems that exist and arise in the workplace, articulated by or in collaboration with the affected parties, rather than attributed from the outside. • Find concrete ways to improve the working lives of co-participants
• • • • • • •
Ensure you have a thorough knowledge of the problem domain—what systems are currently in use and what are the workplace issues? Ensure you have considered at least one potential solution. You may or may not present this solution during the workshop. Prepare scenarios. Prepare an agenda. Ensure that you understand clearly the purpose of each agenda item, and the techniques you will use to achieve it. Confirm attendees and ensure all participants are notified of dates and times. If appropriate, send out a short kit explaining what will happen in the workshop. Book an appropriate room—participants must be comfortable during the workshop. Ensure the room has flipchart, sufficient table space, and a whiteboard. Ensure you have all materials required—Butcher's paper, pens, sticky notes.
The current goals of PD are twofold: to engage people at all organizational levels in the discussion of existing user practices and, to involve users in the subsequent design of technological systems and workplace environments. PD for mass product design • Problem The development team is only responsible for implementing the design idea • Resolution Users participate in product definition and product development Developers participate in creating the product definition PD for mass product design – challenges • • • • Motivating the Developers to work with users Identifying Appropriate Users Obtaining and Motivating Users Properly Utilizing Potential users
Conclusion of PD • • • • Support to articulate the product concept Support analyze the problem situation from users Support communication between people Identify quality attributes of efficiency, effectiveness and satisfaction RAD RAD is more concerned with speed RAD is more tools dependent RAD results in the completed system
Difference between JAD and RAD S.No JAD
RAD is more technical centred What is RAD? Rapid Application Development RAD is a way of developing a system by completing an initial working part of the system, and then incrementally adding to it every few months. Instead of waiting to finish the entire system, the system owners can put the system into use earlier. Development tools such as visual programming and computer-assisted software engineering help with RAD. Comparing these two is a bit of a mismatch since SQFD really only applies to the requirements engineering stage. While building a working prototype is sometimes part of a requirements engineering effort, RAD results in the completed system, while SQFD results in documented requirements. Even applying Betts' application of QFD to software so that it does cover the complete software development life cycle, there are more differences than similarities • RAD is a way to deliver systems very fast The longer a project, the greater its likelihood of failure • It is a lightweight approach • Uses proven technology effectively • Make the solution fit within the capabilities of the tools (hammer?) • RAD is not Quick and Dirty with a thin veneer of discipline • RAD operates where the 80 / 20 rule applies • RAD can’t be used in all situations • RAD (rapid application development) is a concept that products can be developed faster and of higher quality through: • Gathering requirements using workshops or focus groups • Prototyping and early, iterative user testing of designs • The re-use of software components • A rigidly paced schedule that defers design improvements to the next product version • Less formality in reviews and other team communication
When to use RAD?
• • • • • • Business objectives are well defined and narrow Data for the project already exists Decisions can be made by a small number of people The project team is small (6 or less) The technical architecture is defined and clear and the key technology components are in place and tested Technical requirements are reasonable and well within the capabilities of the technology being used.
People – Hybrid Teams
• • Team size: about 6 Spend on their training
• • • • • • •
Includes full-time user Co-locate if possible Multi-talented developers: fulfill all roles
JAD and JRP as necessary Frequent tangible working results (echoes of XP?) Evolutionary Prototyping RAD is agnostic about techniques as long as they are proven and focused
Management • RAD usually assumes that the requirements phase is done as usual (Cross) • Timeboxing – visibility (McConnell 96) • Based on the Boehm Spiral lifecycle (Cross) • Customer sees results regularly • Compress the tasks and deliver often Tools • CASE tools • From Excelerator to Rose • Round trip tools • Version control • Visual prototyping • Team scheduling – collaboration • Automated testing • Code generation Similarities • RAD is a way to deliver systems very fast The longer a project, the greater its likelihood of failure • It is a lightweight approach • Uses proven technology effectively • Make the solution fit within the capabilities of the tools (hammer?) • RAD is not Quick and Dirty with a thin veneer of discipline • RAD operates where the 80 / 20 rule applies • RAD can’t be used in all situations RAD (rapid application development) is a concept that products can be developed faster and of higher quality through: • Gathering requirements using workshops or focus groups • Prototyping and early, iterative user testing of designs • The re-use of software components • A rigidly paced schedule that defers design improvements to the next product version • Less formality in reviews and other team communication Pros and Cons of RAD
Pros Good systems fast Good use of proven technology • Cons Lacking rigor, leading to systems that do not scale Raise expectations to unreasonable levels JAD vs. RAD • Similarities Users and designers are working together
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue listening from where you left off, or restart the preview.