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 Kshama Agrawal Ajay Kujur

0915CS081010 0915CS081013 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) (External Examiner)

HOD CSE Principal

Institute of Information Technology Institute of Information Technology
& Management, Gwalior & 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 System-

This 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 Model-

The 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 requirements-
Hardware Interface 1: The system should be embedded in the
PC/Laptop.
Hardware Interface 2: 40 GB hard disk and 256 MB RAM.

 Software requirement-
Software 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 non-
corrective 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 life-
cycle 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 co-
ordinate 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_3-

fcs/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