Prototyping in Information Systems - Essay Example

A Report On Prototype Development & Documentation Submitted by Prototype development & documentation Prototyping in information systems (IS) development has recently shown increased benefits. The prototyping process execution ensures that users have are able to synergise with the design & development team of the project so that the designed system is consistent with those in use in their work. As a result, they should be highly motivated to participate in an IS prototype development process. Prototyping in Information Systems provides a bridge to users with the designers of the project. This helps software development team in understanding and developing the design as per the user need and provides users a sneak preview of the way the software package may shape up. If users have any feedback on the prototype, that can be very well taken care in the final product without much cost added to the product. The objective of this paper is to develop a functional prototype from the requirements, verify how it fares against the prototype principles and finally strength and weakness of the prototyping. 1.0 Existing Account processing at an organisation Account processing system is the heart of financial transactions in any organisation. Diagram 1 A demonstrates the high level flow of existing account processing system at one of the production company. 1.1 How the process works in the existing flow - Purchase department creates the purchase order and sends a copy of it to vendor and account payable department Purchase department confirms schedule of goods to be sent to vendor Vendor sends the goods which are received at the organisation's security where the goods are received along with the invoice The security gate/person receiving the goods stamps the receipt and provides it back to vendor for claiming the payment at account payment department The invoices for a day are bundled together and sent to account payable department for subsequent payments to vendor Vendor submits the received stamped claims to account payable department The account payable department consists of 120 staff, who have the primary responsibility to ensure that the payments are credited on time after they receive the claims from vendors and subsequent matching with the purchase orders are done The whole matching process at account payable department is manual and at times some claims take as long as 20 days to process and the 5% errors in matching process is quite frequent and is considered an acceptable norm The organisation is considering to expand its operations and brainstorming at various levels has suggested that the account payable department is one of the major bottleneck in expanding its operations Diagram 1 A: Traditional Invoiced Account processing system 1.2 Requirements for a new Information system The CIO of the company was asked to develop a new system to make the whole of the vendor claims process efficient. He was provided following business requirements and was asked to get back with the high level flow and design prototype to the prospective users. The CIO was asked to work with the system users so that the gaps between the business requirements and Information system develop to cater for those requirements, are minimal. Requirement 1: The matching process between purchase order, invoice and goods receipt has to be automated so that the minimum time without any error. This requirement was accorded high priority. Requirement 2: The purchase department should not be able to order more goods than which were originally allocated in Purchase order. This in turn ensures the cumulative quantity of goods received does not exceed the purchase order quantity. Requirement 3: Quantity of goods ordered should be available to Goods receipt department (Usually, Security gate), so that they do not accept quantity which is larger than the one originally ordered by Purchase department. Requirement 4: As the organisation was expecting to scale up operation in other area it was looking for additional staff as well which it expected could come from the Account processing department after implementation of new Information system. Hence one of the requirements was to automate as many non-monetary operations possible. 1.3 High level design of the new Information system Diagram 1B shows the high level design submitted to the Programme Manager. The features of the design take care of all the business requirements of the projects. The requirements as against the features of the Information System to be developed are tabulated in the table 1. Diagram 1 B: High level design of the Invoice-less Account processing system Requirement # Detail Implemented feature 1 Automate the matching of PO, Invoice, quantity of goods received A system developed to do the matching process in the background and identify the outliers 2 Goods received must not be more that PO quantity A system check is performed at purchase department and the goods receipt counter. The purchase person is not allowed to order more than the PO quantity except in exceptional circumstances where the approval would be required. At the receipt counter, the goods are not allowed inside if the order quantity exceeds the PO quantity. Again, the same exception handling is allowed here. 3 Goods received and order quantity are same At the receipt counter, the goods are not allowed inside if the order quantity exceeds the PO quantity. Again, the same exception handling as in above feature is allowed here. 4 Automation of most of the account processing system so that staff can be reduced there for subsequent re-deployment The new account processing system added features which were automating most of the non-monetary functions while staff intervention was still sought in monetary functions, over-rides etc. Table 1: Requirements vis--vis features of Invoice-less Account processing system 1.4 Prototyping of the System to implement above high level design Diagram 2 shows the prototype developed to give users a view to the screen of the actual software. As can be seen from the diagram, all the expected features to take care of the implementation of requirements are visually available in the prototype. Essentially, the prototype shows - Version of the prototype in the header of the screen Scanner to scan any existing PO so that the system can work in parallel for some time with the existing system as well Data entry box which can be used to enter details of the purchase order, quantity, order of delivery (if any) Payment box to transfer money to vendor's account or else print the checks The tool also has a trailing message box which will confirm to user if his actions were correct and accepted by system by turning the footer colour green. The footer colour will change to red in case system does not want user to proceed unless there is exceptional approval. Diagram 2: Prototype of the interface for Invoice-less Account processing system The system has feature of Fax to transmit PO to those vendors who do not have the facility to receive soft copy of the document The printer box can be used for directing any output to a printer The payment flow is used for the normal processing while exception flow is used for the situations where the system designed processing is not desired. For instance, there is an urgent material requirement at production shop cascading an immediate request for arranging material by purchase department from the vendor for which the PO has reached its quantity threshold The operator has an option of reviewing the details entered and then submitting it, if found satisfactory Finally last but not the least, the system keeps the audit trail of all the transactions and anyone designated to review the details entered earlier can uses the audit box 2.0 Testing the prototype The prototype is tested as per the test plan below table 2 and the findings are recorded in as indicated in the template. Test Objective Finding To test the various existing functionalities to ensure that the results are same as before. For instance, a test PO is created and the details are checked to ensure that they are same as before. The functionalities are producing the same results as before. The process flow is verified to be having the checks and balance in place. For instance the quantity of goods which can be received is not more than the PO quantity All the checks and balances are found to be in place and as per the business requirements To test the cycle time taken from goods receipt to releasing the vendor payment. The cycle time for this functionality of prototype is found to be 60% less than what it was taking in existing system. To seek user's feedback whether the system is taking care of all their needs from the interface perspective and whether they have comments on the visual appeal of the prototype User's feedback had been generally good and satisfactory with few constructive feedbacks on colour scheme. These comments would be evaluated with the CIO and hence may/may not be incorporated in the real system. 3.0 Strength and weakness of Prototyping as a design methodology Following two sections highlight the strength and weaknesses of prototyping as a design methodology in Information Systems development. 3.1 Strength of prototyping as a design methodology: Development time & cost is reduced considerably User participation reduces the gaps between understanding and implementation Quantifiable user feedback is received with less subjectivity Facilitates system implementation since users know what to expect and hence users are expected to be delighted with the final outcome. Exposes developers to potential future system enhancements 3.2 Weakness of prototyping as a design methodology: Can lead to insufficient analysis. Users feel that the ultimate system would also be same as the prototype which is really, not the case. Developers can become too attached to their prototypes Can cause systems to be left unfinished and/or implemented before they are ready. Sophisticated development process on 4 GL languages or case tools would offset the time saving benefit of prototyping. 4.0 Critical evaluation of the developed prototype against the prototyping principles Table 3 below evaluates the Account processing invoice-less prototype against the prototyping principles. The evaluation is done on a three point scale which is defined as: Good - If prototype matches and exceeds the prototyping principle Satisfactory - If prototype just reaches to the level of expected prototype principle Poor - If prototype does not achieve the particular prototyping principle Prototyping principle Evaluation of the prototype (Good/Satisfactory/Poor) Product should be approachable for the novice or less experienced computer user Satisfactory Sequence of keystrokes are obvious & intuitive to the users Satisfactory User learning curve and mental load requirements are not much Good User finds prototype and hence image of product easy to use and hence makes full use of all the relevant functions Satisfactory Keep it simple (Follow simple Design Principles like colour, typography, layout) Good Coherent logic which makes the USER feel that the system is logical Good User's time is not wasted by economical series of keystrokes to achieve an objective Good Be consistent not only within your application, but attempt to use the standard conventions that other applications use. Good If practical, give the users the ability to customize their display elements. Poor Do not rely solely on a mouse for navigation. Users would get stuck if for some reason mouse is not working and users would not be able to switch to the keyboard. Good Bibliography: 1. Akers, Gerri (2006) what is prototyping [Internet], Available from: < http://www.umsl.edu/sauterv/analysis/prototyping/proto.html > [Accessed 22 May 2009]. 2. Langefors, Brje (1973). Theoretical Analysis of Information Systems. Auerbach. ISBN 0-87769-151-7. 3. Laudon, Jane P.& Laudon, Kenneth C. (2007) Essentials of Business Information Systems 7th Edn , Prentice Hall. 4. Rockart et. Al (1996) Eight imperatives for the new IT organization, Sloan Management review. 5. Trcek, D., Trobec, R., Pavesic, N., & Tasic, J.F. (2007). Information systems security and human behavior. Behavior & Information Technology,113-118 6. Turban, Efraim & Leidner, Dorothy & McLean, Ephraim & Wetherbe, James (2008) Information Technology For Management 6th Edn., John Wiley and sons. 7. Prakken, Bart (2000), Information, Organization and Information Systems Design: An Integrated Approach to Information Problems, Springer publication, ISBN 0792377842, 9780792377849 8. Arnowitz, Jonathan, Arent, Michael, and Berger, Nevin (2007) Effective Prototyping for Software Makers, Morgan Kaufmann, ISBN: 9780120885688 9. Hasso Plattner, Christoph Meinel & Ulrich Weinberg (2009). Design Thinking. mi-Wirtschaftsbuch. ISBN-10: 3868800131, ISBN-13: 978-3868800135 10. Ben Shneiderman & Cathrine Plaisant (2004) ,Designing the User Interface (4th Edition) Pearson Addison-Wesley, ISBN: 0321197680 (Hardcover) Read More