Assignment 1 Information System

8/4/2019 Assignment 1 Information System

1/17

Assignment:1 Date:Thrusday,June 10, 2010

Submitted By:Ishwar Dhungana

CRN:21,HIST College

Submitted to : Er.Sunil Paudel

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 ofthis 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 facilitatedworkshops 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


2/17

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:

Designate 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.

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?levelmanagers. 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 commitmentto the project is critical to its success.

Preparation

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

Schedule design sessions.

Conduct 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 areinformed.


3/17

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 thedeliverables 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 designsession 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 theteam 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 sponsorworks to ease any fears. The executive sponsor also gives a personal statement of support for thefacilitator.

A successful orientation is key to starting off the JAD process on a good footing. Everyoneshould 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 decisions, issues, assumptions, and definitions of terms.

Assign 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.


4/17

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 (ifappropriate). 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 wellas 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 design

Enhances 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 decision makers are all present.

The facilitator keeps the group focused on the goals.

Differing views are handled immediately.

Most errors are caught in the Analysis and Design stages.

The system design reflects the user's desires.

Issues are resolved quickly.

Assumptions are documented and understood.

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.


5/17

Tips for a Successful JAD

Follow the suggestions below to ensure a successful JAD process:

Make sure the facilitator is fully trained.

Conduct an orientation for all participants.

Make sure user representatives are properly trained.

Do not begin until each JAD role is filled.

Hold sessions off site.

Hold sessions only when all decision?makers are present.

Document all assumptions and issues.

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 offailure.

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.


6/17

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 MISand 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 evolutionaryset 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 re-engineering, 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 ISDepartments to develop information systems that satisfied the information needs of the

1980s - which was largely a DP-driven development environment. Most of the CASEtools available today support this DP-driven variant of IE.

Business-driven: IE was extended into strategic business planning and developed thebusiness-driven variant of information engineering. This variant was designed for rapidchange in the client/server, object-oriented environment of the business-driven 1990s.


7/17

IE stages

There are seven stages in Information engineering:

Information Strategy Planning : The fundamental objective of Information StrategyPlanning (ISP) is to develop a plan for implementing business systems to supportbusiness needs.

Outline Business Area Analysis : The OBAA answers a range of questions related toimplementation 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 detailedmodels 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 specifyall 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 andsystems. The key tasks are therefore structured to produce unambiguous consistent

specifications, with the volume of detail necessary to make planning and technical designdecisions.

Technical Design : A Technical Design project prepares an implementation area forconstruction and installation. The key tasks are structured to produce a system anddatabase that meet the user's acceptance criteria and are technically sound.

Construction : The objective of the Construction stage is to produce a system, as definedin 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 iscomplete when the acceptance criteria for the business system are met.

Transition : Transition is defined as the period during which newly developed proceduresgradually replace or are interfaced with existing procedures. The execution of a

Transition project obviously demands a thorough understanding of both the system to beinstalled 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 theinterdependencies of business processes.

Process logic analysis : describes the sequences of actions carried out by a businessprocess and shows which data are used by each action.


8/17

Entity type lifecycle analysis : describes the significant business changes to entities andconfirm that processes have been modelled to effect these changes

Matrix cross-checking : creates cross-references between data objects and processes toverify that they are necessary and complete.

Normalization : provides a formal means of confirming the correctness of the entitymodel.

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 analyzedusing 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 developedusing RAD is interleaved with writing the software itself. The lack of extensive pre-planninggenerally 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 builtin as little as 60-90 days, often with some compromises.

PRINCIPLES BEHIND THE DEFINITION


9/17

A. In certain situations, a usable 80% solution can be produced in20% of the time that would have been required to produce a totalsolution.

B. In certain situations, the business requirements for a system canbe fully satisfied even if some of its operational requirements

are not satisfied.C. In certain situations, the acceptability of a system can beassessed 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 thecustomer gets to see any results.

B. With conventional methods, development can take so long that thecustomer's business has fundamentally changed by the time the

system is ready for use.C. With conventional methods, there is nothing until 100% of theprocess is finished, then 100% of the software is delivered.

WHY USE RAD?

A. BAD REASONS FOR USING RAD1. 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 RAD1. to converge early toward a design acceptable to the customerand feasible for the developers

2. to limit a project's exposure to the forces of change3. to save development time, possibly at the expense of economy or

product quality

