Petter Nielsen Information Systems/IFI/UiO 1 Software Prototyping

Petter Nielsen Information Systems/IFI/UiO 2 Software prototyping Intention/aim of prototyping In relation with general prototyping Approaches to and types of prototyping Strengths and weaknesses of prototyping

Petter Nielsen Information Systems/IFI/UiO 3 Software prototyping Suggestion for definition: “An early demonstration of relevant parts of a desired IS, which are to be combined with other processes in system development to improve the final system“ Early feedback about meeting users needs, as well as technical feasibility and efficiency Demonstrations provides “tangible” models to evaluate Communication and learning: Internal and external

Petter Nielsen Information Systems/IFI/UiO 4 Motivation You only know to build the system when you have built it While working with prototypes, developers learns about the system Preferred to postpone completion of specifications until system construction An executable specification

Petter Nielsen Information Systems/IFI/UiO 5 Conditions for prototyping Have to be a learning process –A dialog –Possible to criticize –Possible to implement the knowledge Early availability for users and developers Easy to change as needed

Petter Nielsen Information Systems/IFI/UiO 6 Terminology of prototyping Not prototyping in a strict sense: –Engineering: A well defined phase were a model is produced in advance, exhibiting all the essential features of the final product, for use as a test specimen and outside the further production Software prototyping: –In the context of the development process –No clear relation between the prototype and final system –Interest in the process and not the prototype as a product: Learning –Reproduction is not a challenge

Petter Nielsen Information Systems/IFI/UiO 7 Approaches to prototyping Approaches to prototyping, according to the goals we want to achieve: –Exploratory –Experimental –Evolutionary

Petter Nielsen Information Systems/IFI/UiO 8 Exploratory prototyping To handle the communication challenge between users and developers: –User don’t know which help IS can give them, and developers does not know users needs To be used in the early phases of development clarifying requirements Alternatives must be available for discussion Only recommended if tools is available to develop with a minimum of effort – cost and time Normally thrown away

Petter Nielsen Information Systems/IFI/UiO 9 Experimental prototyping Proposed solution evaluated by experimental use, also handling communication challenge Appropriate in any phase after initial specification The prototype can serve as: –Complementary to the specification –Refinement of parts of the specification –Step between specification and implementation Can be a throw-away or become a part of or the system

Petter Nielsen Information Systems/IFI/UiO 10 Evolutionary prototyping Far away from the original term: An approach with fixed requirements does not suffice Continuous process of adaptation to changing requirements Two forms: –Incremental Basis in existing practice and substitution over time –Evolutionary Not a focus on capturing all requirements in advance but in cycles

Petter Nielsen Information Systems/IFI/UiO 11 Horizontal and vertical prototyping Horizontal –Only specific layers of system is implemented Vertical –Selected parts down through all layers Functionality Data model User-interface

Petter Nielsen Information Systems/IFI/UiO 12 Relation to the final system –Prototype proper In parallel with the real system Illustrates specific parts of the system: User interface or functionality Several small to address different problems Throw-away –Breadboard Clarifying construction related questions Based on specifications Not related to users Throw-away –Pilot system Not only for testing but also employed in the system No clear distinction between the prototype and the system Requires more elaborated design than proper and breadboard

Petter Nielsen Information Systems/IFI/UiO 13 Summary Type of prototypeExploratoryExperimentalEvolutionary Main aimLearningEvaluationAccommodate change Relation to final system Proper/breadboard Throw-away Proper/breadboard Throw-away or components Pilot system The final system

Petter Nielsen Information Systems/IFI/UiO 14 Strengths and weaknesses of prototyping Introducing communication and feedback into software development methodology Can lead to more adequate systems if used appropriate Early demonstration of operational version Easy way of involving the users: The feel of participation, ownership and commitment After successful evaluation, the prototype can be used as a teaching environment Prepares the organization by giving a foretaste No guaranty for real user participation Requires a willingness to accept criticism and changes Problems with multiple prototypes Prototypes creates expectations: Differences in final system and prototype without user consent will lead to acceptance problems