core technique, and is itself ISO 9001 approved. It expands upon most understood definitions of a prototype. According to DSDM the prototype may be a diagram, a business process, or even a system placed into production. DSDM prototypes are intended to be incremental, evolving from simple forms into more comprehensive ones. DSDM prototypes can sometimes be throwaway or evolutionary. Evolutionary prototypes may be evolved horizontally (breadth then depth) or vertically (each section is built in detail with additional iterations detailing subsequent sections). Evolutionary prototypes can eventually evolve into final systems. The four categories of prototypes as recommended by DSDM are: Business prototypes – used to design and demonstrates the business processes being automated. Usability prototypes – used to define, refine, and demonstrate user interface design usability, accessibility, look and feel. Performance and capacity prototypes – used to define, demonstrate, and predict how systems will perform under peak loads as well as to demonstrate and evaluate other non-functional aspects of the system (transaction rates, data storage volume, response time, etc.) Capability/technique prototypes – used to develop, demonstrate, and evaluate a design approach or concept. The DSDM lifecycle of a prototype is to: Identify prototype Agree to a plan Create the prototype Review the prototype Operational prototyping Operational prototyping was proposed by Alan Davis as a way to integrate throwaway and evolutionary prototyping with conventional system development. "It offers the best of both the quick-and-dirty and conventional-development worlds in a sensible manner. Designers develop only well-understood features in building the evolutionary baseline, while using throwaway prototyping to experiment with the poorly understood features." Davis' belief is that to try to "retrofit quality onto a rapid prototype" is not the correct method when trying to combine the two approaches. His idea is to engage in an evolutionary prototyping methodology and rapidly prototype the features of the system after each evolution. The specific methodology follows these steps: An evolutionary prototype is constructed and made into a baseline using conventional development strategies, specifying and implementing only the requirements that are well understood. Copies of the baseline are sent to multiple customer sites along with a trained prototyper. At each site, the prototyper watches the user at the system. Whenever the user encounters a problem or thinks of a new feature or requirement, the prototyper logs it. This frees the user from having to record the problem, and allows him to continue working. After the user