CHARACTERISTICS OF RAD

A. RAD USES HYBRID TEAMS1. 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" development2. creation of fake prototypes (pure simulations)


10/17

3. creation of working prototypes4. multiple languages5. team scheduling6. teamwork and collaboration7. use of reusable components8.

use of standard APIs9. version control(because lots of versions will be generated)

C. RAD USES "TIMEBOXING"Secondary features are dropped as necessary to stay on schedule.

D. RAD USES ITERATIVE, EVOLUTIONARY PROTOTYPING1. 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 listenb. Customers talk and listen

2. ITERATE UNTIL DONEa. 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 existingtime boxes are eliminated.

If necessary to stay "in the box," secondary requirementsare dropped.

3. NOTESa. 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 ofinformation that needs to be elicited

by preparing an issue-oriented agenda in advance ofthe meeting


11/17

by ensuring that adequate discussion is directedtoward each issue

by ensuring everyone has an adequate opportunity toparticipate

are followed by a report from the facilitator

IMPORTANT RAD CONSTRAINTS

A. "Fitness for a business purpose" must be the criterion foracceptance of deliverables.

B. All constituencies that can impact application requirements musthave representation on the development team throughout theprocess.

C. Customers, developers and management must accept informaldeliverables.

1. Paper prototypes rather than full-scale systems2. Notes from user workshops rather than formal requirements

documents3. Notes from designers' meetings rather than formal design

documents

4. PRINCIPLE: Create the minimum documentation necessary tofacilitate future development and maintenance.

D. Development teams must be empowered to make some decisionstraditionally 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 processconverges 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 WHEN1. 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.


12/17


13/17

1. Buying may not save money compared to building2. Cost of integrated toolset and hardware to run it3. 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 practicesof 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 problem9. Reduced features

(because of timeboxing, software reuse)

10.Reliance on third-party components may ...a.

sacrifice needed functionalityb. add unneeded functionality

c. create legal problems11.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, lacklusterappearance)

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 functionalitythat 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 lotof 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 andrequirements 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 indevelopment and testing."


14/17

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 Object-

Oriented 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 (timeboxing), 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.
http://searchcio-midmarket.techtarget.com/sDefinition/0,,sid183_gci516025,00.htmlhttp://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci214158,00.htmlhttp://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci214158,00.htmlhttp://searchsoa.techtarget.com/sDefinition/0,,sid26_gci283984,00.htmlhttp://searchsoa.techtarget.com/sDefinition/0,,sid26_gci546283,00.htmlhttp://searchsoa.techtarget.com/sDefinition/0,,sid26_gci546283,00.htmlhttp://searchsoa.techtarget.com/sDefinition/0,,sid26_gci212286,00.htmlhttp://en.wikipedia.org/wiki/Software_development_methodologyhttp://en.wikipedia.org/wiki/Requirementhttp://en.wikipedia.org/wiki/Agile_software_developmenthttp://en.wikipedia.org/wiki/Pair_programminghttp://en.wikipedia.org/wiki/Code_reviewhttp://en.wikipedia.org/wiki/Code_reviewhttp://en.wikipedia.org/wiki/Unit_testinghttp://en.wikipedia.org/wiki/Cowboy_codinghttp://en.wikipedia.org/wiki/Death_march_%28software_development%29http://en.wikipedia.org/wiki/Death_march_%28software_development%29http://en.wikipedia.org/wiki/Cowboy_codinghttp://en.wikipedia.org/wiki/Unit_testinghttp://en.wikipedia.org/wiki/Code_reviewhttp://en.wikipedia.org/wiki/Code_reviewhttp://en.wikipedia.org/wiki/Pair_programminghttp://en.wikipedia.org/wiki/Agile_software_developmenthttp://en.wikipedia.org/wiki/Requirementhttp://en.wikipedia.org/wiki/Software_development_methodologyhttp://searchsoa.techtarget.com/sDefinition/0,,sid26_gci212286,00.htmlhttp://searchsoa.techtarget.com/sDefinition/0,,sid26_gci546283,00.htmlhttp://searchsoa.techtarget.com/sDefinition/0,,sid26_gci283984,00.htmlhttp://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci214158,00.htmlhttp://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci214158,00.htmlhttp://searchcio-midmarket.techtarget.com/sDefinition/0,,sid183_gci516025,00.html


