PROJECT PROPOSAL

Student Attendance Management System (SAMS)

Course: System Analysis and Design

Project Category: Web-Based Information System

Project Mode: Individual Project

Proposed Technologies: JSP, Java, JDBC, and Oracle Database

Prepared By: [Student Name]

Student ID: [Student ID]

Department: Computer Science and Engineering

Institution: [University Name]

Submitted To: [Course Teacher's Name]

Submission Date: [Date]

1. Executive Summary

The Student Attendance Management System (SAMS) is a proposed web-based information system designed to simplify and improve the process of recording, maintaining, calculating, and reporting student attendance in an educational institution.

In many educational environments, attendance is recorded using paper registers, spreadsheets, or a combination of manual and digital procedures. These methods can require repeated data entry, manual calculations, and time-consuming report preparation. They may also create difficulties in maintaining consistent records, identifying students with low attendance, and tracking attendance corrections.

The proposed system will provide a centralized platform through which authorized teachers can record attendance for their assigned courses and class sessions. The system will maintain student, course, section, teacher, and attendance information in a relational database. It will calculate attendance percentages and generate student-wise, course-wise, and section-wise reports.

The system is proposed to be developed using JavaServer Pages (JSP), Java, JDBC, and Oracle Database. The project will follow a structured System Analysis and Design process, beginning with problem identification and existing system analysis, followed by requirements analysis, system modeling, database design, implementation, and testing.

The expected outcome is a practical and maintainable attendance management application that reduces repetitive administrative work, improves access to attendance information, and supports more consistent attendance reporting.

2. Introduction and Background

Student attendance is an important part of academic administration. Educational institutions use attendance records to monitor student participation, identify attendance-related concerns, and support academic decisions in accordance with institutional policies.

An attendance process usually involves maintaining student lists, recording attendance during class sessions, updating records, calculating attendance percentages, and preparing reports for teachers or administrators.

When these activities are handled through separate registers or spreadsheets, the process can become difficult to manage as the number of students, courses, sections, and class sessions increases. Different files may use inconsistent formats, and information may need to be copied from one location to another.

A computerized attendance management system can help organize these activities within a consistent information-processing environment. The proposed Student Attendance Management System will focus on the essential functions required to manage attendance records and produce useful reports.

The project is intended as an individual academic software development project that demonstrates the practical application of System Analysis and Design concepts.

3. Problem Statement

The current attendance-recording process in an educational institution may depend on paper-based registers, spreadsheets, or separate digital records maintained by individual teachers. Although these methods can support basic attendance recording, they may become inefficient when attendance information must be consolidated across multiple courses and sections.

Manual data entry and calculation can increase the possibility of recording errors. Preparing consolidated reports may require additional administrative effort, while retrieving historical attendance information can become time-consuming. If records are maintained separately, it may also be difficult to establish a consistent view of attendance across different class sessions.

Furthermore, without a clearly defined correction process, changes to attendance records may not be documented consistently. Teachers and authorized administrators may therefore need a more structured way to record, review, and retrieve attendance information.

The central problem addressed by this project is the lack of a unified and efficient process for maintaining and reporting student attendance information. The proposed system will investigate and address this problem by providing centralized data storage, controlled attendance entry, automatic attendance calculations, and report-generation facilities.

Validation note: The exact extent of these problems will be validated through preliminary investigation, including interviews, observation, and review of relevant attendance records or procedures.

4. Project Aim

The main aim of this project is to analyze, design, and develop a web-based Student Attendance Management System that supports accurate attendance recording, centralized record management, automatic attendance calculation, and efficient reporting.

5. Project Objectives

5.1 General Objective

To develop a web-based system that improves the management and reporting of student attendance information.

5.2 Specific Objectives

To maintain student, teacher, course, section, and course-offering information.
To provide authenticated access for authorized system users.
To allow teachers to record attendance for their assigned courses and class sessions.
To store attendance records in a centralized relational database.
To calculate attendance totals and percentages automatically.
To generate student-wise, course-wise, section-wise, and date-wise attendance reports.
To provide a controlled process for correcting attendance records.
To reduce duplicate data entry and repetitive manual calculations.
To apply database constraints and validation rules to improve data consistency.
To test the system for functional correctness, usability, access control, and data integrity.

6. Existing System Analysis

6.1 Description of the Existing System

For the purpose of this proposal, the existing system is assumed to use paper registers, spreadsheets, or a combination of manual and digital methods. The actual procedures will be confirmed during the investigation stage.

The typical process consists of the following activities:

A teacher obtains or prepares the student list for a class.
Attendance is recorded in a paper register or spreadsheet.
Attendance information is updated or transferred to a digital file when required.
Attendance data from different classes or teachers is collected.
Totals and percentages are calculated.
Attendance reports are prepared and shared with authorized personnel.

6.2 Limitations of the Existing Process

The following are potential limitations that will be investigated:

Repeated entry of attendance information into different records.
Time-consuming calculation of attendance totals and percentages.
Difficulty retrieving historical attendance records quickly.
Inconsistent data formats across courses or sections.
Possibility of duplicate, incomplete, or incorrect entries.
Additional effort required to prepare consolidated reports.
Limited traceability of attendance corrections.
Dependence on individual files or staff members to retrieve information.

6.3 Existing System Workflow

Student List
     |
     v
Manual Attendance Recording
     |
     v
Register or Spreadsheet Update
     |
     v
Data Consolidation
     |
     v
Percentage Calculation
     |
     v
Report Preparation

The workflow demonstrates that attendance information may pass through several manual steps before a final report becomes available.

7. Proposed System

The proposed Student Attendance Management System will be a web-based application accessible through a browser. It will use a centralized Oracle Database to store student information, course offerings, class sessions, and attendance records.

Authorized users will log in according to their assigned roles. Teachers will be able to view their assigned courses and record attendance for the relevant class sessions. The system will validate entries and store the information in the database.

Attendance totals and percentages will be calculated using defined rules. Authorized users will be able to generate reports based on students, courses, sections, and date ranges. Attendance corrections will be restricted to authorized users and should be recorded in an audit history.

7.1 Main Features

1. User Authentication and Access Control

Secure login and logout.
Role-based access for administrators and teachers.
Restriction of functions according to user permissions.

2. Student Management

Add and update student information.
Assign students to appropriate sections.
Search and view student records.

3. Teacher Management

Maintain teacher information.
Associate teachers with course offerings.
Restrict attendance entry to authorized course assignments.

4. Course and Section Management

Maintain course and section records.
Associate courses with sections and academic terms.
Define which teacher is responsible for each course offering.

5. Class Session Management

Create class-session records for scheduled classes.
Associate each session with a course offering and date.
Prevent duplicate session records where required.

6. Attendance Recording

Display the relevant student list for a class session.
Record attendance status for each student.
Validate attendance entries before saving.
Prevent duplicate attendance entries for the same student and session.

7. Attendance Calculation

Calculate attended sessions and total eligible sessions.
Calculate attendance percentages.
Apply approved institutional rules for cancelled classes, excused absences, and other exceptions.

8. Attendance Reporting

Student-wise attendance reports.
Course-wise attendance reports.
Section-wise attendance summaries.
Date-wise attendance records.
Identification of students below a configured attendance threshold.

9. Attendance Correction and Audit

Permit corrections only to authorized users.
Record the user, date, and reason for a correction.
Maintain an audit history of changes.

10. Backup and Data Protection

Use appropriate database access controls.
Apply input validation and secure session handling.
Establish database backup and recovery procedures.

8. Project Scope

8.1 In-Scope Features

User authentication and role management.
Student and teacher records.
Course, section, and course-offering management.
Class-session management.
Attendance recording and correction.
Attendance percentage calculation.
Basic attendance reports.
Validation and database integrity rules.
Testing and technical documentation.

8.2 Out-of-Scope Features

Biometric attendance devices.
Facial recognition.
GPS-based attendance.
Student admission management.
Tuition fee management.
Examination and result processing.
Full learning management system functionality.
Integration with external university ERP systems.
Native Android or iOS applications.

These features may be considered in future versions if the project requirements and available resources justify their inclusion.

9. Stakeholder Analysis

Stakeholder	Role and Interest
Administrator	Maintains authorized system records and manages access permissions.
Teacher	Records attendance and views reports for assigned courses.
Student	May view personal attendance summaries if student access is included in the approved requirements.
Department Administration	Reviews course-wise and section-wise attendance reports.
Project Developer	Analyzes requirements, designs, implements, tests, and documents the application.
Course Teacher or Project Supervisor	Reviews project progress and provides academic guidance.

Student access is a proposed feature that can be included if time permits and the requirements are approved.

10. Functional Requirements

Requirement ID	Functional Requirement
FR-01	The system shall authenticate users before allowing access to protected functions.
FR-02	The system shall allow authorized administrators to create and update student records.
FR-03	The system shall maintain course, section, teacher, and course-offering information.
FR-04	The system shall allow authorized teachers to view their assigned course offerings.
FR-05	The system shall allow an authorized teacher to create or select a class session and record attendance.
FR-06	The system shall validate attendance entries before saving them.
FR-07	The system shall prevent duplicate attendance records for the same student and class session.
FR-08	The system shall calculate attendance totals and percentages according to defined rules.
FR-09	The system shall generate attendance reports using selected filters.
FR-10	The system shall allow authorized users to correct attendance records through a controlled process.
FR-11	The system shall maintain an audit trail for attendance corrections.
FR-12	The system shall restrict users from accessing functions or records beyond their assigned permissions.
FR-13	The system shall provide a method for authorized administrators to maintain database backups and support recovery procedures.

11. Non-Functional Requirements

11.1 Usability

The interface should be understandable to users with basic computer skills. Attendance entry should require a clear and manageable sequence of actions.

11.2 Performance

Common operations, such as loading a class list or generating a report, should complete within an acceptable time under the expected academic workload. Specific response-time targets will be established during requirements analysis and testing.

11.3 Security

Passwords must not be stored as plain text. The system should use secure password-hashing practices, role-based access control, server-side validation, and protected database credentials.

11.4 Reliability

The application should validate data and use database transactions where appropriate to avoid incomplete or inconsistent attendance records.

11.5 Maintainability

The application should separate presentation, application logic, and database operations so that changes can be made without unnecessarily affecting unrelated components.

11.6 Data Integrity

Primary keys, foreign keys, appropriate constraints, and validation rules should be used to maintain consistent records.

11.7 Backup and Recovery

A documented backup and recovery approach should be established to reduce the risk of permanent data loss.

12. Proposed Technology Stack

Component	Proposed Technology	Purpose
User Interface	HTML, CSS, JavaScript	Forms, navigation, validation assistance, and page presentation.
Presentation Layer	JSP	Dynamic web pages.
Application Logic	Java	Attendance rules, calculations, validation, and processing.
Database Connectivity	JDBC	Communication between Java application code and Oracle Database.
Database	Oracle Database	Storage and management of application records.
SQL Processing	SQL and PL/SQL	Data queries, constraints, procedures, and database-side operations where appropriate.
Development Environment	Java-compatible IDE and Oracle tools	Coding, database development, and debugging.
Testing	Manual and structured test cases	Verification of system functions and data integrity.

The proposed architecture is intended for an academic project. For a larger production deployment, the architecture, session management, deployment model, and application-layer design should be reviewed against institutional standards.

13. Preliminary Database Design

Entity	Purpose	Example Attributes
STUDENT	Stores student information.	student_id, student_name, section_id
TEACHER	Stores teacher information.	teacher_id, teacher_name, email
COURSE	Stores course details.	course_id, course_title, credit_hours
SECTION	Stores section details.	section_id, section_name, batch
COURSE_OFFERING	Links a course, section, teacher, and academic term.	offering_id, course_id, section_id, teacher_id, term
CLASS_SESSION	Stores individual class-session information.	session_id, offering_id, class_date
ATTENDANCE	Stores student attendance for each session.	attendance_id, session_id, student_id, status
USER_ACCOUNT	Stores authentication and role information.	user_id, username, password_hash, role
ATTENDANCE_AUDIT	Records authorized attendance changes.	audit_id, attendance_id, changed_by, changed_at, reason

Preliminary Data Integrity Rules

Every student must have a unique student identifier.
Every class session must belong to a valid course offering.
Each student should have no more than one attendance record per class session.
Attendance status must use a predefined set of permitted values.
A teacher may record attendance only for authorized course offerings.
Attendance corrections must be restricted to authorized roles.
Corrections should record the user, time, and reason for the change.

The final database schema, including relationships, keys, and constraints, will be prepared during detailed system design.

14. Attendance Percentage Calculation

For the initial version, attendance percentage will be calculated as follows:

Attendance Percentage = (Number of Attended Eligible Sessions / Total Eligible Sessions) × 100

For example, if a student attends 18 out of 24 eligible class sessions:

Attendance Percentage = (18 / 24) × 100 = 75%

The calculation must follow the institution's approved policy. Cancelled classes, excused absences, and other exceptional situations must be handled according to agreed rules rather than assumed automatically.

15. Development Methodology

The project will follow a structured, iterative development approach. The main activities will be:

Phase 1: Preliminary Investigation

Identify the problem and intended users.
Investigate the existing attendance process.
Collect initial information through interviews, observation, and document review.
Define preliminary scope and feasibility.

Phase 2: Requirements Analysis

Identify functional and non-functional requirements.
Prepare use-case descriptions.
Document business rules and user permissions.
Validate requirements against stakeholder needs.

Phase 3: System Design

Prepare use-case diagrams.
Develop data-flow or activity diagrams where appropriate.
Design the database schema and entity-relationship diagram.
Prepare interface layouts and navigation structure.
Define validation and security rules.

Phase 4: Implementation

Develop login and access-control functions.
Implement student, teacher, course, and section management.
Develop class-session and attendance modules.
Implement attendance calculations and reports.
Add correction controls and audit history.

Phase 5: Testing

Conduct unit testing for individual functions.
Conduct integration testing for database and application operations.
Test authentication and role-based permissions.
Test attendance calculations and duplicate-entry prevention.
Test invalid inputs and correction procedures.

Phase 6: Documentation and Demonstration

Prepare the user guide.
Document the database and application structure.
Prepare test results.
Demonstrate the completed application and its main workflows.

16. Preliminary Project Timeline

The following schedule is an initial estimate for a 12-week individual academic project.

Week	Activities	Expected Deliverable
1	Problem identification and project proposal	Approved project proposal
2	Existing system investigation	AS-IS analysis report
3	Requirements gathering and validation	Software requirements specification
4	Use-case and process modeling	Requirements diagrams
5	Database and interface design	ERD, schema draft, interface layouts
6	Authentication and basic administration	Initial application modules
7	Student, teacher, course, and section modules	Management modules
8	Class-session and attendance-entry modules	Attendance recording functions
9	Calculations, reports, and correction controls	Reporting and audit functions
10	Integration and functional testing	Test cases and defect list
11	Corrections, validation, and documentation	Revised application and documentation
12	Final demonstration and submission	Final project package

The schedule may be adjusted according to the semester calendar, project complexity, and supervisor feedback.

17. Feasibility Analysis

17.1 Technical Feasibility

The project is technically feasible for an individual CSE student who has the necessary foundational knowledge of Java, JSP, JDBC, SQL, and Oracle Database. A suitable development environment and database access will be required.

The project will use commonly available web-development and database technologies. Technical risks include configuration problems, database connectivity issues, and security implementation errors.

17.2 Economic Feasibility

The project can be developed using available academic facilities and development tools. Actual expenses may include hosting, hardware, internet access, or database deployment, depending on the environment.

Potential benefits include reduced repetitive data entry, faster reporting, and better organization of attendance information. These benefits should be evaluated against actual development and maintenance costs before the system is adopted institution-wide.

17.3 Operational Feasibility

The proposed system is intended to support existing attendance-related responsibilities rather than replace academic policies. Teachers and administrators will need clear instructions and a defined procedure for recording and correcting attendance.

A prototype demonstration and user feedback session can help identify usability problems before final submission.

17.4 Schedule Feasibility

The project is expected to be manageable within a 12-week academic schedule if the initial scope is maintained. Advanced features such as biometric integration and external ERP integration are excluded to reduce schedule risk.

17.5 Legal and Security Considerations

The system will contain student-related information. Access should be limited to authorized users, credentials must be protected, and records should be handled according to applicable institutional policies and relevant data-protection obligations.

18. Risk Analysis

Risk	Potential Impact	Proposed Mitigation
Requirements change during development	Delays and rework	Confirm and document the initial scope.
Limited time for implementation	Incomplete features	Develop core functions before optional features.
Database design errors	Inconsistent records	Review relationships and constraints before implementation.
Unauthorized access	Exposure or modification of records	Apply role-based permissions and server-side authorization.
Incorrect attendance calculations	Unreliable reports	Define calculation rules and test boundary cases.
Data loss	Loss of project records	Maintain backups and test restoration procedures.
Limited user feedback	Usability issues	Obtain feedback from representative users where possible.
Development environment problems	Work interruption	Document configuration and keep versioned source-code backups.

19. Expected Outcomes

At the end of the project, the expected deliverables are:

A documented analysis of the existing attendance process.
A problem statement and validated set of system requirements.
Use-case diagrams and relevant system models.
An entity-relationship diagram and Oracle database schema.
A functional web-based attendance management prototype.
Attendance recording, calculation, and reporting functions.
User authentication and role-based access controls.
A controlled attendance correction mechanism.
Test cases and documented test results.
Technical documentation and a user guide.
A final project demonstration.

The completed prototype is expected to demonstrate how a centralized system can improve attendance record organization and reporting. The actual degree of improvement will depend on testing and evaluation.

20. Evaluation and Success Criteria

The project will be evaluated against the following criteria:

Authorized users can log in and access only permitted functions.
Student, teacher, course, section, and course-offering records can be maintained.
Teachers can record attendance for valid class sessions.
Duplicate attendance records are prevented.
Attendance percentages match independently calculated test results.
Reports display correct information for selected filters.
Unauthorized users cannot modify attendance records.
Attendance corrections are traceable.
Database relationships and constraints preserve data integrity.
The application can be demonstrated using representative test data.

21. Conclusion

The Student Attendance Management System is proposed as a practical solution to the challenges that can arise when attendance information is maintained through separate registers and spreadsheets.

The project will apply the principles of System Analysis and Design to investigate an existing process, identify operational problems, define system requirements, design a relational database, and implement a web-based application using JSP, Java, JDBC, and Oracle Database.

By focusing on attendance recording, calculation, reporting, access control, and correction tracking, the project will demonstrate the development of a focused information system within a manageable academic scope.

The final system will be evaluated through structured testing and demonstration. Any decision to adopt it for actual institutional use would require additional review of operational requirements, security, deployment, backup, maintenance, and stakeholder approval.

22. References

Kendall, K. E., and Kendall, J. E. Systems Analysis and Design. Pearson.
Dennis, A., Wixom, B. H., and Tegarden, D. Systems Analysis and Design: An Object-Oriented Approach with UML. Wiley.
Oracle. Oracle Database Documentation. https://docs.oracle.com/en/database/
Oracle. Java Documentation. https://docs.oracle.com/en/java/
Oracle. JDBC Basics. https://docs.oracle.com/javase/tutorial/jdbc/basics/

Prepared by: [Student Name]