Attendance Manager Android Application Project | Android Project

Attendance Manager Android Application Project | Android Project

1. SYNOPSIS 

Attendance Manager is an application developed for taking student attendance in colleges and institutes. It facilitates to access the attendance information of a particular student in a particular class. The information is sorted by the administrator, which will be provided by the teacher for a particular class. The teachers are provided with a separate username and password to take the student’s attendance.

This system will also help in evaluating the attendance eligibility criteria of a student. The purpose of developing an attendance manager is to automate the traditional way of taking attendance. Another purpose for developing this application is to generate the report automatically at the end of the session or in the between of the session.

2.QUESTIONNAIRE 

   

      1. Email address

      2. What is the name of the respondent?

   

      3. What is the respondent’s gender?

           (a)  Male

           (b)  Female

          (c)Others 

     4. What is your profession? 

        (a)Student

         (b)  Faculty

    5. What is your branch (if student)?

       (a)Computer Science 

       (b)Electrical

        (c)  Mechanical 

       (d)Civil

   6. What is the minimum percentage of attendance required per semester?

      (a)   Greater than or equal to 75

      (b)   Greater than or equal to 60

      (c)   Greater than or equal to 40

  7. Would you like this app to report the miscalculation of your attendance to the concerned authority?

     (a)   Yes

     (b)   No

  8. Do you want to enable bio-metric authentication for this app? 

    (a)Yes

    (b)No

  9. Do you want this app to generate a weekly report of your attendance?

    (a)   Yes

    (b)   No

  10.  Would you like this app to provide a customized theme as per your choice?

    (a)   Yes

    (b)   No

 11.  Do you want this app to be platform-independent (make it available for multiple OS)?

    (a)   Yes

    (b)   No

 12.  Would you like this app to be monetized? 

    (a)Yes

    (b)No 

    (c)Maybe

13.  Do you want to give any suggestions or comments?

3. ANALYSIS OF THE SURVEY

We conducted a survey for our application “Attendance Manager” and we have prepared a survey questionnaire to collect the user requirement that satisfies the functional requirement of the app. The respondent of this survey belongs to a different group of people as per their gender and profession. According to their response, we have generated the following result.

From the above survey, we can conclude that-

·        The stakeholders want the app to generate a debar list at the end of each semester.

·        The stakeholders want the app to report the miscalculation of the attendance to the concerned authority.

·        The stakeholders suggest that enabling biometric authentication for this app will make it more secure.

     ·        The stakeholders want the app to generate a weekly report of their attendance.

     ·     The stakeholders also want a customized theme for the app as per their choice.

·        The stakeholders want the app to be platform-independent (make it available for multiple OS).

·        The stakeholders think this app will be helpful and will be able to full fill the purpose for which it has been built and also suggest to build a web portal for the app.

4.SRS DOCUMENT

4.1 Introduction

Attendance Manager is an application developed for daily student attendance in colleges. 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 faculty for a particular class. This system will also help in evaluating the attendance eligibility criteria of a student.

4.1.1 Purpose

The purpose of developing an attendance management system is to computerize the traditional way of taking attendance. Another purpose for developing this software is to generate the attendance report automatically at the end of the session or in the between of the session.

4.1.2 Scope

This project has much scope both in present as well as future. The scope of this project is the mobile phone on which the software is installed, i.e. the project is developed as a mobile application, and it will work for a particular institute. But later on, the project can be modified to operate for many institutes. In the future, the application can be automated using the student's fingerprint.

4.1.3 Definition, Acronyms, and Abbreviations 

The Attendance Manager has to handle records for many numbers of students and maintenance was difficult. Though it has used an information system, it was totally manual. Hence there is a need to upgrade the system with a computer-based information system.

This document uses the following abbreviations-

 AM- Attendance Manager

 SQL- Structured Query Language

 LAN- Local Area Network

 WAN- Wide Area Network

 Admin- Administrator

4.2 The Overall Description

4.2.1 Product Perspective

The product Attendance Manager is an independent product and does not depend on any other product or system. The product will automate various tasks associated with handling student attendance and better organize the stored information and provide optimum performance, thus helping the colleges to ensure smooth working of these processes.

4.2.2 Hardware Interfaces

 Processor: Intel Core i5 6th gen or above

 System configuration: RAM-4gb or more

 Drive Space: 80gb or more

 Operating System: Windows 10

 LAN or WAN Network

4.2.3 Software Interfaces

 Front end: Java

 Back end: SQL

 Front Design: Visual Studio 2010

 IDE: Android Studio 3.4

 Minimum API Level: API 15: Android 4.0.3(Ice-cream Sandwich)

4.2.4 Product Functions

Our system has two types of accessing modes-

1. Administrator

2. User

2.1 Faculty

2.2 Student

1) Administrator

The administrator has to update and monitor the registered student details, add a new student, add faculty, add time table, add a branch, add class & section, view student, view faculty and view student attendance. The administrator can update his profile and also can give help to the faculty and students.

