User:Janfil mejia
From Wikipedia, the free encyclopedia
==ADVANTAGES OF PROTOYPING
Prototypes can be easily changed
May provide the proof of concept necessary to attract funding
Early visibility of the prototype gives users an idea of what the final system looks like
High user satisfaction
Encourages active participation among users and producer
Enables a higher output for user
Cost effective (Development costs reduced) * Increases system development speed
Make changes quickly and easily.
==DISADVANTAGES OF PROTOTYPING
User’s expectation on prototype may be above its performance
Possibility of causing systems to be left unfinished or implemented before they are ready.
Producer might produce a system inadequate for overall organization needs
Producer might get too attached to it (might cause legal involvement)
Often lack flexibility
Not suitable for large applications
Project management difficulties.
==Another concepts of SOFTWARE PROTOTYPING
The prototyping model is a software development process that begins with requirements collection, followed by prototyping and user evaluation. Often the end users may not be able to provide a complete set of application objectives, detailed input, processing, or output requirements in the initial stage. After the user evaluation, another prototype will be built based on feedback from users, and again the cycle returns to customer evaluation. The cycle starts by listening to the user, followed by building or revising a mock-up, and letting the user test the mock-up, then back.
In the mid-1980s, prototyping became seen as the solution to the problem of requirements analysis within software engineering. Prototypes are mock-ups of the screens of an application which allow users to visualize the application that is not yet constructed. Prototypes help users get an idea of what the system will look like, and make it easier for users to make design decisions without waiting for the system to be built. When they were first introduced the initial results were considered amazing. Major improvements in communication between users and developers were often seen with the introduction of prototypes. Early views of the screens led to fewer changes later and hence reduced overall costs considerably.
However, over the next decade, while proving a useful technique, it did not solve the requirements problem:
Managers, once they see the prototype, often have a hard time understanding that the finished design will not be produced for some time. Designers often feel compelled to use the patched-together prototype code in the real system, because they are afraid to 'waste time' starting again. Prototypes principally help with design decisions and user interface design. However, they can not tell what the requirements were originally. Designers and end users can focus too much on user interface design and too little on producing a system that serves the business process.
[edit] Electronics prototyping In electronics, prototyping means building an actual circuit to a theoretical design to verify that it works, and to provide a physical platform for debugging it if it does not. The prototype is often constructed using techniques such as wire wrap or using veroboard or breadboard, that create an electrically correct circuit, but one that is not physically identical to the productionized product.
A technician can build a prototype (and make additions and modifications) much quicker with these techniques — however, it is much faster and usually cheaper to mass produce custom printed circuit boards than these other kinds of prototype boards. This is for the same reasons that writing a poem is fastest by hand for one or two, but faster by printing press if you need several thousand copies.(END)
==WHAT IS PROTOTYPING?
Prototyping is the process of building a model of a system. In terms of an information system, prototypes are employed to help system designers build an information system that intuitive and easy to manipulate for end users. Prototyping is an iterative process that is part of the analysis phase of the systems development life cycle.
During the requirements determination portion of the systems analysis phase, system analysts gather information about the organization's current procedures and business processes related the proposed information system. In addition, they study the current information system, if there is one, and conduct user interviews and collect documentation. This helps the analysts develop an initial set of system requirements.
Prototyping can augment this process because it converts these basic, yet sometimes intangible, specifications into a tangible but limited working model of the desired information system. The user feedback gained from developing a physical system that the users can touch and see facilitates an evaluative response that the analyst can employ to modify existing requirements as well as developing new ones.
Prototyping comes in many forms - from low tech sketches or paper screens(Pictive) from which users and developers can paste controls and objects, to high tech operational systems using CASE (computer-aided software engineering) or fourth generation languages and everywhere in between. Many organizations use multiple prototyping tools. For example, some will use paper in the initial analysis to facilitate concrete user feedback and then later develop an operational prototype using fourth generation languages, such as Visual Basic, during the design stage.
==SOME ADVANTAGES OF PROTOTYPING_
Some Advantages of Prototyping:
Reduces development time.
Reduces development costs.
Requires user involvement.
Developers receive quantifiable user feedback.
Facilitates system implementation since users know what to expect.
Results in higher user satisfaction.
Exposes developers to potential future system enhancements.(END)
==Some Disadvantages of Prototyping
Can lead to insufficient analysis.
Users expect the performance of the ultimate system to be the same as the prototype.
Developers can become too attached to their prototypes
Can cause systems to be left unfinished and/or implemented before they are ready.
Sometimes leads to incomplete documentation.
If sophisticated software prototypes (4th GL or CASE Tools) are employed, the time saving benefit of prototyping can be lost.(END)
==why prototyping is important??
Because prototypes inherently increase the quality and amount of communication between the developer/analyst and the end user, its' use has become widespread. In the early 1980's, organizations used prototyping approximately thirty percent (30%) of the time in development projects. By the early 1990's, its use had doubled to sixty percent (60%). Although there are guidelines on when to use software prototyping, two experts believed some of the rules developed were nothing more than conjecture.
In the article "An Investigation of Guidelines for Selecting a Prototyping Strategy", Bill C. Hardgrave and Rick L. Wilson compare prototyping guidelines that appear in information systems literature with their actual use by organizations that have developed prototypes. Hardgrave and Wilson sent out 500 prototyping surveys to information systems managers throughout the United States. The represented organizations were comprised of a variety of industries - educational, health service, financial, transportation, retail, insurance, government, manufacturing and service. A copy of the survey was also presented to a primary user and a key developer of two systems that the company had implemented within the two years of the survey.
There were usable survey results received from 88 organizations representing 118 different projects. Hardgrave and Wilson wanted to find out how many of the popular prototyping guidelines outlined in literature were actually used by organizations and whether compliance affected system success (measured by the user's stated level of satisfaction). It should be noted that, although not specifically stated, the study was based on the use of "high tech" software models, not "low tech" paper or sketch prototypes.
Based on the results of their research, Hardgrave and Wilson found that industry followed only six of the seventeen recommended in information system literature. The guidelines practiced by industry whose adherence was found to have a statistical effect on system success were:
Prototyping should be employed only when users are able to actively participate in the project.
Developers should either have prototyping experience or given training.
Users involved in the project should also have prototyping experience or be educated on the use and purpose of prototyping.
Prototypes should become part of the final system only if the developers are given access to prototyping support tools.
If experimentation and learning are needed before there can be full commitment to a project, prototyping can be successfully used.
Prototyping is not necessary if the developer is already familiar with the language ultimately used for system design.
Instead of software prototyping , several information systems consultants and researchers recommend using "low tech" prototyping tools (also known as paper prototypes or Pictive), especially for initial systems analysis and design. The paper approach allows both designers and users to literally cut and paste the system interface. Object command and controls can be easily and quickly moved to suit user needs.
Among its' many benefits, this approach lowers the cost and time involved in prototyping, allows for more iterations, and gives developers the chance to get immediate user feedback on refinements to the design. It effectively eliminates many of the disadvantages of prototyping since paper prototypes are inexpensive to create, developers are less likely to become attached to their work, users do not develop performance expectations, and best of all, your paper prototypes are usually "bug-free" (unlike most software prototypes)!(END)
PROTOTYPING..................
PICTURE
DEFINITION OF PROTOTYPE
CHARACTERISTICS OF A PROTOTYPE
THE PROTOTYPING PROCESS
WHEN DO YOU PROTOTYPE?
WHAT TO CONSIDER UP-FRONT BEFORE BUILDING A PROTOTYPE
PROBLEMS CAUSED AND CURED BY PROTOTYPING
PROTOTYPING TOOLS
EVALUATION OF PROTOTYPING
)PICTURE..
DEFINITION OF PROTOTYPE ,........ An easily modified and extensible model (representation, simulation or demonstration) of a planned software system, likely including its interface and input/output functionality
CHARACTERISTICS OF A PROTOTYPE
TYPES OF PROTOTYPE
LOW-FIDELITY versus HIGH-FIDELITY
LOW-FIDELITY A set of drawings (e.g., storyboard) that provide a static, non-computerized, non-working mock-up of user interface for the planned system
HIGH-FIDELITY A set of screens that provide a dynamic, computerized, working model of the planned system
EXPLORATORY versus EXPERIMENTAL versus OPERATIONAL
EXPLORATORY A throw-away prototype used to clarify project goals, to identify requirements, to examine alternative designs, or to investigate a large and complex system
EXPERIMENTAL A prototype used to validate system specifications
OPERATIONAL An iterative prototype that is progressively refined until it becomes the final system
HORIZONTAL versus VERTICAL
HORIZONTAL A prototype that models many features but with little detail
a horizontal slice of a system's structure chart from the top down to a specific depth
most useful in the early stages of design
purpose is to test the overall interaction metaphor, so includes common functions that the user is expected to perform frequently
VERTICAL A prototype that models few features but with much detail
a vertical slice of a system's structure chart from top to bottom
most useful in the later stages of design
purpose is to test details of the design
DIAGONAL A prototype that is horizontal down to a particular level, then vertical below that point
GLOBAL versus LOCAL
GLOBAL A prototype of the entire system
an expanded horizontal prototype that models a greater number of features and covers multiple levels of the system's structure chart
useful throughout the design process
LOCAL A prototype of a single usability-critical system component
a vertical prototype that is focused on one feature
useful at some specific stage of the design process
DIMENSIONS OF PROTOTYPING
EXECUTABILITY Will the prototype be runnable and, if so, what does that mean?
CHAUFFEURED PROTOTYPE "runnable" in the VERY LOOSE SENSE that the prototype allows a walkthrough to be performed
ANIMATION PROTOTYPE runnable in the LOOSE SENSE that it is executes frame by frame in "slide show" mode on a computer
TURING PROTOTYPE "runnable" in the sense that it executes in "slide show" mode BUT allows a third party, hidden from view, to pick the next slide based on user input (also called "Wizard of Oz" prototyping)
INTERACTIVE PROTOTYPE runnable in the STRICT SENSE that it executes on the computer AND responds to user input in real time
FUNCTIONAL PROTOTYPE runnable in the VERY STRICT SENSE that it executes on the computer, responds to live input, and performs some of the expected computations
MATURATION Will the prototype be improved by stages and, if so, will it eventually grow into the final product?
REPRESENTATION What level of fidelity will the prototype achieve?
SCOPE Will the prototype be limited to specific areas of functionality?
CHARACTERISTICS OF A GOOD NON-DISPOSABLE PROTOTYPE
EXECUTABILITY Works sufficiently well with live user input to permit usability testing
MATURATION Can evolve, given sufficient refinement, into the final product
REPRESENTATION Has the "look and feel" and performance characteristics of the planned system
SCOPE As a minimum, simulates the 20% of the functions that customers will use 80% of the time
THE PROTOTYPING PROCESS Many variations
Perform customer needs analysis in a JAD session but leave requirements incomplete.
Build a low-fidelity prototype to clarify initial requirements.
Iterate (re-specify, re-design, re-evaluate) until the team, both users and developers, agree that the fidelity and completeness of the evolving prototype are sufficiently high.
Freeze these specifications.
Finish building the product exactly as prototyped.
NOTE: The prototyping process experiences a series of birthdays while traditional software development experiences a series of deadlines.
WHEN DO YOU PROTOTYPE?
BEFORE THE BEGINNING to show proof of concept to senior management
IN THE BEGINNING to gather initial user requirements
AFTER THE BEGINNING to validate evolving user requirements
IN THE MIDDLE STAGES to validate system specifications
IN MIDDLE AND LATER STAGES to pre-train users or to create a marketing demo
IN THE LATER STAGES to explore solutions to specific usability or design problems
WHAT TO CONSIDER UP-FRONT BEFORE BUILDING A PROTOTYPE
Breadth of functionality needed in the prototype at first, later on
Choice of prototyping tool and its limitations
Completion criteria for the iteration cycle
Composition of the team (users, developers, other stakeholders)
Level of fidelity needed in the prototype at first, later on
Maximum length of an iteration cycle
Purpose of the prototype at first, later on
Ways to manage conflict between team members, build consensus
PROBLEMS CAUSED AND CURED BY PROTOTYPING
PROTOTYPING MAY ADDRESS THE PROBLEM OF ...
communication between developers and customers
customer acceptance
delivering early proof of concept
fuzziness in early stages of design
gathering valid requirements
increasing constructive user participation
managing change requests
product invisibility
quality assurance
PROTOTYPING MAY INTRODUCE THE PROBLEM OF ...
deciding how much iteration is enough
gauging progress without traditional milestones
managing conflict between developers and customers
managing the schedule for a development cycle that is essentially open-ended
processing excess change requests from customers
runaway customer expectations
DEALING WITH PARTICULAR PROBLEMS
HOW DO YOU PREVENT RUNAWAY EXPECTATIONS DURING PROTOTYPING?
Build the expected performance into the prototype, using delays (timing loops) if necessary.
Develop realistic specifications.
Distinguish between primary and secondary requirements.
Give customers a crash course in software development.
HOW DO YOU KNOW WHEN YOU ARE DONE PROTOTYPING?
When you run out of time or money (default criterion)
When the prototype meets all the requirements of the final system
When the prototype has a limited purpose (e.g., gathering initial requirements) and that purpose has been achieved
When, in horizontal prototyping, you reach the target level (depth) in the system structure chart
When developers and users jointly agree to move on to the next stage
PROTOTYPING TOOLS
FEATURES NEEDED IN A RAPID PROTOTYPING TOOL
MOST IMPORTANT FEATURES
Should create a working prototype with which users can interact
Should make it easy to create, develop and modify screens
Should simulate the look and feel of the planned interface
OTHER DESIRABLE FEATURES
Should allow calls of external procedures and programs
Should allow playback of user trials
Should allow scientific collection and review of user interaction data
Should be able to simulate the expected performance characteristics of the planned system (e.g., by using timers)
Should exhibit the look and feel of the target operating system
Should generate much of the code needed to implement the interface design
Should import reusable software components of various kinds
Should import text, graphics, sound and other media
Should leverage industry-standard APIs and standard libraries
Should make it easy to change task order
Should make it easy to change window order
Should make it easy to create simple animations
Should make it easy to modify tasks
Should make it easy to sequence and re-sequence windows
Should provide a seamless transition from design to implementation
TYPES OF PROTOTYPING TOOLS From less formal to more formal
Pencil and paper
Drawing software
Demo makers (e.g., Demo-It)
Animation and slide-show software
Perl + Motif + Tcl/Tk (UNIX)
"Visual" RAD tools such as Visual Basic, Optima++ and Borland Delphi
4GLs
UIMSs (User Interface Management Systems)
Executable specification languages (VDM variants)
EVALUATION OF PROTOTYPING
BENEFITS AND RISKS OF PROTOTYPING
ADVANTAGES (BENEFITS)
NUMBER 1 BENEFIT Prototypes may be easily changed or even discarded.
NUMBER 2 BENEFIT Prototyping may improve communication between and among developers and customers
NUMBER 3 BENEFIT Users may be more satisfied with systems developed using prototyping.
A prototype may provide the proof of concept necessary to attract funding.
A prototype may serve as a marketing tool.
A prototype may serve as the basis for operational specifications.
Early visibility of the prototype may help management assess progress.
Exploratory prototyping allows productive work to proceed despite initial uncertainties.
Prototypes may demonstrate progress at an early stage of development.
Prototypes may provide early training for future users of the system.
Prototyping may prevent unpleasant surprises by calling attention to incomplete or inconsistent requirements, or to missing functionality.
Prototyping may produce some useful deliverables even if the project runs out of time or money.
Prototyping may reduce misunderstandings between and among developers and customers.
Prototyping may reduce redesign costs if problems are detected early when they are cheap to fix.
Prototyping may reduce the time required for testing if problems are detected early when they are cheap to fix.
Prototyping may require less effort (43% less, according to Boehm, Gray & Seewaldt, 1984) than conventional development.
Prototyping may result in a 50-50 partnership between users and developers where both experience "ownership".
Prototyping may result in a product that is a better fit for the customer's requirements.
Prototyping may save on initial maintenance costs because, in effect, customers are doing "acceptance testing" all along the way.
Prototyping may strengthen requirements specifications.
Systems produced through prototyping may be judged easier to learn and easier to use.
The horizontal prototyping method works nicely as a complement to structured analysis.
The prototyping environment less vested in a particular design, hence more open to change and innovation.
Use of prototypes may flush out change requests earlier, when they are cheaper to process.
Users may understand prototypes better than paper specifications.
Using prototyping during development may reduce the amount of code that is finally written (by 60%, according to Boehm, Gray & Seewaldt, 1984).
PITFALLS (RISKS)
NUMBER 1 RISK Prototpying may encourage an excess of change requests.
NUMBER 2 RISK Working prototypes may lead management and customers to believe that the final product is almost ready for delivery.
NUMBER 3 RISK The excellent (or disappointing) performance characteristics of prototypes may mislead the customer.
Customers may not be prepared to provide the level or frequency of feedback required for iterative prototyping.
Customers may not be willing to participate in the iteration cycle over the long haul
Developers may have difficulty writing the back-end code needed to support the slick front-end interface designed with the prototyping tool.
Due to time and market constraints, system specifications may be frozen before the prototyping process has reached a definitive stage.
During prototyping, the only "design specification" is the prototype itself, which may allow uncontrolled change.
Early prototypes may be of low fidelity, dismissed as toys.
Hi-fidelity prototypes may be mistaken for a real product.
Important system characteristics (e.g., performance, security, robustness and reliability) may have been ignored during prototype development.
It may be impossible to prototype mission- or safety-critical system functions.
Iterative prototyping may be difficult for management to plan and schedule.
Prototypes may become over-evolved, straining to incorporate secondary functionality even though that will take disproportionately more development time.
Prototypes may embody simplifications and other inaccuracies.
Prototypes may oversell the product.
Prototypes of complex systems may themselves be rather complex.
Prototyping is an adaptive process that may not exhibit well-defined phases.
Prototyping may continue too long because there may be no well-defined completion criterion.
Prototyping may force developers to change design philosophies (e.g., switch to a bottom-up or an event-driven model).
Prototyping may provide little room for testing NON-functional system requirements.
Prototyping may stall if members of the team do not have enough decision-making authority.
Prototyping, because it may be less controlled than conventional development methods, may lead to a reduction in programmer discipline.
Specifications that emerge during later prototyping may reduce the structural integrity of the partially designed system (e.g., increase coupling between modules).
The context of use for a prototype may be very different from the context of use for the final system.
There is no guarantee that the positions of developers and customers will converge during the iteration cycle.
WHEN PROTOTYPING WORKS AND WHEN IT DOESN'T
PROTOTYPING IS MORE LIKELY TO SUCCEED WHEN ...
used as a means to achieve early usability testing
used to compare alternative designs (the "dueling prototypes" technique)
used to create a "living" specification
used to escape from the rigid serial pattern imposed by the traditional software development life cycle
used to evaluate a proposed interface
used to explore the effect of change requests
used to expose new or unexpected requirements
used to identify market requirements
used to involve users in the design process
used to model a system that has a significant user interface component
used to model a system that is relatively large and complex
used to provide a common basis for good communication between developers and customers
used to stimulate customer input during requirements gathering
used within a rapid prototyping tool
PROTOTYPING IS MORE LIKELY TO FAIL WHEN ...
no clear terminating criterion has been established to end the iterative development cycle
the expectations of customers are allowed go grow beyond reasonable bounds
the functionality of an operational prototype does not scale up to the functionality required of the final system
the opinions of developers and customers diverge during the iterative phase
the project is too small to justify prototyping
the prototype is mistaken for the promised product
used to model systems that present no external interface (e.g., embedded systems)
used to gauge the future performance of the planned system
used to market software that does not exist
