Prototyping CS 351 Software Engineering AY 2004 Scenario

Prototyping CS 351 - Software Engineering (AY 2004)

Scenario Customer: “We would like the word processor to check the spelling of what is typed in. We also need the checking to take place very quickly”. Developer: “OK. What sort of features do you want? I mean, aprt from speed, how would you like the system to perform the spell check? ” Customer: “Oh! We’re not really sure. All we’d need is for the computer to make sure that our text is spelled correctly. But, could the computer ask us for the correct spelling if it came across a word that it didn’t know about? ” Developer: “Yes, that’s possible. ” Customer: “… and what if we wanted the computer to skip certain words? ” Developer: “What kind of word? ” Customer: “Words that we told it to ignore. ” Developer: “Yes, I see. I think that would be possible too. ” Customer: “How would the system know that words are spelled correctly? ” Developer: “The best way to do this, would be for the system to have a dictionary of known words, and the system would check your text against these words”. Customer: “I’m having difficulty visualizing how that would work for us. Would it be possible for us to see how this would work on the computer? ” Developer: “Yes. I could build a prototype to show you how this would work. You could use the prototype and see if it is actually what you needed. It will also help me to better understand your needs as well. ” CS 351 - Software Engineering (AY 2004) 2

What is a prototype? • • Anything that approximates any aspect of your final product! Why prototype? – To gain a better understanding of a problem. • Will the proposed approach work? Resolve unknowns. – To give the client a “feel” for what the final product will do/look like. • This may assist in clarifying requirements. – Communication • Management, customers, vendors, financiers, … – Integration • Will all the pieces/components fit? – Milestones • Is the project of schedule? – Detect problems/incompatibilities. CS 351 - Software Engineering (AY 2004) 3

Types of prototype • • Experimental – Focused on specific aspects of the project. Alpha – Almost complete system given to trusted and valued clients with the aim of identifying bugs and areas of improvement. Beta – Complete system. Last chance to find bugs before final production. Preproduction – Pilot production system. Incorporates all changes from previous prototypes. CS 351 - Software Engineering (AY 2004) 4

Planned vs unplanned • • Planned prototyping – Reduces risk – May reduce time to market – May reduce cost Unplanned prototyping – Increased time to market – Increased cost CS 351 - Software Engineering (AY 2004) 5

Step-by-step 1. Define the purpose(s) of the prototype. 2. Establish what is to be done as part of the prototype (and what is not). 3. Determine the form of the prototype. 4. Set design plan and establish cost. 5. Define tests to be conducted and data to be collected, CS 351 - Software Engineering (AY 2004) 6

Pitfalls • • Prototype doesn’t contribute to project goals. Prototype delays time to market. Schedule is too tight to integrate the results of the prototype. Excessive cost. CS 351 - Software Engineering (AY 2004) 7

Prototype process model • • • Similar to other types of software development, the prototyping process should follow a defined software process model. Analyze requirements – The developer needs to understand the content and nature of the customers initial requirements. – Determine the functionality to be represented in the prototype. Prototype design – Chose a suitable implementation approach for the prototype. – The prototype design should be baseded on the results of the analysis of the requirements and the choice of implementation. Prototype construction – Actually code the prototype Evaluation – Evaluate the prototype and incorporate new knowledge into the product requirements and design. CS 351 - Software Engineering (AY 2004) 8

Analyze requirements • • • The functionality of the prototype should focus on the requirements that are unclear or fuzzy. Decide on the kind of prototype: – Throwaway prototyping – supports the rapid development of a trail version of the functional behavior for demonstration purposes. Aims to clarify requirements knowing that additional requirements are likely to be uncovered. – Evolutionary prototyping – requirements are well understood but there is a need to make sure that the implementation strategy is appropriate. The prototype may find its way into the final product. It is important to keep the client informed about the nature of the prototype. – Limited functionality – does not posses full set of features or performance characteristics of the final version. CS 351 - Software Engineering (AY 2004) 9

Spell check (again) • • • In the spell check example, we build a throwaway prototype to concentrate on the skipping of words. Requirements of the prototype: 1. The word processing system should possess a means of checking the spelling of inputted text and reporting incorrectly spelled words. 2. The system should provide a means of changing incorrectly spelled words. 3. The system should possess a dictionary of correctly spelled words against which the input text is compared. 4. The dictionary should be expandable so that users can add new words. 5. During the spell check process, the user should be able to ignore the spelling of any word regardless of whether it is spelled correctly or not. Assumptions about the requirements should be recorded and presented to the client during prototype evaluation. CS 351 - Software Engineering (AY 2004) 10

Prototype design • • • To construct a prototype, a suitable implementation approach must be used. The approach must offer features that satisfy the general requirements of prototyping: rapidity and ease of modification. An approach that relies on an overly complex and lengthy development cycle is obviously unsuitable. During the design of a throwaway prototype, performance is not a critical factor, so efficiency of design is not a priority. Since the prototype will be discarded after use: – Maintainability or elegance of the design is not an important consideration. – Large amount of documentation is also not required. – Keep functionality to a minimum – focus on the unclear or fuzzy requirements. CS 351 - Software Engineering (AY 2004) 11

Prototype construction • During the design of the spell check prototype, three tasks were performed: – User interface construction – Implementation of functional behavior – Development of the data model. Developer Customer User Interface Functional Behavior Data Model CS 351 - Software Engineering (AY 2004) 12

Prototype construction • • The aim of the prototype is to provide a working system in the least possible time. For the spell check example, design decisions to achieve this goal include: – Not to include any test entry facilities – use existing tools for this purpose. Our focus is on the spell checking subsystem. – Text-based output facilities. The correctly spelled output is saved to a file for validation purposes. – Display the current state of the spell checking process – feedback information for both the developer and the client. A separate display panel might be used to do this, even though it might not be part of the final product. CS 351 - Software Engineering (AY 2004) 13

Prototype construction – data model • • In terms of the data model, the prototype is no difference from any other piece of software in that it requires information in some form to process. – Storage – in memory, or on disk? – How used? – What needs to be modeled? – Volatility/persistence of the data? Spell check prototype: – Words read in from and written to a separate file. Therefore we need to read words into memory. An array of words is sufficient for the purposes of the prototype. – Where to store checked words. For the prototype, we dicide to simply write them to an output file for verification later. – The dictionary. The correctly spelled words is persistent and therefore stored in a disk file. They need to be stored in memory as the program runs, so we elect to keep them in an array. CS 351 - Software Engineering (AY 2004) 14

User evaluation • Once the prototype is complete, interested parties should use it and provide feedback to the developer. Developer: “The ignore word function simply skips the current word which is incorrect. ” Customer: “… yes but what if the same word crops up again and again? I will have to keep skipping each occurrence with the ignore word button each time, won’t I? ” Developer: “Yes. ” Customer: “Could it be possible for me to skip all occurrences of that particular word in one go? ” Developer: “Do you mean an ‘ignore all’ function? ” Customer: “Yes, something like that …” CS 351 - Software Engineering (AY 2004) 15

Evolution • • The additional requirements identified can be incorporated into the spell check prototype. The additional requirements are: – The need to ignore all occurrences of a particular word. – To change the spelling of all the occurrences of a particular word. – The need for separate dictionaries. E. g. , this feature could be used to allow for different spelling of certain words to be checked for, I. e. , difference between Australian and US spelling (colour vs color, specialise vs specialize, …) CS 351 - Software Engineering (AY 2004) 16