2) User:

There are two users:

a. Student:

Users can only view their personal details, course assigned and attendance.

b. Faculty:

Users can add students, marks attendance of the students also can view the student details and time table.

4.2.5 User Characteristics

This software gives access to two kinds of users.

1. Administrator: The administrator will have access to add, delete and modify information stored in the database.

2. Authorized User: Teaching staff will have access to only view the data stored in the database and can update the student’s attendance.

So the user classes can be categorized as-

1. Admin

2. Faculty

3. Student

4.3 Requirements

4.3.1 User Interfaces

 GUI along with meaningful Frames and buttons

 Reports are generated as per the requirement

4.3.2 Software Interfaces

 Front end: Java

 Back end: SQL

 Front Design: Visual Studio 2010

 IDE: Android Studio 3.4

 Minimum API Level: API 15: Android 4.0.3(Ice-cream Sandwich)

4.3.3 Hardware Interfaces

 Processor: Intel Core i5 6th gen or above

 System configuration: RAM-4gb or more

 Drive Space: 80gb or more

 Operating System: Windows 10

 LAN or WAN Network

4.3.4 Functional Requirements

The functional requirement part of the application discusses the functional behavior that should be possessed by the application. Each requirement maps to a high-level function that transforms the given set of input data into output data.

They are-

REQ-1: AM provides a student registration facility.

REQ-2: It provides facilities to add students to their respective courses which they want to study.

REQ-3: It provides facility to track the percentage of the students attending the classes.

REQ-4: It produces single or multiple attendance reports.

REQ-5: It helps to debar the students from examination having less attendance than the required attendance.

4.3.5 Nonfunctional Requirements

4.3.5.1 Availability 

The software will be available only to authorized users of the colleges like teachers to mark the student’s attendance, student to view their enrolled course, admin, to add an update student’s records.

4.3.5.2 Reliability 

The application will not be able to function properly if the local database crashes due to some reason or if there is any software or hardware failure.

4.3.6 Performance Requirements

Easy tracking of records and updating can be done. All the requirements relating to the performance characteristics of the system are specified in the section below. There are two types of requirements-

4.3.6.1 Static Requirements

These requirements do not impose any constraints on the execution characteristics of the system. They are:

4.3.6.2 Number of Terminals

The software makes use of an underlying database that will reside at the server, while the front end will be available online to the administrative and departmental computers as well as students and teachers.

4.3.6.3 Number of Users

The number of users may vary, as this software finds applications in almost all department of the organization.

4.3.6.4 Dynamic Requirements

These specify constraints on the execution characteristics of the system. They typically include response time and throughout of the system. Since these factors are not applicable to the proposed software, it will suffice if the response tine is high and the transactions are carried out precisely and quickly.

4.3.7 Database Requirements

All the data will be stored in an SQLite database. We can retrieve data from the database using this application.

4.3.8 Design Constraints

Interface is only in English; no other language option is available. User can login with his assigned username and password, no guest facilities is available.

4.3.9 Security

The security requirements deal with the primary security. The software should be handled only by the administrator and authorized users. Only the administrator has the right to assign permission like creating new accounts and generating a password. Only authorized users can access the system with username and password.

4.3.10 Maintainability

The attendance should be correctly inputted against the corresponding student.

4.3.11 Portability

Currently this application works only in android but in the future, it can be modified to work for other operating systems also.

5.UML DIAGRAMS

      5.1 Use Case diagram

   In the above use case diagram there are three actor’s admin, student and        faculty. Student and faculty are the primary actors while admin is the              secondary actor.

   The admin can add new users, delete existing users and modify the                  subjects, time table and course as and when required.

  The faculty(teacher) can mark and modify attendance, generate reports           and receive the complains of the students.

  The students can view their attendance report and can lodge a complaint         if required.

  After performing the required tasks, the user’s logout of the application.

5.2. Class diagram

Following are the components of the class diagram

    Class {name, attribute, method} 

    Objects 

    Interface 

    Relationships {inheritance, association, generalization} 

    Associations {bidirectional, unidirectional}

The above class diagram shows the actions performed by the respective users. These are as follows

  The admin can add new users, delete existing users and modify the                   subjects, time table and course as and when required.

   The faculty(teacher) can mark and modify attendance, generate reports           and receive the complains of the students.

  The students can view their attendance report and can lodge a complaint          if required.

5.3. Sequence diagram

The above sequence diagram works as follows

 (i) Firstly, the application is opened by the user.

 (ii) The user logs into the application using its credentials.

(iii) Depending on the types of user i.e. admin, faculty or student, it performs         the necessary actions.

 (iv) Finally, the user logs out of the application after performing the required actions.

