Abstract

Successful Colleges begin by make sure their students come to school regularly.
The consequences of low attendance are serious and not just affect the students
who miss school but also affect the community. The attendance rate tells us the
average percentage of students attending school in each day in the given year, as
reported by the state Department of Education. Sometimes students and parents
might question why school attendance is so important. Going to school regularly
is important to the student future. After Covid-19 the World is in complete lock
down that leads teachers to take class from home, because of taking class from
and students attending from home the marking of attendance may not be easy to
maintain and submit, sometimes the student might of come and leave the class
but the tutor may not see him in attendee list that might lead to a absent of a
student. In our application we will generate the attendance report automatically
by connecting to google meet

CHAPTER 1

INTRODUCTION

1.1 OVERVIEW OF PROJECT

Google meet attendance management system is software developed for daily

attendance of students. previously, the college relied heavily on paper records.
this paper focuses on preventing information in an easy way and intelligible
manner
which reduces paper and time. the project makes use of database in order to keep
a record of attendance and is used while generating a report for individual student.
the attendence will auto save in the google drive, we can retieve it whenever we
want.

1.2 About the Project

The main objectives of our work are:

• Data of student has been computerized without using any manual effort.

• Attendance will be marked upon the signin

• Easy to generate the report.

• Rapid access to any information regarding the students’ attendance.

 CHAPTER 2

SYSTEM ANALYSIS

2. ANALYSIS OVERVIEW

System analysis is used in every field where something is developed. It is a

process of identifying our project goals and purposes and to create the
systems and procedures that will achieve them in an efficient way.

The system analysis and designing are two main process before
developing the project because if these two step go wrong then the entire
project may go wrong because wrong design leads us to the wrong product
or system development.

2.1 EXISTING 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 semester the reports are generated and it
takes more time in calculation. By the way we are not interested in generating
report in the end of the semester but during the semester for the student to take
note of his situation, and the department to know what action to take on students
with poor attendance even before Exam. So, we are not able to get student
regularity report and take necessary action on students whenever we want because
of having very time-consuming process.

Disadvantages

1. Not User Friendly:

The existing system is not user friendly because the retrieval of data
is very slow and data is not maintained efficiently.

2. Difficulty in report generating:

We require more calculations to generate the report so it is

generated at the end of the semester. And the student doesn’t get a

single chance to improve their Attendance.

3. Manual control:
All calculations to generate report are done manually so there is greater
chance of errors.
4. 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.
5. Time consuming:
Every work is done manually so we cannot generate report in the end
of the semester or as per the requirement because it is very time consuming.

2.2 Proposed System

Our Proposed system is a JavaScript based application which will run as a chrome
extension, while opening the Google Meet the application will automatically
connect itself where the teacher can create as many classes as they can and add
the students in that class once student start attending classes the attendance will
automatically marked with the time logs, those who attended are put present and
not attended are put absent.
In the era of COVID-19, virtual classes have become the norm. For teachers,
however, taking attendance in these virtual classes is often a pain. They must keep
track of when students join and leave among side conversations and distracting
visuals

Our Google Chrome extension, Attendance for Google Meet, streamlines the
entire process of taking attendance in a Google Meet™. All teachers have to do
is enter the name of the class and a list of their students. At any time, teachers
may click on the attendance button to view each student's status (present, absent,
previously present, or not on list), and export the data to a beautifully formatted
Google Spreadsheet in their own Google Drive.

Advantages:-

The new system has been designed as per the user requirements so as to fulfill
almost all them.

1. User Friendly: -

The proposed system is user friendly because the retrieval and storing of data is
fast and data is maintained efficiently. Moreover the interface provided in the
proposed system, provides user to deal with the system very easily.

2. Reports are easily generated:-

Reports can be easily generated in the proposed system so user can generate the
report as per the requirement (weekly, monthly) or in the middle of the semester.
User can give the notice to the employees to be regular.

3. 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.
2.3 FEASIBILITY STUDY

Preliminary investigation examine project feasibility, the likelihood the

system will be useful to the organization. The main objective of the feasibility
study is to test the Technical, Operational and Economical feasibility for adding
new modules and debugging old running system. All system is feasible if they are
unlimited resources and infinite time. There are aspects in the feasibility study
portion of the preliminary investigation:

 Technical Feasibility

 Operation Feasibility

 Economical Feasibility