15/17

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 laterstage (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 ofattempting 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.
http://www.bing.com/reference/semhtml/Structured_Systems_Analysis_and_Design_Methodologyhttp://www.bing.com/reference/semhtml/Waterfall_modelhttp://www.bing.com/reference/semhtml/Agile_software_developmenthttp://www.bing.com/reference/semhtml/Agile_software_developmenthttp://www.bing.com/reference/semhtml/Agile_software_developmenthttp://www.bing.com/reference/semhtml/Agile_software_developmenthttp://www.bing.com/reference/semhtml/Waterfall_modelhttp://www.bing.com/reference/semhtml/Structured_Systems_Analysis_and_Design_Methodology


16/17

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 andProgrammers. Prentice-Hall, 1985.

5. Reingruber, Michael C. and William W. Gregory. The Data Modeling Handbook. JohnWiley & 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
http://www.thefacilitatio.com/htdocs/article11.html.comhttp://www.thefacilitatio.com/htdocs/article11.html.comhttp://www.thefacilitatio.com/htdocs/article11.html.comhttp://www.carolla.com/wp-jad.htmhttp://www.carolla.com/wp-jad.htmhttp://www.thefacilitator.com/htdocs/articles2.htmlhttp://www.thefacilitator.com/htdocs/articles2.htmlhttp://www.utexas.edu/hr/is/pubs/jad.html#whathttp://www.utexas.edu/hr/is/pubs/jad.html#whathttp://www.opio.disa.mil/Products/JAD_RAD.htmhttp://www.opio.disa.mil/Products/JAD_RAD.htmhttp://www.jrcase.mq.edu.au/~didar/seweb/tools.htmlhttp://www.jrcase.mq.edu.au/~didar/seweb/tools.htmlhttp://entsol.com/html/application_descriptions_7.htmlhttp://entsol.com/html/application_descriptions_7.htmlhttp://entsol.com/html/application_descriptions_7.htmlhttp://www.jrcase.mq.edu.au/~didar/seweb/tools.htmlhttp://www.opio.disa.mil/Products/JAD_RAD.htmhttp://www.utexas.edu/hr/is/pubs/jad.html#whathttp://www.thefacilitator.com/htdocs/articles2.htmlhttp://www.carolla.com/wp-jad.htmhttp://www.thefacilitatio.com/htdocs/article11.html.com


17/17

19.Creative Data. Development MethodologyJAD.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
http://credata.com/research/jad.htmlhttp://credata.com/research/jad.htmlhttp://credata.com/research/jad.htmlhttp://principlepartners.com/http://principlepartners.com/http://principlepartners.com/http://www.pcsn.com/services/app/jad.htmhttp://www.pcsn.com/services/app/jad.htmhttp://en.wikipedia.org/wiki/Information_engineeringhttp://en.wikipedia.org/wiki/Information_engineeringhttp://en.wikipedia.org/wiki/Information_engineeringhttp://csweb.cs.bgsu.edu/maner/domains/RAD.htmhttp://csweb.cs.bgsu.edu/maner/domains/RAD.htmhttp://csweb.cs.bgsu.edu/maner/domains/RAD.htmhttp://www.bing.com/reference/semhtml/?title=Extreme_Programming&src=abop&qpvt=extreme+programming&fwd=1&q=extreme+programminghttp://www.bing.com/reference/semhtml/?title=Extreme_Programming&src=abop&qpvt=extreme+programming&fwd=1&q=extreme+programminghttp://www.bing.com/reference/semhtml/?title=Extreme_Programming&src=abop&qpvt=extreme+programming&fwd=1&q=extreme+programminghttp://www.bing.com/reference/semhtml/?title=Extreme_Programming&src=abop&qpvt=extreme+programming&fwd=1&q=extreme+programminghttp://www.bing.com/reference/semhtml/?title=Extreme_Programming&src=abop&qpvt=extreme+programming&fwd=1&q=extreme+programminghttp://www.bing.com/reference/semhtml/?title=Extreme_Programming&src=abop&qpvt=extreme+programming&fwd=1&q=extreme+programminghttp://csweb.cs.bgsu.edu/maner/domains/RAD.htmhttp://en.wikipedia.org/wiki/Information_engineeringhttp://www.pcsn.com/services/app/jad.htmhttp://principlepartners.com/http://credata.com/research/jad.html

Assignment 1 Information System

Documents

Transcript of Assignment 1 Information System