Assignment:1 Submitted By:Ishwar Dhungana CRN:21,HIST College Submitted to : Er.

Sunil Paudel

Date:Thrusday,June 10, 2010

1. Joint Application Development(JAD):

Definition of JAD Joint Application Development (JAD) is a process that accelerates the design of information technology solutions. JAD uses customer involvement and group dynamics to accurately depict the user's view of the business need and to jointly develop a solution. Before the advent of JAD, requirements were identified by interviewing stakeholders individually. The ineffectiveness of this interviewing technique, which focused on individual input rather than group consensus, led to the development of the JAD approach. JAD offers a team oriented approach to the development of information management solutions that emphasize a consensus based problem-solving model. By incorporating facilitated workshops and emphasizing a spirit of partnership, JAD enables system requirements to be documented more quickly and accurately than if a traditional approach were used. JAD combines technology and business needs in a process that is consistent, repeatable, and effective.

When to use JAD

Project Types
JAD can be successfully applied to a wide range of projects, including the following: New systems Enhancements to existing systems System conversions Purchase of a system

Project Characteristics
Not all projects, however, are good candidates for JAD. An appropriate project exhibits at least some of the following characteristics: Involves many groups of users whose responsibilities cross traditional department or division boundaries

Is considered critical to the future success of the organization Involves willing users Is a first-time project for the organization Has a troubled project history or relationship between the systems and user organizations

Although the characteristics above describe a good JAD candidate project, all the characteristics should not be present in your first JAD projects. As the development team and the customer become more comfortable with the JAD approach, more complex projects can be undertaken.

Generic JAD Life Cycle

Planning/Definition
To complete the Planning stage, perform the following tasks: the executive sponsor. Establish the need for the system. Select team members for the definition component. Define the scope of the session. These are generic stages of a JAD and do not indicate any specific methodology. Many books have been written on JAD, and each tends to describe JAD stages and phases in its own way, but the concepts are similar.
Designate

Planning and Definition can be combined if the scope of the project is small. The deliverables from the Definition stage can be completed by conducting a JAD session with high?level managers. It is possible to have a Finalization phase after Planning and Definition that sells the business and leads to the Planning stage of the actual project. The starting point for any JAD process is the designation of an executive sponsor. During the Planning phase, the facilitator should be working closely with this sponsor to provide an orientation to the JAD process and JAD environment. The executive sponsor's full commitment to the project is critical to its success.

Preparation To complete the Preparation stage, you must perform the following tasks:
Schedule Conduct

design sessions. orientation and training for design session participants. Prepare the materials, room, and software aids. Customize the design session agenda. Conduct the kickoff meeting. After the scope is set, the design sessions are scheduled and the participating team members are informed.

In most cases, a particular technique or methodology will be followed in the JAD sessions. To ensure participation, the customer must be educated in the terminology that will be used and the deliverables that will be created in the JAD sessions. Other preparation tasks include preparing the room with the proper equipment (PC, workstation, overhead projector, flip charts, markers, white boards, and so forth), obtaining any software aids, and preparing the reference materials and definition documentation that will be referenced throughout the design sessions. An agenda is also prepared so that the objectives for each design session are clearly stated and the participants can stay focused on the work to be done. The final Preparation step is the kickoff meeting, at which the executive sponsor addresses the team members and shows support for the JAD effort. This meeting is a key component of JAD. In organizations using JAD for the first time, the meeting will minimize resistance within the customer's organization and kindle a spirit of teamwork. A high level explanation of the JAD process is given, preferably by the executive sponsor. If the sponsor is uncomfortable doing this, the facilitator can present the orientation. The goals of the project are stated and everyone is made to feel a part of the process. Initial concerns are expressed, and the executive sponsor works to ease any fears. The executive sponsor also gives a personal statement of support for the facilitator. A successful orientation is key to starting off the JAD process on a good footing. Everyone should leave with a sense of pride in what is going to happen and with confidence that they will be performing a highly valued service for the company.