TECHNICAL FEASIBILITY

The technical issue usually raised during the feasibility stage of the
investigation includes the following:

 Does the necessary technology exist to do what is suggested?

 Do the proposed equipment's have the technical capacity to hold the data
required to use the new system?

 Will the proposed system provide adequate response to inquiries,

regardless of the number or location of users?

 Can the system be upgraded if developed?

 Are there technical guarantees of accuracy, reliability, ease of access and

data security?
 Earlier no system existed to cater to the needs of ‘Secure Infrastructure
Implementation System’. The current system developed is technically feasible. It
is a browser based user interface for audit workflow. Thus it provides an easy
access to the users. The database’s purpose is to create, establish and maintain a
workflow among various entities in order to facilitate all concerned users in their
various capacities or roles. Permission to the users would be granted based on the
roles specified. Therefore, it provides the technical guarantee of accuracy,
reliability and security. The software and hard requirements for the development
of this project are not many and are already available or are available as free as
open source. The work for the project is done with the current equipment and
existing software technology. Necessary bandwidth exists for providing a fast
feedback to the users irrespective of the number of users using the system.

OPERATIONAL FEASIBILITY

The analyst considers the extent the proposed system will fulfill his
departments. That is whether the proposed system covers all aspects of the
working system and whether it has considerable improvements. We have found
that the proposed “Secure file transaction” will certainly have considerable
improvements over the existing system.

ECONOMIC FEASIBILITY

The proposed system is economically feasible because the cost involved in

purchasing the hardware and the software are within approachable. Working in
this system need not required a highly qualified professional. The operating-
environment costs are marginal. The less time involved also helped in its
economical feasibility.
 CHAPTER 3

SYSTEM REQUIREMENT

3. REQUIREMENT

System requirement explains or describes the requirement of developing

the projects. The requirement is divides into two categories, first is hardware
requirements and configuration and second software requirements and
configuration. This is a pre-development process which is needed to be verified
before staring the project because if they doesn’t match then the project outcomes
may have issues or the development process may be delay and interpreted in
between.

3.1 HARDWARE REQUIREMENT

 Processor : i3 or Above

 Mother Board : Intel Family Motherboard

 RAM : 8 GB and Above

 Hard Disk : 300GB GB or Above

 Ethernet Card : 1Mbps Ethernet Card

 Other Accessories : Keyboard & Optical Mouse

3.2 SOFTWARE REQUIREMENT

• Operating System : Windows 8

• Front End :Html, Css, javascript,React

• Back End : Javascript, Json, Babel, Google API

 CHAPTER 4

SOFTWARE SPECIFICATION

React (also known as React.js or ReactJS) is an open-source, front end, JavaScript

library for building user interfaces or UI components. It is maintained by
Facebook and a community of individual developers and companies. React can
be used as a base in the development of single-page or mobile applications.
However, React is only concerned with state management and rendering that state
to the DOM, so creating React applications usually requires the use of additional
libraries for routing, as well as certain client-side functionality.

Components
React code is made of entities called components. Components can be rendered
to a particular element in the DOM using the React DOM library. When rendering
a component, one can pass in values that are known as "props":

ReactDOM.render(<Greeter greeting="Hello World!" />,

document.getElementById('myReactApp'));

The two primary ways of declaring components in React is via functional

components and class-based components.

Functional components

Functional components are declared with a function that then returns some JSX.

const Greeting = (props) => <div>Hello, {props.name}!</div>;

Virtual DOM

Another notable feature is the use of a virtual Document Object Model, or virtual
DOM. React creates an in-memory data-structure cache, computes the resulting
differences, and then updates the browser's displayed DOM efficiently.[9] This
process is called reconciliation. This allows the programmer to write code as if
the entire page is rendered on each change, while the React libraries only render
subcomponents that actually change. This selective rendering provides a major
performance boost.[citation needed] It saves the effort of recalculating the CSS
style, layout for the page and rendering for the entire page

JSX

JSX, or JavaScript XML, is an extension to the JavaScript language syntax.[10]

Similar in appearance to HTML, JSX provides a way to structure component
rendering using syntax familiar to many developers. React components are
typically written using JSX, although they do not have to be (components may
also be written in pure JavaScript). JSX is similar to another extension syntax
created by Facebook for PHP called XHP.
Nested elements

