The Logic behind Creating Software Prototypes from a Usability Point of View - Case Study Example

? The Logic behind creating Software Prototypes from a usability point of view, and how they support Human centered Design I. Abstract and Introduction A. Aims and objectives of the paper Just like the topic states, this paper is aimed at explaining, clarifying, and exploring the essence of creating software prototypes from a usability point of view, and how they support human centered design. At breadth, the objectives are to present an accurate and credible argument for the creation of software prototypes by referring to relevant and up to date literature. II. Background A. Mention why prototyping has become necessary The movie Psycho is a perfect example of this technique (Source 1). Automobile manufacturers, architects, and sculptors develop models: circuit developers make “bread-boards”, aircraft designers test prototypes; artists usually experiment with working sketches. B. Identify key terms (software development cycle, prototyping, piloting, usability, human centered design, etc.) Software development life cycle (abbreviated as SDLC); prototyping; usability; piloting; and human centered design are the key terms that will be used and mentioned a lot in this paper (Source 1). Of course there are other terms that will be used but they are not as important as the abovementioned. C. Discuss types of prototyping used There are 4 types of prototyping, but only 2 are predominant and commonly used. They include the following: a) Throwaway Prototyping Also known as rapid or close-ended prototyping and refers to the development of a model that will be finally be discarded rather than forming a part of the eventual delivered software. After accomplishing preliminary requirements collection, a simple functioning model of the system is built to visually demonstrate to users what their requirements may be when they are implemented into a complete system. Throwaway prototyping involves the creation of working models of different parts of a system at an extremely early stage, after a seemingly short investigation. The method employed in constructing it is normally quite informal, the most critical factor being the pace at which the model is released (Source 2). The model then becomes the foundation from which users can re-evaluate their expectations and clarify their needs. When this has been realized, the prototype model is discarded (disposed of; thrown away) and the system is officially developed based on the highlighted requirements. The most common reason for using this type of prototyping is that it can be executed quickly. If users can receive prompt feedback on their needs, they can be able to refine them in the early stages of software development (SDLC). Making alterations early in the SDLC is very cost-effective because there is nothing to redo at that point. If a project is altered after much work has been done then small alterations may require significant efforts to implement since software systems come with numerous dependencies. Speed is important in implementing throwaway prototypes, since with a small budget of money and time little can be spent on a prototype that will be abandoned (Source 3). Another positive of rapid prototyping is its ability to build interfaces that users are able to test. User interfaces are often seen by users as the system, and because they see it in front of them, it is much easier to understand how the system will function. It is asserted that revolutionary throwaway prototyping is a more effective way in which to manage user requirements-related issues, and hence a greater improvement to software productivity in general. Requirements can be identified, piloted, and tested far much faster and cheaply when issues concerning software structure, maintainability, and evolvability are overlooked (Source 1). This, in turn, aids in the accurate identification of requirements, and the subsequent development of a valid and functional system from the perspective of the user via normal software development models. Prototypes can be categorized based on the fidelity with which they echo the actual product with regards to timing, interaction, and appearance. One method of developing a low fidelity rapid prototype is paper prototyping. The prototype is executed using paper and pencil, and therefore resembles the function of the final product, but does not look like it completely (Source 2). Another way of easily building high fidelity rapid prototypes is to use employ a GUI Builder and develop a click dummy, a prototype that resembles the intended system, but lacks any functionality. Not exactly similar to rapid prototyping, but obviously in the same class, is the application of storyboards, drawings or animatics. These implementations are non-functional but demonstrate how the system will look. In this type of prototyping the prototype is built with the notion that it will be abandoned and the eventual system will be built from scratch (Source 3). The steps in this type of prototyping are: i) Write initial requirements ii) Design the prototype iii) Users use/experience the prototype and specify any new requirements iv) Repeat if needed v) Write the eventual requirements vi) Create the real products b) Evolutionary Prototyping Also called breadboard prototyping. It is quite dissimilar to throwaway prototyping and the primary goal when using it is to construct a very robust and dynamic prototype in a structured way and constantly enhance it. The logic behind this is that this type of prototyping, when constructed, forms the core of the new system, and the refinements and further needs will be built. When building a system using evolutionary prototyping, the system is constantly enhanced and rebuilt (Source 2). Evolutionary prototyping accepts that we do not comprehend all the requirements and constructs only those that are well comprehended. This method allows the development team to insert new features, or make alterations that could not be fathomed in the requirements and design stage. Evolutionary have an edge over rapid prototypes because they are functional systems. In spite of the fact that they may not possess all the attributes the users have planned, they may be used on a temporary basis until the final product is delivered. It is not uncommon within a prototyping setting for users to use an initial prototype while waiting for a more enhanced version. Users may decide that a trial system is better than no system. In evolutionary prototyping, developers can dedicate themselves to developing components of the system that they understand rather than focusing on developing an entire system (Source 4). In order to reduce risk, developers do not implement features that they do not understand properly. The partial system is availed to customer sites. As users engage with the system, they identify opportunities for new features and submit requests for such features to developers (Source 1). Developers then consider these enhancement requests together with their own and employ sound configuration-management techniques to modify the software requirements specification, update the model, recode and retest. c) Incremental Prototyping The final system is constructed as separate prototypes. At the end the different prototypes are merged in a complete design. d) Extreme Prototyping This is used particularly for developing web applications. It basically divides web development into 3 phases, with each one founded on the preceding one. The first stage is a static prototype that is primarily composed of HTML pages. In the second stage, the screens are programmed and wholly functional using a layer of simulated services. In third stage the services are executed (Source 4). The entire process is called extreme prototyping so as to draw attention to the 2nd stage of the process, in which a completely functional UI is created with little concern for the services except their contract. D. Discuss types specifically used in HCI for usability tests Rapid prototyping (discussed above) is the predominant type of prototyping that used in HCI for usability tests (Source 2). The reason for this is that it allows users enough time to use, gauge, and request changes as compared to other types of prototyping. III. Discussion A. Present the case for software prototyping In all instances of software prototyping, the objective is always to provide a prompt ability to notice something about the attribute of the final product, weighing options and evaluating ideas before settling on a particular one. On a different note, conventional approaches to creation of huge interactive software systems – an extremely complex process that needs large amounts of money, time, and personnel – tend to compel a commitment to enormous quantities of design detail without a way to visualize the outcome until it is too late to make major alterations (Source 3). It is therefore little wonder that there is too much dissatisfaction with a majority of the products developed. Prototyping is therefore a very vital process that if ignored can have critical consequences on the success of a software system. An opaque approach to software design, development, and implementation can deceive an organization into thinking that it has crossed all the Ts and dotted all the Is, a common mistake that is the primary cause of the failure of most software development projects (Source 4). B. Discuss the connection between software prototyping and human centered design Software prototyping greatly supports human centered design. When you create software prototypes, you give users the opportunity to compare their needs vis-a-vis the developed system. Consequently, developers can go back to the drawing board and come up with systems that satisfy users’ needs and requirements (Source 1). This creates a cycle in which software developers are compelled to modify and refine their software systems until they are fully satisfy customers’ requirements; this is what supports human centered design. Since it has become a common theme, developers are aware from the very start that their systems must meet user standards, and this has cemented the idea that all software systems should be built around users (Source 4). This explains how software prototyping encourages and supports human centered design. C. Discuss the advantages and disadvantages of software prototyping i) Advantages Misunderstandings between users and software developers can be pinpointed as the system functions are revealed. Also, absent user services can be detected. With software prototyping, complicated or confusing user services can be identified and enhanced. Software development staff can find incomplete/inconsistent needs as the prototype is constructed, and a working although limited system is readily available to show the workability and usefulness of the application to users (Source 2). Software prototypes serve as a foundation for writing specifications for a production quality mechanism. Finally, software prototyping can also be employed in user training and system ii) Disadvantages Insufficient analysis is a common drawback in software prototyping. Developers can focus too much on prototypes and be distracted from the proper development of the actual project. In addition to this, there is a high likelihood of users confusing prototypes and final systems, thinking that the prototype is just as good as or even better than the eventual system. Software prototyping is also a very costly and time-consuming task that cannot be easily undertaken by small or medium-sized organizations (Source 3). Finally, developers are very prone to misunderstanding user objectives and developing an attachment to the prototype so much so that they have a problem creating the actual system. IV. Conclusion. Software prototyping is a vital aspect of software and software systems development. It plays a crucial role in the construction of software systems that are built around users, thereby enabling and enhancing user satisfaction, usability, and human centered design. Currently, software prototyping is not only recommended but also required in most organizations (Source 1). The logic is that it is better to take time to build a good software system than to hurry and come up with something that will cost more time and money because it will keep getting modified due to unsatisfactory features and performance. A. Revisit the aims and objectives I am convinced that the aims and objectives that were stated at the beginning of this paper have been met. The logic behind creating software prototypes from a usability point of view and how they support human centered design has been explained (Source 4). B. Reaffirm the logic behind creating software prototypes The logic is to develop software systems that are able to satisfy user requirements, and this can only be aided by constructing prototypes that ensure that near-perfect systems are delivered as the final products (Source 2). C. Conclude and summarize the findings Software prototyping is an important cog in the wheel of software systems development. There are 4 types of software prototyping, but only 2 are commonly used (Source 4). In conclusion, there is a greater need to emphasize software prototyping so as to save organizations time and money, and satisfy users. Works Cited Source 1 Arnowitz, Jonathan, Michael Arent, and Nevin Berger. Effective prototyping for software makers. Amsterdam: Elsevier, 2007. Print. Source 2 Hanau, Patrick, & Lenorovitz, Dennis. Prototyping and Simulation tools for User/Computer Dialogue Design. SIGGRAPH Proceedings, Seattle, Wash.: ACM SIGGRAPH, 271-278. Source 3 Hartson, H. Rex, & Smith, C. Eric. Rapid Prototyping in Human Computer Interface Development. ACM Computer Surveys, 21, 1 (March), 1-65. Source 4 Hekmatpour, Sharam, & Ince, Derrick. Software prototyping, formal methods, and VDM. Wokingham, Eng.: Addison-Wesley, 2008. Print. Read More