Design Sessions To complete the Design Session component of JAD, you must perform the following tasks:
Review

the project scope, objectives, and definition document. Identify data, process, and system requirements. Identify system interfaces. Develop a prototype.
Document Assign

decisions, issues, assumptions, and definitions of terms.

someone to resolve all issues.

Finalization To complete the Finalization component, you must perform the following tasks:
Complete

the design documents. Sign off on the design documents. Make a presentation to the executive sponsor. Demonstrate the prototype.

Obtain

the executive sponsor's approval to proceed. Evaluate the JAD process. The first goal of the Finalization component is to obtain closure on the deliverables by reaching a team consensus that all necessary elements have been incorporated to fit the project's scope. The second goal is to produce a high quality presentation that includes a prototype demonstration (if appropriate). The third goal is to prepare a document that includes all of the deliverables that will be referenced in the future development effort.

The presentation and prototype demonstration should be given to the executive sponsor, as well as to other leaders. The goal is to get approval to proceed to the next stage of development. The team members, executive sponsor, and facilitator should also take some time to evaluate the effectiveness of the JAD process and to discuss ways to improve that process for future use.

Benefits The JAD approach provides the following benefits:

Accelerates Enhances

design quality Promotes teamwork with the customer Creates a design from the customer's perspective Lowers development and maintenance costs JAD achieves these benefits because of the following factors:
The The

decision makers are all present. facilitator keeps the group focused on the goals. views are handled immediately.

Differing Most The

errors are caught in the Analysis and Design stages.

system design reflects the user's desires. are resolved quickly. are documented and understood.

Issues

Assumptions The

process tends to gain momentum, not lose it.

When participants believe that they have had control over a project's effort and content, they believe in the results as well. This sense of ownership is critical for the next step, whether that step is implementing the results or selling them to others.

Tips for a Successful JAD Follow the suggestions below to ensure a successful JAD process:
Make

sure the facilitator is fully trained. an orientation for all participants. Make sure user representatives are properly trained. Do not begin until each JAD role is filled.
Conduct Hold Hold

sessions off site. sessions only when all decision?makers are present. all assumptions and issues.

Document Assign

responsibility and resolve all issues.

JAD Critical Success Factors

The following are critical success factors that require buy?in from the start:
Prevent

scope creep. Identify and address critical political and organizational issues early. Make sure that all project participants and key executive managers are committed to the JAD techniques. Divide large projects into manageable units. If any of these critical success factors are compromised, you greatly increase your chances of failure. In Joint Application Development, Jane Wood and Denise Silver present critical success factors in terms of the following "ten commandments" of JAD: 1.JAD success requires management commitment. 2.Full time participants must attend the entire session. 3.JAD success requires a trained facilitator. 4.Make sure you have the right people in the session. 5.All participants are equal. 6.JAD preparation is as important as the JAD session itself.

7.Make a good agenda and stick to it. 8.Use appropriate tools and techniques in the session. 9.Keep technical jargon to a minimum. 10.Produce a quality final document quickly. Conclusion: JAD is used as a technique for developing business system requirements and is typically used in the early stages of a systems development project.The purpose of JAD is to bring together MIS and end users in a structured workshop setting; to extract consensus based system requirements.This is accomplished by using a trained JAD facilitators and customized, planned agendas to assist the participant in arriving at complete, high quality requirements.Experience has shown that the JAD process substantially reduces development time, costs and errors.

2. Information Engineering (IE)

Definition: Information engineering (IE) or information engineering methodology (IEM) in software engineering is an approach to designing and developing information systems. Information engineering methodology is an architectural approach to planning, analyzing, designing, and implementing applications within an enterprise. It aims to enable an enterprise to improve the management of its resources, including capital, people and information systems, to support the achievement of its business vision. It is defined as: "An integrated and evolutionary set of tasks and techniques that enhance business communication throughout an enterprise enabling it to develop people, procedures and systems to achieve its vision". Information engineering has many purposes, including organization planning, business reengineering, application development, information systems planning and systems re-engineering.