Multiple elements on the same level need to be wrapped in a single React element
such as the <div> element shown above, a fragment delineated by <Fragment>
or in its shorthand form <>, or returned as an array.

Attributes

JSX provides a range of element attributes designed to mirror those provided by

HTML. Custom attributes can also be passed to the component.[13] All attributes
will be received by the component as props.

JavaScript expressions

JavaScript expressions (but not statements) can be used inside JSX with curly
brackets {}

Architecture beyond HTML

The basic architecture of React applies beyond rendering HTML in the browser.
For example, Facebook has dynamic charts that render to <canvas> tags,[15] and
Netflix and PayPal use universal loading to render identical HTML on both the
server and client.[16][17]

React hooks

Hooks are functions that let developers "hook into" React state and lifecycle
features from function components.[18] Hooks don’t work inside classes — they
let you use React without classes.[19]
React provides a few built-in hooks like useState,[20] useContext, useReducer
and useEffect.[21] Others are documented in the Hooks API Reference.[22]
useState , useReducer and useEffect, which are the most used, are for controlling
state and side effects respectively.

Rules of hooks

There are rules of hooks[23] which describe the characteristic code pattern that
hooks rely on. It is the modern way to handle state with React.

Hooks should only be called at the top level (not inside loops or if statements).

Hooks should only be called from React function components, not normal
functions or class components

Although these rules can't be enforced at runtime, code analysis tools such as
linters can be configured to detect many mistakes during development. The rules
apply to both usage of hooks and the implementation of custom hooks,[24] which
may call other hooks.

Common idioms

React does not attempt to provide a complete "application library". It is designed

specifically for building user interfaces[3] and therefore does not include many
of the tools some developers might consider necessary to build an application.
This allows the choice of whichever libraries the developer prefers to accomplish
tasks such as performing network access or local data storage. Common patterns
of usage have emerged as the library matures.
Unidirectional data flow

To support React's concept of unidirectional data flow (which might be contrasted

with AngularJS's bidirectional flow), the Flux architecture was developed as an
alternative to the popular model-view-controller architecture. Flux features
actions which are sent through a central dispatcher to a store, and changes to the
store are propagated back to the view.[25] When used with React, this
propagation is accomplished through component properties. Since its conception,
Flux has been superseded by libraries such as Redux and MobX.[26]

Flux can be considered a variant of the observer pattern.[27]

A React component under the Flux architecture should not directly modify any
props passed to it, but should be passed callback functions that create actions
which are sent by the dispatcher to modify the store. The action is an object whose
responsibility is to describe what has taken place: for example, an action
describing one user "following" another might contain a user id, a target user id,
and the type USER_FOLLOWED_ANOTHER_USER.[28] The stores, which
can be thought of as models, can alter themselves in response to actions received
from the dispatcher.

This pattern is sometimes expressed as "properties flow down, actions flow up".
Many implementations of Flux have been created since its inception, perhaps the
most well-known being Redux, which features a single store, often called a single
source of truth

React Native is an open-source mobile application framework created by

Facebook, Inc.[3] It is used to develop applications for Android,[4] Android
TV,[5] iOS, macOS,[6] tvOS,[7] Web,[8] Windows[6] and UWP[9] by enabling
developers to use React's framework along with native platform capabilities.[10]

History

In 2012 Mark Zuckerberg commented, "The biggest mistake we made as a

company was betting too much on HTML as opposed to native".Using HTML5
for Facebook's mobile version resulted in an unstable application that retrieved
data slowly.He promised Facebook would soon deliver a better mobile
experience.

Inside Facebook, Jordan Walke found a way to generate UI elements for iOS from
a background JavaScript thread, which became the basis for the React web
framework. They decided to organize an internal Hackathon to perfect this
prototype in order to be able to build native apps with this technology.

After months of development, Facebook released the first version for the React
JavaScript Configuration in 2015. During a technical talk, Christopher Chedeau
explained that Facebook was already using React Native in production for their
Group App and their Ads Manager App.

Implementation

The working principles of React Native are virtually identical to React except that
React Native does not manipulate the DOM via the Virtual DOM. It runs in a
background process (which interprets the JavaScript written by the developers)
directly on the end-device and communicates with the native platform via
serialized data over an asynchronous and batched bridge.

React components wrap existing native code and interact with native APIs via
React’s declarative UI paradigm and JavaScript. This enables native app
development for whole new teams of developers, and can let existing native teams
work much faster.