5.4. Activity diagram

                          Components

      Admin Activity Diagram

 The above activity diagram shows the flow of control in the system for the admin.

    Explanation

   (i)  In the initial state the admin logs into the application.

  (ii) Then the flow of control shifts to the types of activities that can be performed by the                    admin.

  (iii) After performing the required activity, the flow of control shifts to the final state and the             admin is logged out of the system.

Faculty Activity Diagram

   The above activity diagram shows the flow of control in the system for the faculty.

  Explanation

         (iv) In the initial state the faculty logs into the application.

         (v) Then the flow of control shifts to the types of activities that can be performed by the                     faculty.

       (vi) After performing the required activity, the flow of control shifts to the final state and                   the faculty is logged out of the system.

 Student Activity Diagram

   The above activity diagram shows the flow of control in the system for the student.

   Explanation

          (vii) In the initial state, the student logs into the application.

          (viii) Then the flow of control shifts to the types of activities that can be performed by the                      admin.

          (ix) After performing the required activity, the flow of control shifts to the final state and                   the student is logged out of the system.

  5.5 State diagram

     The above state diagram represents the conditions of different parts of our application at            finite instances of time.

     Components of the state diagram

             

 The attendance manager works as follows- 

       (i) On the event of the user clicking the welcome button, we transit from our initial state to login             page state. 

      (ii) The user is then authenticated. 

      (iii) If the login credentials are invalid, then the user retries else we proceed to the end state. 

      (iv) If the login credentials are valid, then the user chooses its type and preforms further actions.          (v) After the user has finished the necessary actions, we transit to our final state.

   6. UI (user-interface)

       6.1 Layout designs

             

       7. Database designs

         

     8. Program Code

           Source File Link

     9. Testing

         Introduction

      

Once source code has been generated, software must be tested to uncover (and correct) as many errors as possible before delivery to customer. Our goal is to design a series of test cases that have a high likelihood of finding errors. To uncover the errors software techniques are used. These techniques provide systematic guidance for designing test that exercise the internal logic of software components,

and exercise the input and output domains of the program to uncover errors in program function, behaviour and performance.

Steps:

Software is tested from two different perspectives:

• Internal program logic is exercised using ―White box‖ test case design techniques.

• Software requirements are exercised using ―block box‖ test case

Design techniques. In both cases, the intent is to find the maximum number of errors with the minimum amount of effort and time.

         

Testing Methodologies

A strategy for software testing must accommodate low-level tests that are necessary to verify that a small source code segment has been correctly implemented as well as high-level tests that validate major system functions against user requirements. A strategy must provide guidance for the practitioner and a set of milestones for the manager. Because the steps of the test strategy occur at a time when deadline

pressure begins to rise, progress must be measurable and problems must surface as early as possible. Following testing techniques are well known and the same strategy is adopted during this project testing.

Unit testing

Unit testing focuses verification effort on the smallest unit of software design-the software component or module. The unit test is white-box oriented. The unit testing is implemented in every module of attendance manager by giving correct manual input to the system, the data are stored in database and retrieved. If user wants a required module to access the input or get the output from the end user.

System testing

System testing is actually a series of different tests whose primary purpose is to fully exercise the application. It is to check all modules worked on input basis, if you want change any values or inputs will change all information so specified input is must.

Performance Testing

Performance testing is designed to test the run-time performance of application within the context of an integrated system. Performance testing occurs throughout all steps in the testing process. Even at the unit level, the performance of an individual module may be assessed as white-box tests are conducted. This project reduces attendance table, codes. It will generate report fast having no extra time or waiting of results. Entry of correct data will show results in a few milliseconds. It uses very low memory.

Test cases

Test case is an object for execution for other modules in the architecture does not represent any interaction by itself. A test case is a set of sequential steps to execute a test operating on a set of predefined inputs to produce certain expected outputs. There are two types of test cases: - manual and automated.A manual test case is executed manually while an automated test case is executed using automation. In system testing, test data should cover the possible values of each parameter based on the requirements. Since testing every value is impractical, a few values should be chosen from each equivalence class. An equivalence class is a set of values that should all be treated the same. Ideally, test cases that check error conditions are written separately from the functional test cases and should have steps to verify the error messages and logs. Realistically, if functional test cases are not yet written, it is ok for testers to check for error conditions when performing normal functional test cases. It should be clear which test data, if any is expected to trigger errors.

10. Snapshots

11. Conclusion and Future work

11.1 Conclusion

The Attendance Manager developed using Java fully meets the objectives of the system for which it was developed. The application has reached a steady-state where all bugs have been eliminated. The application is operated at a high level of efficiency and all the teachers and users associated with the system understand its advantage. The system solves the problem it was intended to solve.

11.2 Future Work

The project has a very vast scope in the future. In the future, this project can be implemented in other colleges with extra technologies. The project can be updated in the near future as and when the requirement for the same arises, as it is very flexible in terms of expansion. With the proposed software of database space manager ready and fully functional the client is now able to manage and hence run the entire work in a much better, accurate, and error-free manner.