IE variants
There are two variants of information engineering. These are called the DP-driven variant and the business-driven variant.

DP-driven : The DP-driven variant of Information engineering was designed to enable IS Departments to develop information systems that satisfied the information needs of the 1980s - which was largely a DP-driven development environment. Most of the CASE tools available today support this DP-driven variant of IE. Business-driven: IE was extended into strategic business planning and developed the business-driven variant of information engineering. This variant was designed for rapid change in the client/server, object-oriented environment of the business-driven 1990s.

IE stages
There are seven stages in Information engineering:

Information Strategy Planning : The fundamental objective of Information Strategy Planning (ISP) is to develop a plan for implementing business systems to support business needs. Outline Business Area Analysis : The OBAA answers a range of questions related to implementation of a business area. Select tasks to include in a particular project that provide support for business decisions and objectives. Specific information needs and priorities for the business area are needed. Detailed Business Area Analysis : The purpose of a DBAA project is to provide detailed models as a solid basis for system design. The methodology helps find the right answers to the right questions. Applying the methodology is never an end in itself. Business System Design : The purpose of a Business System Design project is to specify all aspects of a system that are relevant to its users, in preparation for the technical design, construction, and installation of one or more closely related databases and systems. The key tasks are therefore structured to produce unambiguous consistent specifications, with the volume of detail necessary to make planning and technical design decisions. Technical Design : A Technical Design project prepares an implementation area for construction and installation. The key tasks are structured to produce a system and database that meet the user's acceptance criteria and are technically sound. Construction : The objective of the Construction stage is to produce a system, as defined in the technical specification, on time and within budget. The system should be of an acceptable quality, and contain all necessary operating and user procedures. The task is complete when the acceptance criteria for the business system are met. Transition : Transition is defined as the period during which newly developed procedures gradually replace or are interfaced with existing procedures. The execution of a Transition project obviously demands a thorough understanding of both the system to be installed and the systems to be replaced.

IE techniques
Some techniques that are used during an IE project are:

Entity analysis : identifies all the things that the enterprise may want to hold data about. The analysis classifies all of the things into different entity types, revealing how they relate to each other. Which is being described in the entity model. Function analysis and process dependency : takes a function (a major business activity) of the enterprise and breaks it down into elementary business processes. From this, two diagrams are prepared: the process decomposition diagram, which shows the breakdown of a business function, and the process dependency diagram, which shows the interdependencies of business processes. Process logic analysis : describes the sequences of actions carried out by a business process and shows which data are used by each action.

Entity type lifecycle analysis : describes the significant business changes to entities and confirm that processes have been modelled to effect these changes Matrix cross-checking : creates cross-references between data objects and processes to verify that they are necessary and complete. Normalization : provides a formal means of confirming the correctness of the entity model. Cluster analysis : helps define the scope of design areas for proposed business systems. Data flow and data analysis : makes a comparison possible between the business area models and the systems currently supporting this area, these current systems are analyzed using data flow and data analysis techniques.

3. Rapid Application Development: Introduction:

Rapid Application Development (RAD) refers to a type of software development methodology that uses minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements. It is a software development process that allows usable systems to be built in as little as 60-90 days, often with some compromises.

PRINCIPLES BEHIND THE DEFINITION