While React Native styling has a similar syntax to CSS, it does not use HTML or
CSS.Instead, messages from the JavaScript thread are used to manipulate native
views. React Native also allows developers to write native code in languages such
as Java or Kotlin for Android and Objective-C or Swift for iOS, which makes it
even more flexible.

Babel

Babel is a free and open-source JavaScript transcompiler that is mainly used to

convert ECMAScript 2015+ (ES6+) code into a backwards compatible version of
JavaScript that can be run by older JavaScript engines. Babel is a popular tool for
using the newest features of the JavaScript programming language.

Developers can use new JavaScript language features by using Babel to convert
their source code into versions of JavaScript that evolving browsers are able to
process.[5] The core version of Babel was downloaded 5 million times a month
as of 2016, increasing to 16 million times per week as of 2019.[6][7]

Babel plugins are used to transform syntax that is not widely supported into a
backwards-compatible version. For example, arrow functions, which are
specified in ES6, are converted into regular function declarations.[8] Non-
standard JavaScript syntax such as JSX can also be transformed.[9][10]

Babel provides polyfills to provide support for features that are missing entirely
from JavaScript environments. For example, static methods like Array.from and
built-ins like Promise are only available in ES6+, but they can be used in older
environments if a Babel polyfill is used.

The fact that React Native actually renders using its host platform’s standard
rendering APIs enables it to stand out from most existing methods of cross-
platform application development, like Cordova or Ionic. Existing methods of
writing mobile applications using combinations of JavaScript, HTML, and CSS
typically render using webviews. While this approach can work, it also comes
with drawbacks, especially around performance. Additionally, they do not
usually have access to the host platform’s set of native UI elements. When these
frameworks do try to mimic native UI elements, the results usually “feel” just a
little off; reverse-engineering all the fine details of things like animations takes
an enormous amount of effort, and they can quickly become out of date.

In contrast, React Native actually translates your markup to real, native UI

elements, leveraging existing means of rendering views on whatever platform you
are working with. Additionally, React works separately from the main UI thread,
so your application can maintain high performance without sacrificing capability.
The update cycle in React Native is the same as in React: when props or state
change, React Native re-renders the views. The major difference between React
Native and React in the browser is that React Native does this by leveraging the
UI libraries of its host platform, rather than using HTML and CSS markup.

For developers accustomed to working on the Web with React, this means you
can write mobile apps with the performance and look and feel of a native
application, while using familiar tools. React Native also represents an
improvement over normal mobile development in two other areas: the developer
experience and cross-platform development potential.

Developer Experience
If you’ve ever developed for mobile before, you might be surprised by how easy
React Native is to work with. The React Native team has baked strong developer
tools and meaningful error messages into the framework, so working with robust
tools is a natural part of your development experience.

For instance, because React Native is “just” JavaScript, you don’t need to rebuild
your application in order to see your changes reflected; instead, you can hit
Command+R to refresh your application just as you would any other web page.
All of those minutes spent waiting for your application to build can really add up,
and in contrast React Native’s quick iteration cycle feels like a godsend.

CHAPTER 5

SYSTEM DESIGN
5. SYSTEM DESIGN

System design is process of software development life cycle where the

project is defined in diagrammatic way or picture representation so that the
process and the ideology of the project can be properly understood by the
developer visually.

5.1 ARCHITECTURE DESIGN

The overall system architecture diagram explains the structure of our

complete project in a graphical model in very simple and effective manner. It
almost holds every component or modules of our developing projects and the
workflow of the components and the relative data resources
 Fig:5.1 System Architecture

5.2 USE CASE DIAGRAM

A use case is a set of scenarios that describing an interaction between a user and
a system. A use case diagram displays the relationship among actors and use
cases. The two main components of a use case diagram are use cases and actors.
An actor is represents a user or another system that will interact with the system
modeled. A use case is an external view of the system that represents some action
the user might perform in order to complete a task
 Fig:5.2 System Usecase

USECASE COMPONENTS

Actor and usecase are the main components of the usecase diagram
which are used to explain the access of function for a particular participant in
an application

Fig:5.2.1 Actor Component

 The symbol mentioned in the fig 5.2.1 is used to represent the user of
the functionalities or usecase of the project. It contains a label below which
helps us to identifier the user category.

Fig:5.2.2 Usecase Component

