Evaluation of the Existing and Proposed System Using the PIECES Framework - Report Example

? of Institute] of Discipline] ‘Design Principles’ Acknowledgements It is a pleasure for me to acknowledge the contributions of my respected instructor and family members in the formulation and printing of this report. Above their guidance, managerial and conceptual skills I thank them for their encouragement, patience and support. I am privileged to have attended the course of ‘Design Principles’ with Mr. Peter Sun as its instructor who made sure that each of his students got the clear perception and understanding of the concepts and skills of the principle concepts in the course. The establishment of perception of Practical systems was also a task the learning of which was an enormous milestone that we achieved in this course. I thank my instructor and friends for their guidance and for the knowledge that I gained during this course that, of course, immensely assisted me in the formulation of this final report to the project. In the end I also thank the Anglia Ruskin University for providing me with a platform for learning and implementation of the required skills. PROJECT INITIATION DOCUMENTS The purpose of the new system The reasons why the current information system was required to be prepared can be narrated as follows: The problems faced by the management and other personnel at educational institute regarding the institute’s transport facility were numerous. The basic problem lay in the fact that no computerized record of the personnel availing the institute’s transport system existed. Whenever any transport related decision was required to be made at runtime it was solely dependent on human skills. Very few records relating to the passengers were stored in different files. The entire system being manual was very difficult to maintain. Performance wise this system was very poor and would take very long time in providing the results. Anyone who wanted to have information about any transport management related issue would have to go through many files before getting the desired information. Though this system was very cheap economically but the time factor and lack in efficiency was over shadowing its advantages. This situation became the root cause of all the problems eventually resulting in the arousal of a dire need to construct an efficient system that would cater to the vehicle management related issues. This was absolutely necessary as due to the lack of such a proposed system it was absolutely impossible to make complicated management related decisions at runtime especially when new students were enrolled into the institute and each one of them wanted to start availing the transport facility right away. For the proposed vehicle management system to function efficiently it was absolutely necessary to maintain a constantly updated database at its backend that enabled interaction of users with it via a user friendly interface. Objectives of the new system The objectives of the system were thus the making of an information system that would be linked to the student record database. It would separately store the students that would be opting for the vehicle management system that is run under the supervision of the educational institute itself. The objective it would thus achieve would be as follows: The computerized record keeping of all students/ staff availing the transport facility. The allotment of vehicle number to each student with respect to the desired pick up point and drop off point specified by him. The computerized collection of monthly fee. The assigning of specific routes to vehicles. The assigning of specific routes and vehicles to drivers. The registration and record keeping of vehicles running in the system. The record of revenue being used in maintenance of the vehicles and for fuel consumption. Stakeholders The stakeholders of the system include: Students and staff members availing the facility of transport provided by the educational institute. The system handlers. The owners of the institute. The scope of the system The scope of the system involves addressing the issues related to the incorporation of an automated information system that would address the needs of managing the vehicles being run by an institute for transportation purposes. The root cause of the problem was thus addressed first. Fact-finding techniques were applied that resulted in the collection of a manual record of the people availing the transport facility and the management personnel related to it. This collected data was then made automated by storing it in a database powered my MS ACCESS. An element of artificial intelligence was also embedded into the system that enabled the automated selection of a route for a given vehicle comprising of the available checkpoints. The choice of the route’s destination and checkpoints was characterized by the identification of landmarks that lay nearest to the destination of each passenger. In addition to passenger’s personal information the other records maintained would be that of the transport contractor, vehicles in use, drivers, arrival and departure timings, route codes, landmarks all throughout the major areas of the city, and also the fee collection records. Finally the front end for the transport management system was designed so as to receive and satisfy user’s queries via a user friendly interface. The users of the system were also characterized into categories such as the administration, Passengers and the Drivers. Proposed upgrades to the system may be the conversion of the database from MS ACCESS to Oracle as Oracle provides more user connectivity that the former. Benefit analysis The benefit analysis for this project may be done in two manners. These may be tangible or intangible. The intangible benefits are naturally those that the owners and shareholders of the educational institute would themselves reap. The running of the transport system smoothly would encourage newer incoming students and would also build the reputation of the system as a progressive one. The tangible benefits would be the monetary revenue that a smooth running system would bring to the educational institution itself. Feasibility Analysis: Technical, organizational and economic feasibilities Operational/ ORGANIZATIONAL Feasibility Evaluation of the existing and proposed system using the PIECES framework Existing System Performance Does the system provide adequate throughput and response time? 1. Throughput: The current throughput is significantly low due to the fact that the entire system is a manual one with a number of redundant processes. 2. Response Time: The time taken for to start processing a request is high and there is usually a back-log of requests. Information Does the system provide end user and managers with timely, pertinent, accurate, and usefully formatted information? Outputs Being a manual system there are not a lot of useful outputs most of the information is either not relevant or is not in any useful format so that it can be used quickly and easily. Also information that is found to be relevant is not produced in time to be of any productive use. Inputs The data coming into the system is usually not accurately captured and as such contains a variety of errors that could lead to any number of mishaps. The fee voucher generation related data is not kept up to date and is not connected to the fee acceptance system under the aegis of the accounts department. Stored Data The data is either not stored at all or is stored in a manual filing system which is not well organized. It is also not flexible and cannot be analyzed. Some of the stored data is also redundant. Economics Does the system offer adequate service level and capacity to reduce the cost? Costs The cost of the existing system is mainly the misuse of personnel but the monetary costs emerge indirectly as often inaccurate route assignments result in more consumption of the transport related resources such as Fuel and the vehicle’s mileage. The numerous redundant processes at the manual system can be automated. Profits The profits of the existing system can be computerizing it and by improving the number of requests processed within a unit time. Control Does the system offer adequate control to protect against fraud and is it control the security and accuracy of data and information? The input data is not accurately edited and there are a number of processing errors. Also there are a number of inconsistencies in the storage, manipulation of the data and the ongoing processes. Efficiency Does the system make maximum use of available resources including people, time, flow of forms minimum processing delays and the like? A lot of time is wasted because the data is redundantly copied and processed. Also the efforts and materials required for the tasks are unnecessary. Service Does the system provide desirable and reliable service to those who need it? Is the system flexible and expandable? The existing system suffers a number of drawbacks pertaining to the service it provides, these include the foremost fact that being manual it is neither easy to use nor is it flexible to change. Also it is incompatible with any other system and can only be run autonomously. Proposed System Performance Does the system provide adequate throughput and response time? Being an automated system the throughput can be expected to increase and the system will be able to handle an increased amount of orders with a minimum of delays. This may well eliminate the current backlog of orders fairly quickly. Information Does the system provide end user and managers with timely, pertinent, accurate, and usefully formatted information? Outputs There will no longer be any lack of relevant information the data will be processed quickly and be available in a timely fashion. There will also be a minimum of error in the information which will be both necessary and in a useful format. Inputs Data will be captured easily and proficiently. The data that is captured will be complete and without any redundancies. Stored Data The data will be stored in a database and as such will be secure, accurate, well organized, flexible and easily accessible. Economics Does the system offer adequate service level and capacity to reduce the cost? Costs will be easily traceable and low. Profits will be increased due to the increase in the number of throughput. Control Does the system offer adequate control to protect against fraud a and is it control the security and accuracy of data and information? Since the new system will be computerized control and security will not be on issue. The input data will be accurately edited. Processing errors will be minimized and data will be stored consistently. Efficiency Does the system make maximum use of available resources including people, time, flow of forms minimum processing delays and the like? The new system will be more efficient because there will be a lot less wastage of time and materials. Also, the tasks will be easier to perform. Service Does the system provide desirable and reliable service to those who need it? Is the system flexible and expandable? The new system will produce accurate, consistent and reliable results. It will be flexible to changes and will be compatible with other systems. It will be easy to use and learn. Technical Feasibility Characteristics Candidate 1 Candidate 2 Candidate 3 Portion of system computerized Creation of an Request Entry System using Microsoft Access Creating a custom Request entry and Fee Billing system Same as candidate 2 Benefits Can be implemented easily because it is already available in Microsoft Access. Fully supports all the users’ requirement. Is also more efficient and secure. Same as candidate 2 Hardware Requirements Minimum Intel Core i3 CPU @ 1.70 GHz 4 GB RAM Recommended Intel Core i7 CPU @ 2.70 GHz 4 GB RAM Minimum Intel core2 duo CPU @ 1.8 GHz 6 GB RAM Recommended Intel Core i7 CPU @ 2.7.70 GHz 6 GB RAM Same as candidate 2 Software Tools needed Microsoft Access MS Visual Basic and Oracle 11g JAVA and Oracle 11g Application Software Package Software Custom Solution Same as candidate 2 Output Devices Laser Printer VGA compatible Monitors (Both LCD and conventional) with every terminal. Same as candidate 1 Same as candidate 1 Input Devices Keyboard and mouse Same as candidate 1 Same as candidate 1 Storage Devices And Implications. Hard disks (50-60 GB space) Same as candidate 1. Same as candidate 1. Economic Feasibility Personnel PERSONNEL No Person Rates / Hr Total 1. System Analyst / Project Manager $ 20K 2. Programmers and GUI Designers $ 18K 3. Database developers / Telecommunication specialists $ 25K 4. System Librarian $13K SOFTWARE PACKAGES Visual C & ORACLE VB & MS ACCESS VB & Oracle Oracle and C are most secure, effective and strong but expensive package. . This combination works very efficiently in small business application but it somewhat lacks in security if needed. The are absolutely brilliant in the security purposes. $2K $ 1.8K Rs 2.5K Constraints of the project The constraints of the project, as stated earlier were the same that since no computerized record of the people availing the transport facility existed and all the records was on paper work only it took quite a lot of time to create and maintain the database of records. There was a shortage of personnel who would assist in the bringing up if the system and thus personnel needed to be hired who specialized in programming and DBA skills. REQUIREMENT SPECIFICATION DOCUMENT Choice of Requirement Gathering technique and justification The requirement gathering technique used for gathering information for the designing of the implementation of the project was questionnaire. This technique was used owing to the diversified nature of people from whom the input was required to be taken. Conducting the RG exercise The people involved in the conduction of the requirement gathering exercise were the students of the institute, the staff members and the faculty that taught at the educational institute. The owners of the institute were also consulted for their consent. The questions that were used to gather responses are as follows: QUESTIONS FOR THE PASSENGERS (Current and Proposed) 1. Kindly state your name, Student Identity Number, National Identification Number, Contact number and your Full Address. 2. Are you interested in availing a transport facility run by the institute? Yes ______ No_________ 3. Do you currently avail the transport facility run by the Institute? 4. At what time do you want avail the transport facility? Evening __________ Morning _____________ Both ____________ 5. For which area of the city do you want to avail the transport facility? 6. Are you satisfied with the current transport facility provided by the institute? 7. Please state any suggestions that you may with respect to the current transport facility. QUESTIONS FOR THE DRIVERS 1. State the Vehicle Serial Number that you drive. 2. Please state the route at which your vehicle runs. 3. Please state the Full Name, Contact Number, Address, Personal identification number and Employee Code for the institute. 4. Please state the preferable route at which you would want to drive. QUESTIONS FOR THE ADMINISTRATION OF THE INSTITUTE: 1. What is the route upon which most of the vehicles are run? 2. How many drivers has the administration hired? 3. How many vehicles are run by the institute? Analysis of information obtained through RG exercise The analysis of information obtained revealed that there was an immediate need of an automated and computerized system that would intelligently handle not only recoding the data relative to the vehicle management system but would also enable assignment of the vehicles to the passengers and drivers without the need of any human resource getting involved in it. Only by spending comparatively minute amount of revenue in getting the automated system integrated into the institute, the overall revenue generated by its implementation would be manifolds. List of all requirements for the new system The requirements of the new system can eventually be stated as follows: Microsoft Office (Which may later be updated to Oracle 11g.) Microsoft Visual Basic Express. Database Administrators. Programmers. Use case descriptions USE CASE Author: Faisal Dikko. Date: 12th April 2012 USE CASE NAME: New Passenger Subscription ACTOR: Prospective Passenger DESCRIPTION: This use case describes the process of a Prospective passenger submitting request for subscription to the Institute’s transport facility. On completion, the prospective passenger will be sent a notification that the subscription was accepted. NORMAL COURSE: Actor Action System Response Step 1: This use case is initiated when a passenger submits a subscription request to be processed. Step 2: The prospective passenger’s institute ID and personal information such as address and phone number is validated against what is currently on file. Step 3: The landmark Id’s selected by the Passenger that lie near to the destination at which the client needs to be dropped are matched into the route ID’s already present on file. Step 4: Route IDs containing the Landmark IDs as stated by the passenger are highlighted and the vehicles running through them selected. Step 5: Seating capacity in the vehicles selected is checked to find space for the prospective passenger. Step 6: A subscription confirmation notice is generated indicating the status of the subscription. Step 7: This use case concludes when the prospective passenger is assigned the route ID and respectively the Vehicle ID in which he/she will be traveling. ALTERNATE COURSE: Step 4: If no route ID contains the chosen landmarks then either the route ID containing the landmarks nearest to the ones chosen are modified to include the chosen landmark IDs within them.. Step 5: If there is no seating capacity in any of the vehicle Ids chosen then a new Vehicle is assigned and a new route Id made for the new vehicle so as to accommodate the new passenger as well as few old passengers from another vehicle ID PRE-CONDITION: Subscriptions can only be submitted by students/faculty/staff of the institute. i.e. Individuals who possess a institute Id as provided by the institute itself. POST-CONDITION: New passenger’s data is updated into the database and a report is generated for the chosen Vehicle ID’s driver so as to inform him of the new passenger’s addition. USE CASE Author: Faisal Dikko. Date: 12th April 2012 USE CASE NAME: Change of address for existing passenger. ACTOR: Existing Passenger. DESCRIPTION: This use case describes the process of an existing passenger updating the change of his destination address. NORMAL COURSE: Actor Action System Response Step 1: This use case is initiated as soon as the passenger requests the Change of address module of the system. Step 2: The institute ID and the Passenger ID of the existing passenger are verified. Step 3: The current destination address is retrieved from the records and is displayed to the user asking for verification whether it really requires changes or not. Step 4: Changes as entered by the passenger into the existing address are updated into records. Step 5: This use case concludes as soon as the updated address is displayed by the system to the user. ALTERNATE COURSES: Step 3: If the user had entered this module accidentally it verifies the address to be correct and exits from the module. PRE-CONDITION: The update can only be made if and only if it is verified by the passenger. USE CASE Author: Faisal Dikko. Date: 12th April 2012 USE CASE NAME: Existing passengers’ fee balance inquiry. ACTOR: Existing passenger. DESCRIPTION: This use case describes the process of displaying the fee balance of a passenger upon his inquiry. NORMAL COURSE: Actor Action System Response Step 1: This use case is initiated as soon as the passenger is willing to ask for the fee balance currently due from him. Step 2: After verification of the existing passenger’s ID the system looks up fee balance associated with it in its records. Step 3: This use case concludes as soon as the passenger’s requirement is displayed. PRE-CONDITION: This module can only be activated if the actor is an existing passenger. USE CASE Author: Faisal Dikko. Date: 12th April 2012 USE CASE NAME: Subscription of new driver into the transport system. ACTOR: Prospective driver. DESCRIPTION: This use case describes the process of the provision of new drivers’ subscription into the system. NORMAL COURSE: Actor Action System Response Step 1: This use case is initiated as soon as the prospective driver requests for subscription. Step 2: Data entered by the current driver is matched with that sent by the institute’s management as of those drivers that are permitted for employment. Step 3: Upon verification the evaluation department then approves the subscription of the new driver. Step 4: New Driver ID, Existing vehicle ID and route ID are designated for the Prospective driver in the records. Step 5: This use case concludes as soon as the subscription confirmation notice is displayed to the driver. ALTERNATE COURSE: Step 2: If data entered by the Prospective driver does not match that sent by the administration as of those drivers that have been approved for employment then the module ends and display message that data entered is invalid. Step 4: If the driver’s own vehicle is approved to become part of the system then a new vehicle ID is assigned to it. PRE-CONDITION: The prospective driver should already have been evaluated and interviewed by the administration. POST CONDITION: New DRIVER’S data is updated into the database and a report is generated for the administration so as to inform him of the new driver’s addition. USE CASE Author: Faisal Dikko. Date: 12th April 2012 USE CASE NAME: New route ID assignment for existing Driver. ACTOR: Existing Driver. DESCRIPTION: This use case describes the process of the changing of the assigned route ID for an existing Driver. NORMAL COURSE: Actor Action System Response Step 1: This use case is initiated as soon as the driver requests a change of Route ID assigned to it. Step 2: The approval of the change of route ID by the administration is checked into the records. Step 3: The vehicle ID running on the chosen route ID is assigned to the requesting driver. Step 4: This use case concludes as soon as the driver’s requirement is fulfilled. PRE-CONDITION: The evaluation department checks whether the change of route ID has been permitted by the administration or not. PART II: DATA FLOW DIAGRAMS, ENTITY RELATIONSHIP MODEL, DATABASE SCHEMA AND SUGGESTED DBMS FOR THE COMPUTER BASED MORTGAGE APPROVAL AND CREDIT CHECKING SYSTEM Designing system functionalities using Data Flow Diagrams What DFDs are for? Data Flow Diagrams are for modelling a system’s flow of data. It clearly signifies the input of data into the system, shows what processes it goes through to reach the output phase. Context Diagram What does Context Diagram show of the system? A context Diagram centres the concerned system as its centre and shows the interaction of this system with other entities. These interacting entities may be External systems, internal interrupts, systems Users etc. A description of the Context Diagram and any issues that need clarification The Context Diagram for the Vehicle Management System under Consideration shows the system at its centre. The interactions that the centre of the system has are with the following entities: Existing Passengers Accounting Management System Administration Existing Driver Administrative reports New Subscription Requests Past Passengers Potential Passengers The diagrams shows how and for what do these entities interact with the system and what are the responses generated by the system upon interaction with each respective entity. CONTEXT DATA FLOW Diagram FOR VEHICLE MANAGEMENT SYSTEM Figure 1: Context Data Flow Data Flow Diagram Level 1 Diagram The level 1 diagram demonstrated the sub processes of the major processes within the system. Level 2 Diagrams The details of inputs and outputs within the system are narrated by the level 2 diagram which further breaks down the level 1 diagram into simpler sub processes. Figure 2.0: Describes the three interaction entities namely Driver, Manager and Passenger. The Driver and Passenger get registered with the Vehicle Management System. The Manager further manages the whole system with repositories via interacting with the same system. Figure 3.0: Level 1 DFD The registration of Passenger, Driver and Vehicle is done through the same registration process with subsequent tables. Checking the validity of registration is a part of the registration system. This part can also be elaborated at Level 2 DFD. The Transaction Management System allows day to day entries into the respective repository. That repository is further exploited by the Accounts Management System (referred to as Accounting System to generate different reports like fee bills etc. The Level 2 DFD elaborates this section. Figure 4.0: Level 2 DFD Elaborates the report generation under Accounts Management System. Data retrieval from all repositories is necessary in order to generate respective reports. Entity Relationship Diagram The entity relationship diagram is a graphical representation that demonstrates the relationships between the entities within a computing system. The entities within the vehicle management system are demonstrated as follows: Driver Passenger Driver Vehicle Daily Register. Vehicle Management System Entity Relationship Diagram Figure 5: ERD DB Schema for Vehicle Management System Passenger PART III: ARCHITECTURAL DESIGN AND INTERFACE DE User Interfaces: The following interfaces have been constructed for the system prepared above. Figure 6: Title Interface This is the first interface that a user would encounter when the system would initiate. It gives the very basic options of entry into the system or exit from it. Figure 7: Main Menu Interface The second screen that a user would encounter upon entering the system. This screen classifies the users with respect to their current status. Each respective button would open the interface for its respective type of users only. This is in line with the names on the buttons. Figure8: Passenger Sign up Form This screen shown in figure 8 would appear if a new passenger clicks the button of “new passenger signup” from screen shown in figure 7. This form interface enables prospective passengers to enter their data into the system. It gives an option of going back to the main menu in the end. REFERENCES: Dennis, Wixom and Roth. 2006. System Analysis and Design (3rd edition). Wiley. Kendal, K and Kendal, J. 2005. Systems Analysis and Design (6th Edition). Addison Wesley Britton, Carol and Doake, Jill. 2005. Software System Development: A Gentle Introduction (4th edition). McGraw-Hill Higher Education Agarwal, R., De, P., & Sinha, A. P. 1999. Comprehending object and process models: an empirical study. IEEE Transactions on Software Engineering,25(4), 541-556. Institute of Electrical and Electronics Engineers, Inc, 445 Hoes Ln, Piscataway, NJ, 08854-1331, UK,. Retrieved from http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=799953 Dennis, A., & Wixom, B. H. 2000. Systems analysis and design. New York: Wiley Gomaa, H. 2011. Software modeling and design: UML, use cases, patterns, and software architectures. Cambridge: Cambridge University PressBottom of Form Gemino, A., & Parker, D. 2009. Use case diagrams in support of use case modeling: deriving understanding from the picture. Journal of Database Management, 20(1), 1+. Retrieved from http://go.galegroup.com.proxy1.ncu.edu/ps/i.do?id=GALE%7CA193886943&v=2.1&u=pres1571&it=r&p=AONE&sw=w Hoffer, J. A., George, J. F., & Valacich, J. S. 2011.Modern systems analysis and design. Upper Saddle River, N.J: Pearson Prentice Hall. Nunes, D. N. J. 2001. Object Modeling for User-Centered Development and User Interface Design: The Wisdom Approach. Program. Universidade da Madeira. Retrieved from http://xml.coverpages.org/NunoWisdomThesis.pdf UML Document Set June 25, 2001, Retrieved from http://www.omg.org/. Wand, Y., and R. Weber 2002 "Research Commentary: Information Systems and Conceptual Modeling -- A Research Agenda," Information Systems Research (33)4, pp 363-376. Wand, Y. & Weber, R. 2002. Information systems and conceptual modeling: A research agenda. Information Systems Research, 203-223. Whitten, J. L., Bentley, L. D., & Dittman, K. C. 2007.Systems analysis and design methods. Boston, Mass: McGraw-Hill. Read More