A. In certain situations, a usable 80% solution can be produced in 20% of the time that would have been required to produce a total solution. B. In certain situations, the business requirements for a system can be fully satisfied even if some of its operational requirements are not satisfied. C. In certain situations, the acceptability of a system can be assessed against the agreed minimum useful set of requirements rather than all requirements. PROBLEMS ADDRESSED BY RAD A. With conventional methods, there is a long delay before the customer gets to see any results. B. With conventional methods, development can take so long that the customer's business has fundamentally changed by the time the system is ready for use. C. With conventional methods, there is nothing until 100% of the process is finished, then 100% of the software is delivered. WHY USE RAD? A. BAD REASONS FOR USING RAD 1. to prevent cost overruns (RAD needs a team already disciplined in cost management) 2. to prevent runaway schedules (RAD needs a team already disciplined in time management) B. GOOD REASONS FOR USING RAD 1. to converge early toward a design acceptable to the customer and feasible for the developers 2. to limit a project's exposure to the forces of change 3. to save development time, possibly at the expense of economy or product quality CHARACTERISTICS OF RAD A. RAD USES HYBRID TEAMS 1. Teams should consist of about 6 people, including both developers and full-time users of the system plus anyone else who has a stake in the requirements. 2. Developers chosen for RAD teams should be multi-talented "renaissance" people who are analysts, designers and programmers all rolled into one. B. RAD USES SPECIALIZED TOOLS THAT SUPPORT ... 1. "visual" development 2. creation of fake prototypes (pure simulations)

creation of working prototypes multiple languages team scheduling teamwork and collaboration use of reusable components use of standard APIs version control (because lots of versions will be generated) C. RAD USES "TIMEBOXING" Secondary features are dropped as necessary to stay on schedule.

3. 4. 5. 6. 7. 8. 9.

D. RAD USES ITERATIVE, EVOLUTIONARY PROTOTYPING 1. JAD (Joint Application Development) MEETING High-level end-users and designers meet in a brainstorming session to generate a rough list of initial requirements. a. Developers talk and listen b. Customers talk and listen 2. ITERATE UNTIL DONE a. Developers build / evolve prototype based on current requirements. b. Designers review the prototype. c. Customers try out the prototype, evolve their requirements. d. FOCUS GROUP meeting Customers and developers meet to review product together, refine requirements, and generate change requests. Developers listen. Customers talk. e. Requirements and change requests are "time boxed". Changes that cannot be accommodated within existing time boxes are eliminated. If necessary to stay "in the box," secondary requirements are dropped. 3. NOTES a. Iterations require between 1 day and 3 weeks. b. At some stage, exploratory prototypes may evolve into operational prototypes. c. Focus Group Sessions last about 2 hours are led by an experienced facilitator, who keeps the group "on focus" by having clear goals regarding the kind of information that needs to be elicited by preparing an issue-oriented agenda in advance of the meeting

by ensuring that adequate discussion is directed toward each issue by ensuring everyone has an adequate opportunity to participate are followed by a report from the facilitator

IMPORTANT RAD CONSTRAINTS

A. "Fitness for a business purpose" must be the criterion for acceptance of deliverables. B. All constituencies that can impact application requirements must have representation on the development team throughout the process. C. Customers, developers and management must accept informal deliverables. 1. Paper prototypes rather than full-scale systems 2. Notes from user workshops rather than formal requirements documents 3. Notes from designers' meetings rather than formal design documents 4. PRINCIPLE: Create the minimum documentation necessary to facilitate future development and maintenance. D. Development teams must be empowered to make some decisions traditionally left to management. E. End-to-end timescale must be 6 months or less. F. Iteration must be used in such a way that the development process converges toward an acceptable business solution. G. Prototyping must incorporate evolving requirements quickly, in real time, and gain consensus early. H. There must be a "buy before build" bias.

WHEN RAD WORKS AND WHEN IT DOESN'T

A. RAD TENDS TO WORK WHEN 1. The application will be run standalone. 2. Major use can be made of preexisting class libraries (APIs). 3. Performance is not critical. 4. Product distribution will be narrow (in-house or vertical market). 5. Project scope (macro-schedule) is constrained. 6. Reliability is not critical. 7. System can be split into several independent modules. 8. The product is aimed at a highly specialized IS (information systems) market.

