ࡱ> Y EbjbjWW "==d2]8$#4WWW"""""""$7$+&"WWWW"AAAAW<"W"AA3}%|"d_"Prototyping Definition A prototype is a working model of ( or parts of ) an information system with emphasis on specific aspects of that system. The aim is to test certain design decisions. It may not be complete in every respect - scaled-down version Background Prototyping is an approach characterised by a high degree of iteration, user participation and extensive use of prototypes < see diag1.ppt > A working model rather than a paper model < Has some functionality > screen handling < look & feel > for data capture and report printing < output > no file updating < no permanent storage > or error handling Interact with client/user < demos, interviews - data gathering techniques > and when happy Followed by more formal specification < built from knowledge gained > Can be effectively integrated with the waterfall model < parts of the requirements analysis > Some political risks < later > Reasons for Prototyping Other methods present us with some problems the vagueness and intangibility of the end product < especially from methods like SDLC > the difficulty of describing and defining a computer system the difficulty of describing user requirements < in words > the still ever-present communication problems between user and designer < inherent in the methods used > Computing Industry still ask for a commitment to something described and defined on paper Prototype Systems are constructed to address design issues defined from the initial stages Aims of Prototyping Make the system requirements tangible < something the user can see > by providing an illustrative system < an example > at the earliest possible stage in the development process < a long lead-time from Requirements Analysis to Implementation & Installation > with the least possible effort < quick & dirty >. The Prototyping Process Iteration is the key Regardless of the purpose, repeated refinement is an essential part of the process Identify known requirements < user and analysts work together identify the known requirements that must be met outline areas where further definition is required > Design and develop prototype < A quick design then occurs focused on a representation of the aspects of the software that will be visible to the user (reports, layout inputs, outputs ). leads to the construction of a prototype by the analyst. Speed in producing a running system is essential so that the momentum on the project is not lost and so that users can quickly begin evaluating the application > Customer evaluation of prototype < by the users and is used to refine requirements for the software to be developed > User Workshops are held as a formative evaluation to get user feedback Review prototype < During the evaluation, the analyst captures information on what users like and dislike, noticing why they react as they do. The information influences the features of the next version. Changes are planned and agreed with users and the analysts proceeds with the modifications > Type of Prototype < number of classifications Classification may be based on the particular aspect that is modelled in a prototype > Modelling user interface user-interface prototyping functional prototyping < scenario-based prototyping > Usability Scenarios are used to define the problems from the existing systems Design Scenarios are used to envision the ideal systems Timing of the development exploratory prototyping < discovering the user requirements > experimental prototyping < takes place in the technical design phase objective is to determine the adequacy of a proposed solution > Use of prototype keep-it or evolutionary prototyping throw away prototyping Use of the prototype < Most prototyping activities are associated with the requirements definition phase there is a question of what to do having completed the prototype > Abandon application Both prototype and application are discarded. < Developing the prototype provided information from which to determine that the application or the intended approach is inappropriate to justify additional development > Implement prototype The features and performance of the prototype will meet user needs either permanently or for the foreseeable future. < This strategy may be selected when the application environment is changing so fast that it is difficult to determine long-term or stable application requirements. > Redevelop application Development of the prototype provided sufficient information to determine the features necessary in the full application. < This info is used as the starting point for development of the application in a manner that makes the best possible use of resources. > Begin new prototype Information gained by development of the prototype suggests alternative strategies. < A different prototype is constructed to add to information about application requirements. > Candidate Applications < Where can/should this technique be used? > Requirements are not known Application is such that there is little available information about features the system must have Requirements need evaluation There may be different ways of satisfying the user requirements, hence verification and assessment are needed High Cost/High Risk A need exists to get the production of the system right first time. < because of the size of the investment and the implications of getting it wrong > New technology There is no experience < can form a good basis for learning > Tools for Prototyping 4th generation techniques reusable code executable specification languages Very high level languages < Structures English, Action State Language - ASL > Problems of Prototyping Greater investment of user time Probably involved in several iterations Inadequate problem analysis a tendency to dive straight in with the tools Some compromise decisions made during production of the prototype maybe carried through to the development of the real system User would not give up the prototype The customer may think that the prototype is nearly the finished product. < unaware that issues such as long term maintenance have not been addressed by the designer > When informed that the product must be rebuild, the client demands that few fixes are carried out to make it a working product As a result, the customer may not be prepared to wait another 6 months (or whatever) while the system is rebuilt" User develops unrealistic expectations time scales, flexibility and capacity to accommodate changes Others include Resistance documentation drift difficulty of co-ordination within large projects Benefits of Prototyping Reduction of requirements uncertainty Customers and users can give immediate feedback on the requirements specification < Reduce of uncertainty about the nature of the information problem Prototyping is an important technique in requirements validation- fixing errors in requirements are high so validation is important Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error > Shorter and less expensive testing < The testing phase will be shorter and less expensive because the costs are largely shifted to the requirements definition phase > Lower training costs Users are involved during the prototyping activity and will already be familiar with the system < so training costs will turn out to be significantly lower > Prototype system is much easier to evaluate than a dry SRS document < System Requirements Specification > The implications of requirements can be judged within the live environment Construction of the prototype can help developers to make better decisions when implementing the full system Evolutionary development Exploratory prototyping Objective is to work with customers and to evolve a final system from an initial outline specification. Throw-away prototyping Objective is to understand the system requirements. Starting point is poorly understood requirements Advantages Used for systems where the initial requirements are very complicated and hard to define < a bit woolly - 'we don't really know what we want it to do yet' > Often produces a product which is very close to the users actual needs Typically used for cutting edge system developments < e.g. AI & Neural Net Processing > This model is also much favoured by academic researchers Disadvantages Almost impossible to manage must plan for an unknown number of iterations < could go round the loop twice - could go round 7 or 8 times > Resulting software is usually poorly structured difficult to test thoroughly almost impossible to maintain after delivery < poorly documented - usually in source code > Does not scale well to large projects < 7+/- 2 - people cannot remember such a large volume of detail Also because of the number of people required on large projects, where's the communication, the task list, etc. > Problems Lack of process visibility cannot measure progress due to quick development that makes documentation unworthy Systems are often poorly structured continual change corrupts the s/w structure Special skills may be required e.g. specialist structured/programming language skills Applicability For small or medium-size interactive systems For parts of large systems (e.g. the user interface For short-lifetime systems Rapid Application Development Aim of new software development to help organisation meet some business need to exploit new opportunity for revenue creation Time spent building software costs money Claim: most new software developments turn out not to be fit for purpose arrive too late exploit the business opportunity RAD proposed in early 1990s Based on the observation that 80% of the system built in 20% of the time Emphasises: need to develop software in short timescales < typically 60-90 days > software should be fit for purpose, not perfect < does what it needs to do - no need for bells and whistles > Dynamic Systems Development Method (DSDM) U.K. developed RAD methodology Concepts: resources and timetable are fixed but requirements are flexible < timeboxing > small teams < 6 people > full-time end-user involvement in team team members empowered to make decisions use of 4GLs, CASE and component-based techniques The DSDM Lifecycle < see diag3.ppt > Advantages Can result in incredible increases in programmer productivity Can result in a product with an excellent business fit Fits the business' needs exactly Overall costs can be lower Time taken from start to end is much less End-user satisfaction can be much higher It does what they need it to do New business opportunities can be exploited Disadvantages Focus on quick delivery and prototyping can compromise long term quality and usefulness of the product Perfect this week What about next month or after the reorganisation Too great an emphasis placed on users reactions to prototypes Just because they don't like the look Depends upon commitment from client and developer Client could decide the benefits are not worth the costs Does not fit well in traditional, hierarchically structured organisations Insufficient documentation may be produced Difficult to apply rigorous quality control Not suitable for large projects where too many teams are required Not suitable for projects requiring: high performance application of complex new technology if technical risks high in general Nowadays... The most recent software development processes focus on: lightweight processes < utilities to d a single, simple job > high levels of customer involvement phased and iterative development < planned deliverables > use of software engineering best practices < Learn from previous experience > emphasis on planning and control Comments... All models follow (more or less) the same principle understand the problem design a solution test the solution ...the difficulties lie in deciding how to define and organise each of the functions chronologically to suit individual project how to implement the iterative nature of the development process < where does the cycle begin and end? When does the next stage begin? > ...all in all how to get the right product to the client at the right time. Summary There is no ideal model For large systems, hybrid models are usually appropriate The project manager should define the model to be used at the beginning of the project Database and IS Development SDLC Generally clear match between phases in database development and SDLC. RAD Cursory attempt at conceptual data modeling. Define database during development of initial prototype. Repeat implementation and maintenance activities with new prototype versions. RAD is a methodology for compressing the analysis, design, build, and test phases into a series of short, iterative development cycles. This has a number of distinct advantages over the traditional sequential development model. RAD projects are typically staffed with small integrated teams comprised of developers, end users, and IT technical resources. Small teams, combined with short, iterative development cycles optimizes speed, unity of vision and purpose, effective informal communication and simple project management Joint Application Design, or JAD, is a process originally developed for designing a computer-based system. It brings together business area people (users) and IT (Information Technology) professionals in a highly focused workshop. The advantages of JAD include a dramatic shortening of the time it takes to complete a project. It also improves the quality of the final product by focusing on the up-front portion of the development lifecycle, thus reducing the likelihood of errors that are expensive to correct later on Rapid Application Development - Development Methodology The traditional software development cycle follows a rigid sequence of steps with a formal sign-off at the completion of each. A complete, detailed requirements analysis is done that attempts to capture the system requirements in a Requirements Specification. Users are forced to "sign-off" on the specification before development proceeds to the next step. This is followed by a complete system design and then development and testing. But, what if the design phase uncovers requirements that are technically unfeasible, or extremely expensive to implement? What if errors in the design are encountered during the build phase? The elapsed time between the initial analysis and testing is usually a period of several months. What if business requirements or priorities change or the users realize they overlooked critical needs during the analysis phase? These are many of the reasons why software development projects either fail or dont meet the users expectations when delivered. RAD is a methodology for compressing the analysis, design, build, and test phases into a series of short, iterative development cycles. This has a number of distinct advantages over the traditional sequential development model. INCLUDEPICTURE \d "/ImagesOld/rad.gif" Iteration allows for effectiveness and self-correction. Studies have shown that human beings almost never perform a complex task correctly the first time. However, people are extremely good at making an adequate beginning and then making many small refinements and improvements. We should encourage and exploit this rather than fight it. RAD projects are typically staffed with small integrated teams comprised of developers, end users, and IT technical resources. Small teams, combined with short, iterative development cycles optimizes speed, unity of vision and purpose, effective informal communication and simple project management. An important, fundamental principle of iterative development is that each iteration delivers a functional version of the final system. It is a properly engineered, fully working portion of the final system and is not the same as a prototype. For example, the first iteration might deliver 100% of 10%, the second iteration 100% of 25%, etc. Development Methodology - Joint Application Development (JAD) Joint Application Development, or JAD, is a process originally developed for designing a computer-based system. It brings together business area people (users) and IT (Information Technology) professionals in a highly focused workshop. The advantages of JAD include a dramatic shortening of the time it takes to complete a project. It also improves the quality of the final product by focusing on the up-front portion of the development lifecycle, thus reducing the likelihood of errors that are expensive to correct later on. The JAD process does for computer systems development what Henry Ford did for the manufacture of automobiles (a method of organizing machinery, materials, and labor so that a car could be put together much faster and cheaper than ever before the assembly line). The goal in systems development is to identify what the users really need and then set up a system or process that will provide it. Traditional methods have several built-in delay factors that get worse as more people become involved. The following description of the Traditional Systems Design process is from "Joint Application Development" by Jane Wood and Denise Silver . It may sound familiar. In most organizations, the systems development life cycle begins with the identification of a need, assignment of a project leader and team, and often the selection of a catchy acronym for the project. The leader pursues a series of separate meetings with the people who will use the system or be affected by it. The leader continues these meetings over time. Often the key people involved are not so easy to reach. But eventually, having documented everything possible, the leader translates copious notes into a personal terminology. Thats when it becomes apparent that the requirements from, say Accounting, dont mesh with what the Sales department wants. So the leader calls Sales and finds out the contact there is in the field and will not be back until tomorrow. Next day the leader reaches Sales, gets the information, calls Accounting, and of course the person in Accounting is now out of the office, and so on. When everyone is finally in agreement, alas, the leader discovers that even more people should have been consulted because their needs require something entirely different. In the end, everyone is reluctant to "sign off" on the specifications. Other times, signing off comes easily. But when the system is delivered, it often has little to do with what the users really need: "A user sign off is a powerless piece of paper" when matched against the fury of top management. Slow communication and long feedback time is one reason the traditional process is so time-consuming. You can see why the communication problem grows worse as more people must be brought into consensus. JAD centers around a structured workshop session. Everyone gets together in a room and talks it out. Everyone hears what the rest of the group has to say. Theres no delay between question and answer, no "telephone tag" or waiting for memos to come back. JAD eliminates many of the problems with traditional meetings. Meetings are not well regarded as a productive form of work. JAD turns meetings into workshops. They are less frequent, more structured, and more productive. An agenda provides the structure, a facilitator directs the process, visual aids clarify concepts being discussed and the group dynamics, with constant feedback, stimulates creativity. JAD sessions are: Very focused Conducted in a dedicated environment Quickly drive major requirements and interface "look & feel" JAD participants typically include: Facilitator facilitates discussions, enforces rules End users 3 to 5, attend all sessions Developers 2 or 3, question for clarity Tie Breaker Senior manager. Breaks end user ties, usually doesnt attend Observers 2 or 3, do not speak Subject Matter Experts limited number for understanding business & technology In the early history of databases, everyone who owned this type of program needed basic programming skills to use them, but the advent of the graphical interface means typed commands are pretty much a thing of the past. Nowadays, application building is usually done with a point and click interface, meaning that databases which can be set up by lay people without compromising flexibility are still the goal all publishers are working towards. Some programming knowledge is still necessary for specialist databases, however, which is why nearly every product comes with a developer's edition either as standard or as an add-on program. These versions of the software enable the creator to use the database language to build specific applications. Although still a big task for a novice, this is nowhere near as difficult as it was in the days when programmers made money selling ready made databases to people who wouldn't have a clue where to begin. These days, you'll use a simplified programming environment called a scripting language to customise an application. Scripts can be built up by selecting pre-defined commands from a scrolling list, before filling in the blanks for the parameters by selecting fields from pop-up lists or typing in numerical or textual values. It should be relatively simple to print forms, cross tabs and print labels. In addition many mainstream programs will guide you through the tricky process of converting a database into dynamic HTML using wizards, and some include a Web server. A decent product will show you how to create both static and dynamic databases. Static databases will only change when you republish them, whereas dynamic programs will change every time the database is updated. Rapid application development Philosophy: Applications must be produced quickly to be economical to reduce the number of changes between analysis and final delivery to be relevant when delivered, not solving last year's problem because users want their new system now, or because the organisation must conform to new legislation to clear the application backlog User requirements must be understood users must be involved in the development process understanding is ensured by the use of concrete examples, hence the emphasis on prototyping Software developers must be allowed to do their job with the minimum of bureaucratic interference Rapid application development Advantages: Quick results, not abstract, users have assurance that correct solution will be produced  Overview of RAD Rapid application development is an approach that uses evolutionary prototyping to deliver a limited system in a short time. If additional functions are required, another project enhances the system delivered by the first project. RAD requires that it is possible to define a small set of requirements to be delivered over a period of months. RAD is different from evolutionary prototyping because of the use of a time-box: a fixed time limit (about two months) for the completion of the project. Once the requirements have been identified, analysis, design, prototyping and reviews are carried out repeatedly until the time limit expires or the requirements are satisfied. The fixed time limit forces the users and designers to concentrate on the most important system functions and aims to provide a working, if limited, system quickly. RAD relies on the appropriate use of prototyping tools including user interface design tools, and rapid database development tools. CASE tools may also be useful. RAD will normally use Joint Application Development techniques which ensure that the intended users of the system actively participate in its development. Users are involved in requirements analysis, prototyping, construction, system test and installation. Joint Application Development WorkshopsINCLUDEPICTURE \d "pmanrul.gif" Joint Application Development workshops are structured meetings bringing together users and designers to specify, design, or approve a system within defined time limits. The workshops are led by a trained facilitator and follow defined rules. They concentrate on the business needs and how these needs are met by the new system. Typically users and designers are relieved of other duties to focus exclusively on the project for the duration of the workshop. Joint requirements planning workshop The joint requirements planning workshop is normally held after the developers have familiarised themselves with the business area and the current system and its problems. The workshop will confirm the developers' understanding and identify the requirements for the new system. The workshop should produce a description of the project scope, its objectives, and constraints, the functional requirements and a list of implementation issues. JAD Analysis A JAD analysis workshop produces a detailed description of the system's behaviour based on the basic requirements and issues raised during the joint requirements planning workshop. Input from the intended users of the system is critical to ensuring that the system will ultimately meet users needs. JAD design A JAD design workshop involves the users and developers in designing procedures, reports and the user interface for the new system. The workshop is based on the detailed requirements produced from the JAD analysis and additional work by the developers. Prototyping tools are essential to ensure that the users understand the implications of the design. The workshop plans the construction and installation stage of the project, identifying the necessary resources. A test plan is also produced. JAD review and confirmation This workshop can be scheduled at any time during the development when it is necessary to review progress and confirm any changes. For example, such a meeting may be held after the development and evaluation of a prototype. The roles of the participants in JAD workshops The size of a JAD meeting must be kept small to ensure full participation. Representatives of users and developers are essential. Other roles include scribe and facilitator. Project Champion The project champion is a manager with overall responsibility for the users. The champion takes political responsibility for the project, ensures that there is appropriate management support including resources and people, and ultimately makes the approval decision for the project. Facilitator The facilitator is responsible for planning and conducting the workshop. During the workshop, the facilitator is responsible for: encouraging participation, helping communication between users and developers, negotiating solutions to disagreements, ensuring coverage of the agenda and the achievement of the workshop goals. Scribe The scribe is usually an information systems professional skilled in using CASE, prototyping and documentation tools to record the workshop minutes (including unresolved issues, options considered, decisions, and justification), document requirements, build prototypes. Users These will include end users and managers who can defined business rules and requirements. They are responsible for ensuring that the system is defined to meet business objectives. End users help with design issues, prototyping evaluation and the specification of training needs and acceptance criteria. User managers are involved in approving project durations and costs and in ensuring that the system meets their goals. Developers The developers must ensure that they obtain a clear understanding of the users needs and the system requirements. They will identify the feasibility and costs of any proposal. They may develop prototypes and present design and specification alternatives. JAD TechniquesINCLUDEPICTURE \d "pmanrul.gif" Brainstorming is commonly used to generate ideas. The Nominal Group Technique (NGT) is a another technique for conducting a group meeting. Its goals are to maximise individual participation and build a group consensus, particularly when the issue being discussed is highly political. The technique focuses on ideas not on the people that propose them. Using the Nominal Group Technique The facilitator explains the rules, introduces the topic for discussion, and answers questions from the group to clarify the purpose of the meeting. The rules include Everyone must participate fully to generate the best ideas Criticise ideas not people There are no "stupid" ideas Criticism should be constructive Group members work individually to generate ideas The facilitator requests and idea from each group member, listing the ideas on a white board. No comments or criticisms are taken at this point. The facilitator continues requesting ideas from each member in turn until all ideas have been listed. The facilitator opens discussion for a pre-defined period during which the group discuss the ideas and add new ideas as they arise. After the discussion, each group member ranks the listed ideas on paper and submits the ranking to the facilitator, who combines the individual rankings to create a group ranking. If the group decides that the group ranking is unacceptable, steps four, five and six are repeated. Success factors for JAD workshopsINCLUDEPICTURE \d "pmanrul.gif" Management commitment A skilled facilitator A reasonable project scope (larger projects may need to be broken into smaller projects) Committed, well-prepared participants who represent and can take decisions for their colleagues Concentration on business not detailed technical issues The use of a system development methodology, supported by appropriate tools The use of modelling techniques which all the participants understand A suitable environment for the meetings Co-ordinating a JAD workshopINCLUDEPICTURE \d "pmanrul.gif" Ideally, a JAD workshop should be held away from the participants' normal workplace to reduce the risk of their being interrupted and to ensure they concentrate on the workshop objectives. A JAD workshop may take one to two days, but this depends on the complexity of the project. Workshops are best scheduled for a full day. Half-day workshops are less productive because the participants are distracted. It is important to obtain the best participants. The more indispensable a user is to their manager, the more useful they are likely to be in the workshop. Participants should understand the format of the workshop, and the modelling techniques to be used. They need background information and should be aware of the objectives of the workshop. A half day kick-off meeting hosted by the project champion and held about a week before the workshop is a useful preparation. The workshop should start with a review of the agenda and the workshop rules and an outline of the scope and or objectives of the workshop. Each day's session should be finished with a review of the agenda and the progress that has been made. Participants should have the opportunity to comment. At the end of the workshop, the results should be summarised, open issues identified, and the action plan generated. The workshop facilities should have the appropriate equipment and supplies. Tables should be arranged to encourage group discussion and appropriate communication tools should be available. This includes white boards, flip charts, overhead projector, computers, software and printers. A photocopier can save time. It can be useful to have additional accommodation to allow the group to split up to carry out activities in parallel. The rules of operation for a workshop are similar to those of an NGT meeting: Everyone is an equal participant Criticise ideas, not people Follow normal meeting conventions Add issues which are not likely to be quickly resolved to an open issues list for consideration outside the meeting. At the end of each day, the facilitator helps the participants to review the open issues list, and to allocate priorities and responsibilities for resolving those issues by a fixed date. After the workshop, the scribe consolidates all the information and circulates the minutes to all participants. The minutes may include A list of objectives The project scope The functional requirements Analysis of costs and benefits Designs The open issues list and allocation of responsibilities Project action plans and completion date Benefits of using Joint Application DevelopmentINCLUDEPICTURE \d "pmanrul.gif" The users are actively involved in the analysis and design of the system. This increases their understanding and makes them more accountable for the final system. The time devoted to analysis, design and documentation is a reduced. Communication between the users and developers is improved and there is less time between specification and and implementation, consequently the number of late changes in requirements is reduced. Training needs are reduced and changeover is easier because the users are more familiar with the system's features and more committed to its success. INCLUDEPICTURE \d "question.gif"Discuss whether RAD / JAD techniques are appropriate for the following development projects: a web site a multimedia teaching package an air-traffic control system a fly-by-wire system for an aircraft INCLUDEPICTURE \d "pmanrul.gif" Rapid Application Development Rapid Application Development (RAD) -- Introduction From Rapid Applications Development by James Martin. Rapid Application Development (RAD) is a development lifecycle designed to give much faster development and higher quality than the traditional lifecycle. It is designed to take advantage of powerful development software. RAD is used for building large Information System applications of the kind which occur in every large business. Unique and highly complex programs cannot be created using this method. Programs for tasks such as game playing, operating systems, and special purpose programs must be hand-crafted. Lower Cost Fast application development often results in lower costs. This is due to the use of small development teams using power tools to generate the system. Faster development due to these tools also reduces costs. The power tools for application development are CASE tools. (Computer-Aided Systems Engineering) The RAD methodology uses computerized tools and human techniques in a tightly interwoven fashion to achieve the goals of high-speed and high-quality. Quality CASE tools, code generators, and prototyping tools provide a means of ensuring higher quality when employed using an appropriate methodology. Most organizations define software quality inappropriately as ``conforming to the written specifications as effectively as possible.'' A more appropriate definition would be ``meeting the true business (or user) requirements as effectively as possible at the time the system comes into operation.'' The shorter the elapsed time between user design and cutover (new system integration with the business), the more likely the system will be satisfactory. RAD Requirements Thorough involvement of the end-user in the design of the system. Prototyping to help the end-user visualize adjustments to the system. Use of an integrated CASE toolset, which enforces technical integrity in system modeling and design. A CASE repository which facilitates the reuse of well-proven templates, components, or systems. A CASE toolset that generates bug-free code from validated design. User involvement in the Construction Phase, allowing the details of the prototype to be adjusted if necessary. Metrics System construction metrics are used to: Set goals for developers. Compare tools and techniques. Allow management to detect, examine, and possibly replicate examples of excellence. Facilitate planning. The total elapsed time for the entire development lifecycle is known as cycle time. An objective of developers is to shorten the cycle time. Metrics -- continued The cycle time may be subdivided into sections of the development process: Initiation and requirements planning. User analysis and design. Technical design, coding, and testing. Cutover. Notice the simialarity to the SDLC. RAD Tools The Wall Street Journal lamented that software is one of the two principle obstacles to economic progress. A former U.S. Pentagon chief commented ``If anything kills us before the Russians, it will be our software.'' Power tools are required to overcome the problems involved with software development. Power tools change the methods of construction by using design-automation techniques, code generation, and computer aided planning and analysis. The Integrated Tool Set The components of this set can include 4GLs, user friendly query languages and report generators, prototyping tools, CASE tools, code generators, expert system shells. When these tools are integrated into one environment they provide a powerful system for project construction. The term I-CASE came into use to describe this type of environment. CASE Diagrams are used to represent planning information, an overview of the system, data models and data flows, detailed designs, and program structures. A principle of CASE is that, whenever appropriate, diagrams are used to aid in clear thinking. Diagrams in non-CASE projects are often hand drawn and contain errors, inconsistencies, and ommisions. CASE tools enforce precision in diagraming. A critical characteristic of I-CASE is that it generates executable programs. CASE -- diagrams CASE diagrams often show objects and associations among objects. Examples of objects are an entity type, a process, a data store, a program module, a department, a business goal. Examples of associations are a relationship between two entity types, a data flow on a DFD, a line indicating how a procedure is dependent on other procedures, a line connecting events on a PERT chart. An important form of diagram shows the structure of the programs. An action diagram represents program structures independently of any programming language. Hyperdiagrams Hyperdiagrams or hypercharts describe representations of plans, models, or designs in which multiple two dimensional representations are linked together. Multiple types of of two dimensional diagrams are used to build the hyperdiagram. Systems are generally too complex to draw as one single type of diagram. System components may be summarized with decomposition diagrams, interdependencies may be shown with data-flow diagrams, logic may be depicted with an action diagram, views of database structure may be depicted. Action diagrams may also refer to screen designs or report formats. All of these may be stored in a hyperdiagram with logical links between them. The Repository The meaning represented by diagrams and their detail is stored in a repository. Simple repositories (called dictionaries) contain names and descriptions of data items, processes, and variables. More complex repositories contain information about objects behavior and about plans and designs for these objects. The repository contains many rules relating to the knowledge it stores and may employ rule processing to help achieve accuracy, integrity, and completeness of the projects plans, models, and designs. RAD -- Methodology A methodology must be used which has been adapted to match the needs of the toolset being used. Toolsets should integrate: prototyping graphical computer aided modeling and design a repository of design information and reusable components automation for enforcing design integrity integrated code generator, testing tools thorough end-user interaction with developer, aided by tools This should replace the written system documentation. Four Phases of RAD Lifecycle To help ensure that developers build what the user really needs the RAD lifecycle has four phases: Requirements planning phase. User design phase. Construction phase. Cutover phase. Requirements Planning Phase The requirements planning phase requires that high level or knowledgeable end-users determine what the fuctions of the system should be. It should be a structured discussion of the business problems that need to be solved. It can often be done quickly when the right users and executives are involved. Requirements planning occurs in a Joint Requirements Planning workshop (JRP). User Design Phase The user design phase requires the users to participate strongly in the nontechnical design of the system, under the guidence of I.S. professionals. User design is done in a Joint Application Design (JAD) workshop similar to the JRP workshop. In the first two phases the users and executives should play a larger part than the I.S. professionals. Prototyping is used to aid in requirements specification and design. The user does not sign off a paper design, they sign off a CASE representation. Construction Phase The design created during the User Design Phase is added to using I-CASE tools. As each transaction is built it may be demonstrated to the end-users for revision. The CASE environment allows for the continuous changes in design. End-users are closely involved in the construction phase. Testing occurs throughout the process. The I-CASE toolset should generate the code as well as the database descriptions for the final product. Code optimizers may be used to improve the performance of the generated code. Cutover Phase When the cutover phase occurs, a variety of actions are needed, comprehensive testing, training of the end-users, organizational changes and operation in parallel with the previous system until the new system settle in. INCLUDEPICTURE \d \z "http://hebb.cis.uoguelph.ca/~deb/Icons/Lines/eyes_left.gif" INCLUDEPICTURE \d \z "http://hebb.cis.uoguelph.ca/~deb/Icons/Lines/eyes_right.gif"  (Alex Fleming, 2001 Page  PAGE 28 Workshops Design scenarios Prototype development Scenario-based Prototyping Concerned with demonstrating that the requirements define the system that the customer really wants Requirements error costs are high so validation is very important Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error Prototyping is an important technique of requirements validation (:R>dz  ] n  6 E  - J =KUn3~#$V|b;o0;< 5CJ@mH 5B*CJ8mH  5CJ8mH  5CJHmH  6<B*6<B*B*U )ee!] \ ]  G  )ee!] \ ]  G   4 - J {urolif<n    q   H?@?{  |//k h  N {  &G   4 - J h " <=P3Lg~pJ h " <=P3Lg~$>V|6Mb ;o,~{u~rl 7w g T  c GH z  S!OpL)~$>V|6Mb ;o,0Dp,0D;VDX<Rlz#Kg8`7G{xuroif`  2            >    p%;VDX<Rlz#Kg8`p<89(b ~ !&!"""i##)$M$$%%%%&+*D*v**G+V+b+o+,,00)1B1o1127364W5r99h>j>>>jBBB1E;EOG6K;KLRYY[[[[$a%aEaGadpep j!U56CJOJQJ CJOJQJ 6OJQJOJQJ0J5OJQJ jU0J5mH jB*UhmHnH<B*J`7GRf(mb  ~ !&!s!!!!"""""pGRf(mb  ~ !&!s!!!!""""""##i###)$M$$$$$%{xrlfc`  [   Y   W  % r   6C  h%""##i###)$M$$$$$%N%k%%%%-&&&&':'f''''p%N%k%%%%-&&&&':'f'''''+(F(d(((( )4)Z))))))+*D*v****+G+ʗ|yvpjda   | T   b     % 9   B1W h&''+(F(d(((( )4)Z))))))+*D*v****+G+V+b+o+++pG+V+b+o+++++,,!,_,,,,,'-G-s----...m....I/t///00>0a0m0ý~xrolic    * t  Ep     ]   0  >g$+++,,!,_,,,,,'-G-s----...m....I/t///00p0>0a0m00001)1B1o11111 22.2R222733333344454pm00001)1B1o11111 22.2R22273333334445464R4W44445V5W5ti^X H               ?  +De "5464R4W44445V5W5X5g7h7q9r99`;=h>>?AhBiBjBBD$hh & F & FW5X5g7h7q9r99`;=h>>?AhBiBjBBDFOGHJKbLLM$P7PEPkPPPQ.QYQQ~wpib[                     F   _  #DFOGHJKbLLM$P7PEPkPPPQ.QYQQQRRRRSTTU & F @& & F @& QQRRRRSTTUgWhWXXXYY7YIYYY4ZVZ|ZZ[ [p[q[[[[[[ºzrjga^[XUz|} V    U        6  v         _`-.     !UgWhWXXXYY7YIYYY4ZVZ|ZZ[ [p[q[[[[[[[[ \ & F  & F [[[ \b]S__```#a$aHac8cdd*f5f%hBh#iSijj0k=kllmmGoRoRpSpTpcpdppp|yvokhe       ! N        wxy' \b]S__```#a$aHac8cdd*f5f%hBh#iSijj0k=kllm$$$$mmGoRoRpSpTpcpdpppq rrr s)sKs~svttuvvv & F @& & F @&$$$ $eppp:v;v[v]v]x^x~xx΂Ђ:< +-0OP̈DERSSTrsǏȏݏޏ&0l67@AfpIT1IЖSaǘ˘֘Vedw-.5CJCJCJH jU_pq rrr s)sKs~svttuvvv9v:v^vuvvvGwwwx=x>x?x\x]xxz{}<cсPz{|тuŅ ./0PQž                              9Dv9v:v^vuvvvGwwwx=x>x?x\x]xxz{}<$$ & F $$$$cсPz{|тuŅ$$$$ & F  ./0PQR̈ES9Tsȏޏl$ & F QR̈ES9Tsȏޏl͐7Afp1IVedw.j4Qӟ (ƥQRSTUcdfgjϧЧEWl͐7Afp1IVedw.j4 & F .ij4Qҟӟ (xe}ƥNPUbjkϧЧBECJ(CJ86B*CJmH 56B*CJmH  0JmHnH0J j0JU6 j6 jUmH jCJU5CJCJ=4Qӟ (ƥQRSTUcdefghijdd & F ϧЧPBCD & F> & FDE &P . A!"#$%!Dd*LvX  c 4Arad.gifb *f6_ r8 O=d Dn >2 .YUN*f6_ r8 O=dPNG  IHDR*qu[]\݈ypԝ@SQQm]uZ+ p-$ioi)ZIPzNx~@yCxh8}xÏL3XY(## FȐ<+cZ 0I/aL_'#E*`<й8נ`KCs/ V"77qbTmu`K-85OYoK"n}q@ FC\`W3/fxt,ËezX!1}`'8#1b\xzue(yeL0òVZ81+Ӎt&E;Py-NI`LJ+ϻXJB],]<~ӧX>ҵ˚Œ[`t Tc:_ҋhv_?طez":|ғaYX%[%k”ߓ\9NR/1Kwu?pCX.1S 1di¯]vL=h >@'-S\K-$t] ZKb[YGy$f:A~Ad]H ty@r :,B$ V"=_[MT$aIe-$]C!mX nNZzu @S0tgYzz$bi"oKJfXz@ ȔI* i2@*w zȫ>D{ǃ"dՙGqDeŽ7E@1IDar[s7Q,b ~ aX/**`T:hc $ XF$u e _NIb!BԿ"$xR}_&+}+jgNEM6a&4"= h:PEw*r1.c'l0gFxi|:j\8CɆ1 }GKnH2 , ]f4Ao*KOCeC ΐrұ%;N_(nk~K']Kx}5~@KX [ԥH-}G6x%MZz. y%5ތRxC7ތR ,zCZzjݩAmYdlUM6m8&*iD}yO(_ KOFz\uJvB7\:}z;o雏. o.aORH.C. &i7W눑VyU>;O˘M}D Sn7"R1m޿\h_K׮,5 i'fCquY^);"[=NM}>ޓнϓvzG}(zGdݫ-m2vhYwA(}"}t2}boCz굌ߘ=ICz%=X{S'BԕwUݛL7جBInJ}0z$uw#}>* wn*7z яЋ|fb?k<%O!#{G#AIfy!Snjq5K͙zL3Q!Ȳ<ˀ^ 7qm%n=IבxڴAwTWChb)GNo|jklT[4Ynr! ˨`'^*_ Cg6gȹnl4M]@ .}0ONSбSWtCt%K3UG1p37n&}ɕuC{\/6IMy˶\x->j }>j'B@4ɫMC7*7PfAOzzuet5u[ C?tny%ݜ 7]K63+q*=]C/Yp:6XV| ) _rIdE=95e#L9͑ ze4)c[5sthVct*fGiB]Zts.$i S?3мq/}aKSS,l?(rԓ_ҜM[Pxv:\m"/"ol?:LǪ;~@]\$W0~q twJ7X)P)蹘~Fa!?˪ख़~ECPq?l'|b+[\yR]@ _nm/x<;v4 D{~e)3:|e9vf,?:tSm8 4ti/W)'3-p~rCf|x%[EWGwOč2Enj}uO5.:,eo*g}XȂSS ;aauwQG=׎e}< 3%Bϩ[T&N&6֟RNN7WB/8({hEBmiٲK~Gu=t}{G}z^3=oA=VY E:AmBn o؉'[^9"4 ]d,kX:r_l4ǛGijVTf^`6nad{ݰ[=ԲzC__2`K1@EC&"䡿$};#\KӉ l?KKJu}s%tZZof&[R]0/-\= Lq@ y4{ٙ͠(nzQA82dbAyCiG Kzȩ=3䡣[:oY{zy/J~m߫9PWdNj y]"|o}Ï\#>n2}B_ Wy+d\a+}A-+4:[A_F`ZϿ`(s+?gU4##t,z!F\b|=.obځKЕfBrp zFoMYQ仕jP恝Ksq|>ϬѢNxȌRd8tkt;A5ϾҎuP\!DžButqn:.֣g5n_cjV[\] ^TA$iPAc[g>R\z׾Cy%lKPh.mvyM̓.t: hY"',Mxlf2x-̓R!1zAoˆgMǭg^!#\Wx[ӭ[}w@8Qs\17o}Y;&?\-42یāvNz8D:' }@_jL46N^C/{F~'.u92Z:XZ^ސ, _F#TAQGWs}~G?MKz%CB >OZ-s84]Kaںt9Dyhip⻬'FmoxP% W2} 9&}Q)g8DbХoy&u .\nNF$N#t*H}kĝI}ݝTG܍nRNݍCʙdEμC7!^r܂N!g.C7'䡛wdݠ\1tݠ@4̭n~n8cPNG  IHDR~5sBITO0PLTEg bKGDHIDATx o7L@yLkgbz-M?mxNvR {킶3e`Ƚ`ozY k1W ,юq;Xz`?RW|M6e4#ER_mC?h%}>90jf`?!HJl`x nn`K&7DdT&Tj<̓T j&T<qZM< pǝT,׾վb֝MM}|kY L^X3 E;.^k`M-kG<=Q>kő"?;0dGHy:&tC5?)%6Я\L~؀㒭O6Ċ|Et 7*8l:ѾQ>Í7$Y8lokOj[  LCN(?8*ư]U6OZ< XZ0Aئ`ʾHNk51Gj0X=+ \_.NvUBwI?ޒ`k }--1_˖+xL`с}E|+[{6&󼈪]z`ʬ%zۅY lBa`=6iow:Xp; x*FN<ݷB`q uc)X[ U{D[##1f=xhkD`Y9Յ9r-Sq owU#q%˻/z(*Lx$.W/U g49Lo lhlHo1̑l*m#u0Ӏmٵom|˪R+H%5wO`/4\2t+ϱ0W' 6@in L>`pxF-smm * {NTeFV|<u}J R\E'ז|QH"o(6>){ZE;>?cDlUSyVCϡ0xcE.FHb ح06J8ߛ@$> ] ZQ k`Ù*{Ĝ= XX9ƥ42%[k.+٘ h"$L+b7lXh}8Vاd Xz%X9x{*vU΍V7hS =2G>IN \gUKB=:6V'h.7UZ,ZQCV0 x_`E+۟ʃJ l=8M?C]g(``]*Kdr_~4/ը`opycL#ԆE0)+JniI#+5إINvR-jT  JIENDB` [B@BNormal P6B*OJQJhmH nH D@!"D Heading 1$$@&a$:>*CJ KH >@12> Heading 2@&^5CJ<@< Heading 3$x@&6CJ,, Heading 4$@&<A@< Default Paragraph Font,@,Header  9r 4 @4Footer p#CJ&)@& Page Number(U@!( Hyperlink>*B* W`1 Strong5@o@H4$dd@&56B*CJOJQJJoRJ Blockquotehhdd6B*CJOJQJDoDH1$dd@&56B*CJ0KH$OJQJ@o@H2$dd@&56B*CJ$OJQJ@o@H3$dd@&56B*CJOJQJ#:VE'%&(#:V  E-/14<ep.EW_qxG ~`"'+054DU \mvl4DEXZ\^`bdfgikmopstuwyz{J ,G%G+m0W5Q[pQEY[]acehjlnrvi:::$]E]F]dlll:r[r\r]t~tt~~~:; +,NOECCCCCCCCCC '*4!t8)*@),(    H xaxa1 ?  "  T? Z<P B2  3 2 BB  3 2 r   B2 L" ? B ! 3 2 H " C G<2 #  B`CXDE(F>  8(0HH`X @    $  BC8DEF>` @8@  Z % S % Z & S  &  Z ' S ' Z ( S  (   ) S h$B`CXDE(F>  8(0HH`X @   B S  ?8UVWXYZ[\]^_`aE)t(t&)j~ t%t)O  t' t$C>t#)Et"0  t!t  & t)n t)3t`!S t2388<<1A;AVA[AWCdCHHIIjk'*#0=fo܉Za7>LW%/ǔ˔֔fh'3ckÙʙיߙ! ,4 nxϡ֡8FdF[; # 8920cdfhϣУBCF Alex Fleming%C:\PrestonCollege\RAD\Prototyping.doc Alex Fleming?C:\WebPages\afleming\lectures\rapid-application-development.doc Alex FlemingFC:\WINDOWS\TEMP\AutoRecovery save of rapid-application-development.asd Alex Fleming?C:\WebPages\afleming\lectures\rapid-application-development.doc Alex Fleming?C:\WebPages\afleming\lectures\rapid-application-development.doc Alex FlemingFC:\WINDOWS\TEMP\AutoRecovery save of rapid-application-development.asd Alex Fleming?C:\WebPages\afleming\lectures\rapid-application-development.doc Alex Fleming?C:\WebPages\afleming\lectures\rapid-application-development.doc Alex Fleming?C:\WebPages\afleming\lectures\rapid-application-development.doc Alex Fleming?C:\WebPages\afleming\lectures\rapid-application-development.doc|+9;,#Eg,h^`.*..p.@ .......p.@ .....0o()/o()|,C#Eg+9;CԓC(C|CДC$CxCCC\CCC8C @CJOJQJo(lC ^h@CJ(OJQJo(nCX@CJ(OJQJo( 4C`@CJ OJQJo(" C @CJOJQJo( ܔC t @CJ@OJQJo(" 0C@CJ8OJQJo( ȕC @h OJQJo(hC~0@CJOJQJo(C @CJOJQJo( C @CJOJQJo(  @ccQCccE`@G:Times New Roman5Symbol3& :Arial7& VerdanaEMonotype Sorts"qhL\aPD D 9"0drrRapid Application Development Alex Fleming Alex Fleming RhubarB26 Oh+'0 0< X d p |Rapid Application DevelopmentMiapi Alex Flemingtiolexlex Normal.dotg Alex Flemingtio6exMicrosoft Word 8.0e@e@h ʪ@^؋@$Q ՜.+,D՜.+,H hp|  yDrj Rapid Application Development Title\(RZ _PID_GUID _PID_HLINKSAN{4D6332C0-211A-11D4-8F0E-0000E8314749}A q&h>rad.gifD[lifecycles-i4.gif  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|~Root Entry F`RZ Data } *1Table&WordDocument"SummaryInformation(DocumentSummaryInformation8CompObjjObjectPool    FMicrosoft Word Document MSWordDocWord.Document.89q