Design Process of Dynamic Attendance System - Thesis Proposal Example

Dynamic Attendance System for s of Local DMV [Pick the Introduction This essay discusses the development of the prototype for a Dynamic Attendance System (DAS) that would aid quick checking in of the customers for a local DMV. Our software company has designed this system with the help of sophisticated software tools for programming and building a user friendly GUI. We have provided two options for attendance system i.e. self checking in by customers during peak hours and receptionist aided attendance system during normal hours. We have built a prototype software model as a first step towards the implementation. We will look at the different stages of implementation of our ideas in this project. This report contains the prototype development in the first part, then the management of the tasks to build on the attendance system, and the last part considers the graphical representation of the ideas to be implemented in our real-time attendance system for local DMV. Prototype of the Attendance System Our prototypes will follow the popularly sued prototypes in the literature (Preece, 2002) (Scharge, 1996) (Walker, 2002).The prototype will reflect our idea of implementation of the project. It will show main parts of the model that is required to implement the two suggested parts of the attendance system, self-checking in and receptionist aided checking in. We have developed the prototype in the form of user interface that will provide two options for checking in for customers. When the busy hours are going on, the customers will use their thumb impressions to quickly sign in after assigning a unique personal identification number to each customer. The customers will not have to enter various fields like names, purpose of coming etc when the busy hours are going on. The procedure for checking in is simple and robust during busy hours. We have an arrangement that captures the image of each customer through the camera located just above the entrance as soon as self-checking is initiated. The automated system will allow the customer to check in with his unique PIN if it is already in the database, or generates a new one if he has come for the first time. During normal hours, our model will allow the receptionist to enter some fields that will provide detailed information about the customer. The receptionist will be expert in understanding our software system. The software system will quickly enter the names, purpose of coming, contact numbers, and addresses of the customers for future reference. The entries made by the receptionist will also be automatic in a sense that receptionist will dictate the software to write the information as he speaks it using voice recognition technique. This method will be quite robust and quick as compared to manual entry system. Management Plan The management plan of developing DAS will throw some light on the stages required to accomplish our goals and objectives. It consists of the following stages described below. Developing Prototype The first step in developing our DAS is making a suitable prototype. The description and requirements of the prototype that will serve our requirements is already presented in the previous section. Analyze the Equipment Required The next step is analysis of the equipment required for implementation our proposed system. It will contain the servers for keeping the record, the central computer for processing the records, the computer for displaying user interface on the customer checking in counter. The equipment should be purchased after checking the requirements of the processing, memory and other relevant things to optimize the cost. Buy Necessary Hardware for Implementation of Project The management will decide the cost for purchasing the equipment after optimizing the necessary requirements in terms of design and implementation. Designing Algorithm The expert software team in our company will design the algorithm for implementation of the attendance system at the local DMV. The algorithm will contain the pseudo code for the programmers to build on. Programming The expert panel of programmers will write the code for execution of the desired attendance system. It will consist of various modules required to be integrated after making them independently. These modules will have codes written in background by programmers. Integrate the Modules with Software The next step is integration of the modules with the software. The modules have their own software and hardware part. When they are integrated, our final system will be ready for execution and processing of checking in of the customers. The integration process must take into consideration various limitations of equipment and design. Building User Interface The last step in our building DAS is making a user friendly interface at the entrance or reception of the company. This interface will guide the receptionist during normal hours while it will guide the customers during busy hours. The software is intelligent enough to minimize the time for checking in quickly during peak hours by simply capturing the image of the customer and assigning the PIN. Testing After completion of the DAS, it will be tested on some dummy clients before presenting it for final implementation. Time Required for Each Phase The time requirement for each phase is mentioned below. Phase 1: 1 week Phase 2: 2 weeks Phase 3: 2 weeks Phase 4: 3 weeks Phase 5: 3 weeks Phase 6: 3 weeks Phase 7: 1 month Phase 8: 3 days The time distribution of the project is quite efficient given the deadline we have. We have to finish the project in 5 months which is very much probable with our time management. Comparison of Self-Checking in and Receptionist Aided Checking in The comparison of checking in mechanism is based on the time consumption of each to expedite the process of attendance. In the case of Self-Checking in, the user’s involvement is not much. He will have to accept the welcome call by the user interface that will open the camera for capturing his image. The camera will recognize the presence of the customer in the vicinity while focusing on his face. As the image is captures, it is transferred to the database for comparison with the history of the customer. The software assigns the unique PIN to the customer after retrieving from database, or generating a new one for first time registration. Then the software asks the user to confirm his entry and the interface goes back to the starting point. The whole process of attendance only takes 2 to 3 minutes per customer. In case of receptionist aided checking in, we have some time as there is no rush of customers. We have designed the algorithm for 3 to 4 minutes of processing of each customer. The receptionist will enter the code for logging into the module for voice recognition. The software will listen to the words of the customer directly. The voice will be dictated to the form-filling to enter his record in terms of name, address and purpose of visiting. The form-filling fields will be verified by the receptionist for corrections, if required. This mode is not applicable for self-checking in since it will create problems in dictating the software for exact punctuation of words. If the customers feel difficulty in handling the voice recognition module then they will get stuck at the entrance. Hence it was thought to use the voice commands with the aid of receptionist only. Representation of Interfaces Main User Interface Reception-Aided Checking in Window 1: Window 2: Window 3: Self-Checking In Conclusion Our software module checks in the customers very quickly with robust settings for rush hours as well as normal hours. The involvement of the users is minimized to the maximum extent to reduce the time for checking in. The users will not be stuck while self-checking in since the software will be guiding them all the way through. Also for aid of receptions, the recognition of voice is enabled to quickly filling out the forms. References Preece, J., Rogers, Y., and Sharp, H. 2002. Interaction Design: Beyond Human-Computer Interaction. John Wiley, New York. Schrage, M. 1996. Cultures of prototyping. In T. Winograd (ed.), Bringing design to software. ACM Press, New York, NY. Walker, M., Takayama, L., and Landay, J. A. 2002. High-fidelity or low-fidelity, paper or computer? Choosing attributes when testing web prototypes. In Proceedings of the Human factors and ergonomics society 46th annual meeting (HFES 2002). Human Factors and Ergonomics Society, Santa Monica, CA, 661-665. Read More