9. The project has strong micro-schedule constraints (timeboxes). 10. The required technology is more than a year old. B. RAD TENDS TO FAIL WHEN ... 1. Application must interoperate with existing programs. 2. Few plug-in components are available. 3. Optimal performance is required. 4. Product development can't take advantage of high-end IS tools (e.g., 4GLs). 5. Product distribution will be wide (horizontal or mass market). 6. RAD becomes QADAD (Quick And Dirty Application Development). 7. RAD methods are used to build operating systems (reliability target too high for RAD), computer games (performance target too high for RAD). 8. Technical risks are high due to use of "bleeding" edge technology. 9. The product is mission- or life-critical. 10. The system cannot be modularized (defeats parallelism).

EVALUATION OF RAD
A. ADVANTAGES OF RAD 1. Buying may save money compared to building 2. Deliverables sometimes easier to port (because they make greater use of high-level abstractions, scripts, intermediate code) 3. Development conducted at a higher level of abstraction (because RAD tools operate at that level) 4. Early visibility (because of prototyping) 5. Greater flexibility (because developers can redesign almost at will) 6. Greatly reduced manual coding (because of wizards, code generators, code reuse) 7. Increased user involvement (because they are represented on the team at all times) 8. Possibly fewer defects (because CASE tools may generate much of the code) 9. Possibly reduced cost (because time is money, also because of reuse) 10. Shorter development cycles (because development tilts toward schedule and away from economy and quality) 11. Standardized look and feel (because APIs and other reusable components give a consistent appearance) B. DISADVANTAGES