The functionalities of the project are represented using an ellipse with a

label inside them which mentions the name of the functionality. The figure 5.2.2
is a how the usecase will look like.

Fig:5.2.3 Relationship Component

The arrow show in the diagram are used to represent the relationship between
the usecase and the actor. The arrow point toward the usecase from the actor
which means the user have the access to the particular functionalities in the
project. The usecase diagram can contain multiple actor and can have multiple
access to the usecases. Similarly same usecase can be accessed by the multiple
actor/users in the project.
5.3 SEQUENTIAL DIAGRAM

A sequence diagram shows, as parallel vertical lines (“lifelines”), different

processes or objects that live simultaneously, and as the horizontal arrows, the
messages exchanged between them, in the order in which they occur. This allows
the specification of simple runtime scenarios in a graphical manner
 Fig:5.3 Sequence Diagram

SEQUENCE DIAGRAM COMPONENTS

The sequence diagram uses arrows to represent the message flow between
the object inside the project. The sequence of the arrow from top down method
represent the sequence of the message flow

Fig:5.3.1 Object Component

 The rectangular box is used to represent the objects used in the project and
a label given inside the rectangle to identify the object. The messages flow
between the objects for which a straight line is drawn below the rectangle.

Fig:5.3.2 Message Flow Component

An arrow as shown in the figure 5.3.2 will be used to mention the message flow
between the objects the label below the arrow represent the message. The point
of the arrow represent the direction of the message flow and the sequence of the
arrows used in the diagram represent the sequence of the message flow.

CHAPTER 6

IMPLEMENTATION
6. SYSTEM IMPLEMENTATION
In this chapter the main implementation of the projects is explained in
detail part by part in the form of modules. The implementation is based on the
project design as already mentioned in the system design chapter. The developer
always need to compare and verify the system design information for developing
the correct and proper implementation of the project.

Modules:-

Creating a Classes:-

A Teacher can Create a class as they enter into the meet and they can create as
many class they want and they can add the n number of students in the class once
the class is finished the teacher can export the attendance from the application as
a Excel sheet.

Student Login Capturing: -

Once the Student login to the google meet using his google ID, our application
will capture the First name and Last Name of the Student as Check in our Class
list which the Teacher create the class earlier once the name matches the
attendance will be marked as present.

Exporting the Data as SpreadSheet:-

We use Google API Plugin to Extract Data from the Google Meet and Virtualize
it on Excel Spreadsheet the Google Engine will provide the API from Google
Meet where by using the API we fetch and Extract the data and virtualize it on
spreadsheet.

Saving it on Google Drive:

By using Google Api Engine we can save the Spreadsheet on Google drive and
can share the link to school to use this Spreadsheet. We authenticate user and
connect the Drive using OAuth google.
CHAPTER 7

TESTING
7.1 TESTING OBJECTIVE

Software will undergo many changes after it is delivered to the user

Because of many errors, performance enhancements and change to new
environments. System testing is the stage of implementations, which is aimed at
ensuring that the system works accurately and efficiently before live operations
commences. Testing is vital to the success of the system. The candidate system is
subject to a variety of tests. Data prepared for the purpose of testing is called test
data. Testing is the process by which the programmers generate a set of test data,
which gives the maximum probability of finding all types of errors that can occur
in the software and the following steps has been performed.

7.2 TESTING TECHNIQUES

1. Unit Testing
2. System Testing
3. Black-Box Testing
4. White Box Testing
5. Integration Testing
6. Requirement Testing
7. Acceptance Testing

7.2.1 UNIT TESTING

Unit testing is a testing technique using which individual modules are tested
to determine if there are any issues by the developer himself. It is concerned
with functional correctness of the standalone modules. The main aim is to
isolate or separate each unit or module of the system to identify, analyze and
fix the defects. The following are the advantages of the testing.
  Reduces Defects in the newly developed features or reduces bugs when
changing the existing functionality.
 It reduces Cost of Testing as defects are captured in very early phase.
 Improves design and allows better refactoring of code.
 Unit Tests, when integrated with build gives the quality of the build as
well.

7.2.2 SYSTEM TESTING

System Testing (ST) is a black box testing technique performed to
evaluate the complete system the system's compliance against specified
requirements. In System testing, the functionalities of the system are tested
from an end-to-end perspective.
 System Testing is usually carried out by a team that is independent of
