A Project Report On Student Attendance Management System Submitted To
RAJIV GANDHI PROUDYOGIKI VISHAVIDYALAYA BHOPAL (M.P.) in partial fulfillment for the award of the degree of BACHELOR OF ENGINEERING IN COMPUTER SCIENCE ENGG. Submitted By: Anuj Gupta 0915CS081010
Kshama Agrawal 0915CS081013
Ajay Kujur 0915CS0810
Under the Guidance of Mr. D. D. Shrivastava CSE Deptt.
Department of Computer Science & Engineering Institute of Information Technology & Management Gwalior (MP)
2010-11
CERTIFICATE OF APPROVAL The foregoing project entitled “Student Attendance Management System” Is here by approved as a certifiable study of engineering subjected carried out and presented in manner satisfactory to warrant it acceptance as a pre-Requisite to the degree for which it is submitted. It is understood by this Approval the undersigned do not necessarily endorse any conclusion of Opinion therein, but approve the project for which it is submitted.
(Internal Examiner)
HOD CSE Institute of Information Technology & Management, Gwalior
(External Examiner)
Principal Institute of Information Technology & Management, Gwalior
CERTIFICATE This is a certify that project entitled “Student Attendance Management System” is record of bona fide done by Anuj Gupta, Kshama Agrawal, Ajay Kujur under my guidance for partial Fulfillment of the requirements for the award of the degree of “Bachelor of Engineering” To the best of my knowledge, this project is original work and has not been submitted before for award of any other degree.
Date: 16/05/2011
Mr. D. D. Shrivastava Institute of Information
Technology & Management, Gwalior
ACKNOWLEGEMENT We are extremely grateful to Mr. D. D. Shrivastava their active & constant encouragement & also for the excellent & faithful discussion that has helped us during the course of the project. It gives us immense pleasure to express our sincere thanks to H.O.D. of CS & IT department for their encouragement to complete this project. We sincerely and heartly thankful to the project in charge Ms. Romina Sharma for her timely advise and kind cooperation of though times without his innovation guidance we would not been able to complete this project. At the outside we would like to express our deep gratitude for project to Dr. B K Singh, Principal of INSTITUTE OF INFORMATION TECHNOLOGY & MANAGEMENT (IITM) for granting permission & providing the necessary facilities for successful completion of this project.
Anuj Gupta Kshama Agrawal Ajay Kujur
1. Introduction Attendance Management System is software developed for daily student attendance in schools, colleges and institutes. It facilitates to access the attendance information of a particular student in a particular class. The information is sorted by the operators, which will be provided by the teacher for a particular class. This system will also help in evaluating attendance eligibility criteria of a student. Since ages, attendance system has remained one of the most important systems for evaluating the working time of students in any college or school. In short, this project is used to mark the number of days present/absent in any academic year of students in a college, school etc.
1.1 Overview:- Attendance Management System basically has two main modules for proper functioning. • First module is admin which has right for creating space for new batch, entry of new faculty, updating any subject if necessary, and sending notice. • Second module is handled by the user which can be a faulty or an operator. User has a right of making daily attendance, generating report. Attendance can be taken in two ways: • On the basis of Subject and month. • On the basis of Class. 1.2 Scope: - The scope of the project is the system on which the software is installed, i.e. the project is developed as a desktop application, and it will work for a particular institute. But later on the project can be modified to operate it online.
1.3 Purpose: - The purpose of developing attendance management system is to computerized the tradition way of taking attendance .It is also used to generate the report automatically at the end of the session or in the between of the session. Also, the purpose of the project is to develop a student attendance system, which has better data security, performance and user interface than the current system. In the current system, the attendance is maintained manually, due to which the people concerned with maintaining the attendance report have to face lot of problems like: problem of data security, not properly storage of data, increases the work load, takes a lots of time etc. It is also a very tedious job and as manipulation of data is very easy it is error prone. So, to solve these problems we computerized the student attendance system.
2. System Requirements
2.1 Software Requirement:1. Language – Java Servlets, HTML, Apache Tomcat etc. 2. Backend - MS-Access, Xara 3. Operating System - Windows-7
2.2 Minimum Hardware Requirement:1.
RAM -256 MB (Preferably 2GB or higher)
2.
Hard Disk -40 GB
3.
Processor -Intel Pentium 4
4.
SVGA Monitor
5.
Keyboard
6.
Two Button Mouse
7.
Operating System -Windows XP Service Pack2
3. Literature Survey & Introduction of Methodology 3.1 Working of Present System: - In the present system all work is done on paper. The whole session attendance is stored in register and at the end of the session the reports are generated. We are not interested in generating report in the middle of the session or as per the requirement because it takes more time in calculation. At the end of session the students who don’t have 75% attendance get a notice.
Disadvantages of present working system:• Not User Friendly: The existing system is not user friendly because the retrieval of data is very slow and data is not maintained efficiently. • Difficulty in report generating: We require more calculations to generate the report so it is generated at the end of the session and the student does not get a single chance to improve their attendance. • Manual control: All calculations to generate report is done manually so there is greater chance of errors. • Lots of paperwork: Existing system requires lot of paper work. Loss of even a single register/record led to difficult situation because all the papers are needed to generate the reports. • Time consuming: Every work is done manually so we cannot generate report in the middle of the session or as per the requirement because it is very time consuming. •Less security: Security of data is less in manual systems. This because majority of the records are stored as statements or in registers. Moreover, these data can be accessed by anyone and even they can modify any important data.
Proposed SystemThis Application is built for automating the processing of attendance. It also enhances the speed of the performing attendance task easily. It also generates periodic reports to keep a check on the students who are regular & who are not. A Faculty has to login to the system & then in the attendance option they have to select appropriate class, semester and subject. So this will display the list of the students who are eligible to appear in this session. So now the faculty has to just select the students name from the manual attendance sheet according to their roll number and then submit the sheet. This will add the selected students as present student in that particular session. This system is very useful to the office staff also because they can generate various types of reports and submit them to respective faculties also or also can be submitted to the College Coordinator. Office staff can also generate black list of students who have attendance less than 50% or80%. So this kind of various reports can be generated
Characteristics of the proposed system• User Friendly:-The proposed system is user friendly because the retrieval and storing of data is fast and data is maintained efficiently. Moreover the graphical user interface is provided in the proposed system, which provides user to deal with the system very easily. • Reports are easily generated:- reports can be easily generated in the proposed system so user can generate the report as per the requirement (monthly) or in the middle of the session. User can give the notice to the students so he/she become regular. • Very less paper work:- The proposed system requires very less paper work. All the data is feted into the computer immediately and
reports can be generated through computers. Moreover work becomes very easy because there is no need to keep data on papers. • Computer operator control:- Computer operator control will be there so no chance of errors. Moreover storing and retrieving of information is easy. So work can be done speedily and in time.
Software Engineering ModelThe model employed to materialize the Student Attendance Management System is the iterative waterfall model. A common mistake is to consider "iterative" and "incremental" as synonyms, which they are not. In software/systems development, however, they typically go hand in hand. The basic idea is to develop a system through repeated cycles (iterative) and in smaller portions at a time (incremental), allowing software developers to take advantage of what was learned during development of earlier parts or versions of the system. Learning comes from both the development and use of the system, where possible key steps in the process start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving versions until the full system is implemented. At each iteration, design modifications are made and new functional capabilities are added. The procedure itself consists of the initialization step, the iteration step, and the Project Control List. The initialization step creates a base version of the system. The goal for this initial implementation is to create a product to which the user can react. It should offer a sampling of the key aspects of the problem and provide a solution that is simple enough to understand and implement easily.
3.2Introduction of Methodology:Student Attendance Management System has been developed in Institute for computerised attendance submission and it’s monitoring by Teachers, Head of Departments, Dean Academic Affairs and Director. Students/Guardians also have access to view their attendance. In this the teachers engaging different classes are required to submit the attendance of the students present in their class regularly. Detailed guidelines for its use are as under. Teachers will submit their attendance through this Student Attendance Management System.
Attendance Management System basically has two main modules for proper functioning • First module is admin which has right for creating space for new batch, any entry of new faculty, updating a subject if necessary, and sending notice. • Second module is handled by the user which can be a faulty or an operator. User has a right of making daily attendance, generating report.
4.
System Requirement Specification (S.R.S.)
4.1 Overview & Summary:Attendance Management System is a software developed for daily student attendance in schools, colleges and institutes. If facilitates to access the attendance information of a particular student in a particular class. This system will also help in evaluating attendance eligibility criteria of a student. The purpose of developing attendance management system is to computerized the tradition way of taking attendance. The scope of the project is the system on which the software is installed, i.e. the project is developed as a desktop application, and it will work for a particular institute. 4.2 Functional Requirements:The functional requirement of the project is defined under three modules. The first module allows the system Administrator(admin) to log into his account and has the privileges to do multiple things some of the include adding a new branch, adding a new subject, adding a new teacher, adding new student, modifying student information, modifying branch information, and modifying student information, also there is a provision to change login password. The second module of the project defines itself in terms of being used by the Teachers; Teachers have to enter their loginid and password in system. After that the id is verified and the records of student of particular semester are displayed on the screen. Teacher now mark the attendance of student who is present in class, teachers can also change their password. The third module of the project allows the students to log into the system and view their current attendance statistics. No other privileges are given to the student.
4.3 Non-Functional Requirements: Hardware requirementsHardware Interface 1: The system should be embedded in the PC/Laptop. Hardware Interface 2: 40 GB hard disk and 256 MB RAM. Software requirementSoftware Interface: Student Attendance management System.
5.
Design and Development
5.1 Design of Project:GUI 1: Main provides the basic navigation access to the user allowing him to choose his login type as Administrator, Faculty or Student. GUI 2: Based on the users’ selection on the first screen he is navigated to the other screen on the basis of selection he/she made. GUI 3: This screen is the users main work area from the navigation menu the user selects for the operation to be performed and is taken to the respective domain of the project. 5.2 Use Case Diagram:A use case diagram in the Unified Modeling Language (UML) is a type of behavioral diagram defined by and created from a Use-case analysis. Its purpose is to present a graphical overview of the functionality provided by a system in terms of actors, their goals (represented as use cases), and any dependencies between those use cases. The main purpose of a use case diagram is to show what system functions are performed for which actor. Roles of the actors in the system can be depicted. Use Case diagrams are formally included in two modeling languages defined by the OMG: the Unified Modeling Language (UML) and the Systems Modeling Language (SysML).
Fig. Showing Use case Diagram
5.3 Data Flow Diagram:A data flow diagram (DFD) is a graphical representation of the "flow" of data through an information system. It differs from the system flowchart as it shows the flow of data through processes instead of hardware. The DFD a way of expressing the system in a graphical format in a modular design was developed by Larry Constrains. This DFD is also known as “Bubble Chart” has the purpose to classify the system requirement and to identify the major information that will be a program in system design. A Data Flow Diagram is logical model of the system and shows the flow of the data and the flow of logic so this all thing describes what takes place in a proposed system, not how the activities are accomplished. We have noted that the DFD describes what the flow is rather then how they are processed, so it means the DFD doesn’t depend on the hardware, software, data structure or file organization. DFD consist of a series of symbols joined together by a line. There may be a single DFD for the entire system or it may be exploded into various levels. 1.
Context Free Diagram
2.
First Level DFD
3.
Second Level DFD
Fig. 1 - Context Free Diagram
Fig. 2 – First Level Diagram 5.5 Entity Relationship Diagram:-
An entity-relationship diagram is a data modeling technique that creates a graphical representation of the entities, and the relationships between entities, within an information system. The three main components of an ERD are: •
The entity is a person, object, place or event for which data is collected. For example, if you consider the information system for a business, entities would include not only customers, but the customer's address, and orders as well. The entity is represented by a rectangle and labeled with a singular noun.
•
The relationship is the interaction between the entities. In the example above, the customer places an order, so the word "places" defines the relationship between that instance of a customer and the order or orders that they place. A relationship may be represented by a diamond shape, or more simply, by the line connecting the entities. In either case, verbs are used to label the relationships.
•
The cardinality defines the relationship between the entities in terms of numbers. An entity may be optional: for example, a sales rep could have no customers or could have one or many customers; or mandatory
The steps involved in creating an ERD are: • • •
Identify the entities. Determine all significant interactions. Analyze the nature of the interactions.
Entity Relationship Diagram Notations
Peter Chen developed ERDs in 1976. Since then Charles Bachman and James Martin have added some slight refinements to the basic ERD principles. Entity An entity is an object or concept about which you want to store information. Weak Entity Attributes are the properties or characteristics of an entity. Key attribute A key attribute is the unique, distinguishing characteristic of the entity. For example, an employee's social security number might be the employee's key attribute. Multivalued attribute A multivalued attribute can have more than one value. For example, an employee entity can have multiple skill values. Relationships Relationships illustrate how two entities share information in the database structure.
Fig. Showing Entity Relationship Diagram
6.
Snapshots of Project
Fig. Showing Basic Navigation Menu
Fig. Showing Administrator Login Screen
Fig. Showing Administrator Home Screen
Fig. Showing A Student Registration Page
Fig. Showing A Faculty Registration Page
Fig. Showing A Branch Registration Page
Fig. Showing A Subject Registration Page
Fig. Screen to Enter Student Attendance
Fig. Showing Screen to Display Attendance
Fig. Showing Faculty Login Screen
Fig. Showing Faculty Home Screen
Fig. Showing Student Login Screen
Fig. Showing Student Home Screen
7.
Maintenance
Software maintenance in software engineering is the modification of a software product after delivery to correct faults, to improve performance or other attributes. A common perception of maintenance is that it is merely fixing bugs. However, studies and surveys over the years have indicated that the majority, over 80%, of the maintenance effort is used for noncorrective actions (Pigosky 1997). This perception is perpetuated by users submitting problem reports that in reality are functionality enhancements to the system. Software maintenance and evolution of systems was first addressed by Meir M. Lehman in 1969. Over a period of twenty years, his research led to the formulation of eight Laws of Evolution (Lehman 1997). Key findings of his research include that maintenance is really evolutionary developments and that maintenance decisions are aided by understanding what happens to systems (and software) over time. Lehman demonstrated that systems continue to evolve over time. As they evolve, they grow more complex unless some action such as code refactoring is taken to reduce the complexity. In the late 1970s, a famous and widely cited survey study by Lientz and Swanson, exposed the very high fraction of life-cycle costs that were being expended on maintenance. They categorized maintenance activities into four classes: Adaptive – dealing with changes and adapting in the software environment Perfective – accommodating with new or changed user requirements which concern functional enhancements to the software Corrective – dealing with errors found and fixing it
Preventive – concerns activities aiming on increasing software maintainability and prevent problems in the future.
The survey showed that around 75% of the maintenance effort was on the first two types, and error correction consumed about 21%. Many subsequent studies suggest a similar magnitude of the problem. Studies show that contribution of end users are crucial during the new requirement data gathering and analysis. And this is the main cause of any problem during software evolution and maintenance. So software maintenance is important because it consumes a large part of the overall lifecycle costs and also the inability to change software quickly and reliably means that business opportunities are lost.
7.1 Software maintenance planning:The integral part of software is the maintenance part which requires accurate maintenance plan to be prepared during software development and should specify how users will request modifications or report problems and the estimation of resources such as cost should be included in the budget and a new decision should address to develop a new system and its quality objectives. The software maintenance which can last for 5–6 years after the development calls for an effective planning which addresses the scope of software maintenance, the tailoring of the post delivery process, the designation of who will provide maintenance, an estimate of the lifecycle costs.
7.2 Software maintenance processes:This section describes the six software maintenance processes as: 1. The implementation processes contains software preparation and transition activities, such as the conception and creation of the
maintenance plan, the preparation for handling problems identified during development, and the follow-up on product configuration management. 2. The problem and modification analysis process, which is executed once the application has become the responsibility of the maintenance group. The maintenance programmer must analyze each request, confirm it (by reproducing the situation) and check its validity, investigate it and propose a solution, document the request and the solution proposal, and, finally, obtain all the required authorizations to apply the modifications. 3. The process considering the implementation of the modification itself. 4. The process acceptance of the modification, by confirming the modified work with the individual who submitted the request in order to make sure the modification provided a solution. 5. The migration process (platform migration, for example) is exceptional, and is not part of daily maintenance tasks. If the software must be ported to another platform without any change in functionality, this process will be used and a maintenance project team is likely to be assigned to this task. 6. Finally, the last maintenance process, also an event which does not occur on a daily basis, is the retirement of a piece of software.
8.
Testing
8.1 System Testing:System testing is a critical aspect of Software Quality Assurance and represents the ultimate review of specification, design and coding. Testing is a process of executing a program with the intent of finding an error. A good test is one that has a probability of finding an as yet undiscovered error. The purpose of testing is to identify and correct bugs in the developed system. Nothing is complete without testing. Testing is the vital to the success of the system. In the code testing the logic of the developed system is tested. For this every module of the program is executed to find an error. To perform specification test, the examination of the specifications stating what the program should do and how it should perform under various conditions. Unit testing focuses first on the modules in the proposed system to locate errors. This enables to detect errors in the coding and logic that are contained within that module alone. Those resulting from the interaction between modules are initially avoided. In unit testing step each module has to be checked separately. System testing does not test the software as a whole, but rather than integration of each module in the system. The primary concern is the compatibility of individual modules. One has to find areas where modules have been designed with different specifications of data lengths, type and data element name. Testing and validation are the most important steps after the implementation of the developed system. The system testing is performed to ensure that there are no errors in the implemented system. The software must be executed several times in order to find out the errors in the different modules of the system.
Validation refers to the process of using the new software for the developed system in a live environment i.e., new software inside the organization, in order to find out the errors. The validation phase reveals the failures and the bugs in the developed system. It will be come to know about the practical difficulties the system faces when operated in the true environment. By testing the code of the implemented software, the logic of the program can be examined. A specification test is conducted to check whether the specifications stating the program are performing under various conditions. Apart from these tests, there are some special tests conducted which are given below: Peak Load Tests: This determines whether the new system will handle the volume of activities when the system is at the peak of its processing demand. The test has revealed that the new software for the agency is capable of handling the demands at the peak time. Storage Testing: This determines the capacity of the new system to store transaction data on a disk or on other files. The proposed software has the required storage space available, because of the use of a number of hard disks. Performance Time Testing: This test determines the length of the time used by the system to process transaction data. In this phase the software developed Testing is exercising the software to uncover errors and ensure the system meets defined requirements. Testing may be done at 4 levels:
Unit Level
Module Level
Integration & System
Regression
8.1.1
Unit Testing:-
A Unit corresponds to a screen /form in the package. Unit testing focuses on verification of the corresponding class or Screen. This testing includes testing of control paths, interfaces, local data structures, logical decisions, boundary conditions, and error handling. Unit testing may use Test Drivers, which are control programs to coordinate test case inputs and outputs, and Test stubs, which replace low-level modules. A stub is a dummy subprogram. 8.1.2
MODULE LEVEL TESTING:-
Module Testing is done using the test cases prepared earlier. Module is defined during the time of design. 8.1.3
INTEGRATION & SYSTEM TESTING:-
Integration testing is used to verify the combining of the software modules. Integration testing addresses the issues associated with the dual problems of verification and program construction. System testing is used to verify, whether the developed system meets the requirements. 8.1.4 REGRESSION TESTING:Each modification in software impacts unmodified areas, which results serious injuries to that software. So the process of re-testing for rectification of errors due to modification is known as regression testing.
9.
Conclusion
The Attendance Management System is developed using Java Servlets and fully meets the objectives of the system which it has been developed. The system has reached a steady state where all bugs have been eliminated. The system is operated at a high level of efficiency and all the teachers and user associated with the system understands its advantage. The system solves the problem. It was intended to solve as requirement specification.
10. Reference Books:1. The complete Reference Java 2. Java servlet programming - Jason Hunter, William Crawford 3. Java servlet programming bible - Suresh Rajagopalan 4. Software Engineering – Roger Pressman Websites:1. Java Servlet Technology - java.sun.com/j2ee/tutorial/1_3fcs/doc/Servlets.html 2. Servlet Essentials - www.novocode.com/doc/servlet-essentials/ 3. Access 2010 - Database Software and Applications - Microsoft Office - office.microsoft.com/en-us/access