1. Buying may not save money compared to building 2. Cost of integrated toolset and hardware to run it 3. Harder to gauge progress (because there are no classic milestones) 4. Less efficient (because code isn't hand crafted) 5. Loss of scientific precision (because no formal methods are used) 6. May accidentally empower a return to the uncontrolled practices of the early days of software development 7. More defects (because of the "code-like-hell" syndrome) 8. Prototype may not scale up, a B-I-G problem 9. Reduced features (because of timeboxing, software reuse) 10. Reliance on third-party components may ... a. sacrifice needed functionality b. add unneeded functionality c. create legal problems 11. Requirements may not converge (because the interests of customers and developers may diverge from one iteration to the next) 12. Standardized look and feel (undistinguished, lackluster appearance) 13. Successful efforts difficult to repeat (no two projects evolve the same way) 14. Unwanted features (through reuse of existing components)

SUMMARY
"In order to ensure high responsiveness, projects are designed with fixed timescales, sacrificing functionality if necessary. This allows the development team to focus on the pieces of functionality that have the highest business value, and deliver that functionality rapidly. Change is often the reason for delays in application development. In long linear development processes, changes in functionality requirements or project scope, particularly after a lot of time has been invested in planning, design, development and testing, cause many months to be lost and significant expense to be incurred for redesigning and redevelopment. RAD combats scope and requirements creep by limiting the project's exposure to change -shortening the development cycle and limiting the cost of change by incorporating it up-front before large investments are made in development and testing."

4. Rational Unified Process (RUP)

Rational Unified Process (RUP) is an object-oriented and Web-enabled program development methodology. According to Rational (developers of Rational Rose and the Unified Modeling Language), RUP is like an online mentor that provides guidelines, templates, and examples for all aspects and stages of program development. RUP and similar products -- such as ObjectOriented Software Process (OOSP), and the OPEN Process -- are comprehensive software engineering tools that combine the procedural aspects of development (such as defined stages, techniques, and practices) with other components of development (such as documents, models, manuals, code, and so on) within a unifying framework. RUP establishes four phases of development, each of which is organized into a number of separate iterations that must satisfy defined criteria before the next phase is undertaken: in the inception phase, developers define the scope of the project and its business case; in the elaboration phase, developers analyze the project's needs in greater detail and define its architectural foundation; in the construction phase, developers create the application design and source code; and in the transition phase, developers deliver the system to users. RUP provides a prototype at the completion of each iteration. The product also includes process support for Java 2 Enterprise Edition (J2EE) and BEA (WebLogic) development, and supplies an HTML-based description of the unified process that an organization can customize for its own use.

4. Extreme Programming
Extreme Programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent "releases" in short development cycles (time boxing), which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted. Other elements of extreme programming include: programming in pairs or doing extensive code review, unit testing of all code, avoiding programming of features until they are actually needed, a flat management structure, simplicity and clarity in code, expecting changes in the customer's requirements as time passes and the problem is better understood, and frequent communication with the customer and among programmers. The methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to "extreme" levels, on the theory that if some is good, more is better. It is unrelated to "cowboy coding", which is more free-form and unplanned. It does not advocate "death march" work schedules, but instead working at a sustainable pace.

Fig:Extreme Programming

Goals
Extreme Programming Explained describes Extreme Programming as a software development discipline that organizes people to produce higher quality software more productively. In traditional system development methods (such as SSADM or the waterfall model) the requirements for the system are determined at the beginning of the development project and often fixed from that point on. This means that the cost of changing the requirements at a later stage (a common feature of software engineering projects) will be high. Like other agile software development methods, XP attempts to reduce the cost of change by having multiple short development cycles, rather than one long one. In this doctrine changes are a natural, inescapable and desirable aspect of software development projects, and should be planned for instead of attempting to define a stable set of requirements. Extreme Programming also introduces a number of basic values, principles and practices on top of the agile programming framework.

References:
1. Andrews, Dorine C. and Naomi S. Leventhal. Fusion: Integrating IE, CASE, and JAD: A Handbook for reengineering the Systems Organization.Yourdon Press, 1994.

2. August, Judy H. Joint Application Design. Yourdon Press, 1991. 3. DeGrace, Peter and Leslie Stahl. Wicked Problems, Righteous Solutions. Yourdon Press, 1990. 4. Martin, James and Carma McClure. Diagramming Techniques for Analysts and Programmers. Prentice-Hall, 1985. 5. Reingruber, Michael C. and William W. Gregory. The Data Modeling Handbook. John Wiley & Sons, 1994. 6. Wood, Jane and Silver. Joint Application Development. John Wiley & Sons, 1995. 7. Yourdon, Edward. Decline and Fall of the American Programmer. Yourdon Press, 1992. 8. Zachman, John. A Framework for Information Systems Architecture. IBM Systems Journal (1987). 9. Hoffer, George and Valacich. Modern Systems Analysis and Design. Prentice Hall 2002. 10. Marchand, Davenport and Dickson. Mastering Information Management. Prentice Hall 2000. 11. Engler, Natalie, "Bringing in the Users", Computerworld, Nov 25, 1996. 12. Roman Soltys and Anthony Crawford. JAD for Business Plans and Designs. http://www.thefacilitatio.com/htdocs/article11.html.com 13. Cline, Alan. JAD for Requirements Collection and Management. http://www.carolla.com/wp-jad.htm 14. Nurre, Susan. The Habits of and Effective Facilitator. http://www.thefacilitator.com/htdocs/articles2.html 15. University of Texas at Auston. Human Resource Services Information Systems. http://www.utexas.edu/hr/is/pubs/jad.html#what 16. Defense Information Systems. Operational Process Improvement. http://www.opio.disa.mil/Products/JAD_RAD.htm 17. Requirements Engineering. Tools and Techniques. http://www.jrcase.mq.edu.au/~didar/seweb/tools.html 18. Meeting Networks. Application Descriptions. http://entsol.com/html/application_descriptions_7.html

19. Creative Data. Development Methodology JAD. http://credata.com/research/jad.html 20. Moeller, Walter. Facilitated Information Gathering Sessions. http://principlepartners.com/ 21. PCS Networks. Joint Applications Development http://www.pcsn.com/services/app/jad.htm 22. http://en.wikipedia.org/wiki/Information_engineering 23. http://csweb.cs.bgsu.edu/maner/domains/RAD.htm 24. http://www.bing.com/reference/semhtml/?title=Extreme_Programming&src=abop&qpvt =extreme+programming&fwd=1&q=extreme+programming