the development team in order to measure the quality of the system unbiased.
It includes both functional and Non-Functional testing.

The above diagram explains the different types of testing process carried
out during the system testing process. For a project to success the system
testing it has to pass all the above testing process

7.2.3 BLACK BOX TESTING

Black-box testing is a method of software testing that examines the
functionality of an application based on the specifications. It is also known as
Specifications based testing. Independent Testing Team usually performs this
type of testing during the software testing life cycle.
This method of test can be applied to each and every level of software testing
such as unit, integration, system and acceptance testing.
There are different techniques involved in Black Box testing process

 Equivalence Class
 Boundary Value Analysis
 Domain Tests
 Orthogonal Arrays
 Decision Tables
 State Models
 Exploratory Testing
 All-pairs testing

7.2.4 WHITE BOX TESTING

White box testing is a testing technique that examines the program
structure and derives test data from the program logic/code. The other names
of glass box testing are clear box testing, open box testing, logic driven testing
or path driven testing or structural testing. White Box Testing Techniques
includes

 Statement Coverage-This technique is aimed at exercising all

programming statements with minimal tests.
 Branch Coverage-This technique is running a series of tests to ensure that
all branches are tested at least once.
 Path Coverage-This technique corresponds to testing all possible paths
which means that each statement and branch is covered.

7.2.5 INTEGRATION TESTING

 Upon completion of unit testing, the units or modules are to be
integrated which gives raise to integration testing. The purpose of integration
testing is to verify the functional, performance, and reliability between the
modules that are integrated. Integration strategies include

1. Big-Bang Integration
2. Top Down Integration
3. Bottom Up Integration
4. Hybrid Integration

7.2.6 REQUIREMENT TESTING

Requirements-based testing is a testing approach in which test cases,
conditions and data are derived from requirements. It includes functional tests
and also non-functional attributes such as performance, reliability or usability.
Stages in Requirements based Testing:

 Defining Test Completion Criteria-Testing is completed only when all

the functional and non-functional testing is complete.
 Design Test Cases-A Test case has five parameters namely the initial
state or precondition, data setup, the inputs, expected outcomes and actual
outcomes.
 Execute Tests-Execute the test cases against the system under test and
document the results.
 Verify Test Results-Verify if the expected and actual results match each
other.
 Verify Test Coverage-Verify if the tests cover both functional and non-
functional aspects of the requirement.
 Track and Manage Defects-Any defects detected during the testing
process goes through the defect life cycle and are tracked to resolution.
 Defect Statistics are maintained which will give us the overall status of
the project.

7.2.7 ACCEPTANCE TESTING

User acceptance testing is a testing methodology where the clients/end
users involved in testing the product to validate the product against their
requirements. It is performed at client location at developer's site.For industry
such as medicine or aviation industry, contract and regulatory compliance
testing and operational acceptance testing is also carried out as part of user
acceptance testing. UAT is context dependent and the UAT plans are prepared
based on the requirements and NOT mandatory to execute all kinds of user
acceptance tests and even coordinated and contributed by testing team.
The following diagram explains the fitment of user acceptance testing in
the software development life cycle:
 The acceptance test cases are executed against the test data or using an
acceptance test script and then the results are compared with the expected
ones. Acceptance criteria are defined on the basis of the following attributes

 Functional Correctness and Completeness

 Data Integrity
 Data Conversion
 Usability
 Performance
 Timeliness
 Confidentiality and Availability
 Install ability and Upgradability
 Scalability
 Documentation

7.3 Test Cases

A test case, in software engineering, is a set of conditions under which a

tester will determine whether an application, software system or one of its
features is working as it was originally established for it to do.

Login Form: Test Case

Expected
Controls Cases Value Outcome
Result
CHAPTER 8

APPENDICE

8.1 SCREENSHOT
8.2 SOURCE CODING
CHAPTER 10

Conclusion

In this paper we have proposed an attendance management system where

attendance has been taken in the digitalized way. By using the proposed system
we are overcoming the problems of the manual entry. Here we are implementing
a system where the attendance is taken and it automatically updates the
attendance.

Future Enhancement

In future we will also record the exact sign in and sign out of a particular student
and we are also designing a system where in the attendance details and the marks
details have been sent to their respective parents/guardians through broadcasting
of SMS. In future work, we can implement the attendance management system
using RFID technology

REFERENCES