Microlink Information Technology College Department of Computer Science

MicroLink Information Technology College
Department of Computer Science
<Project Name>For Kelem Amba Primary School
Prepared by:
Solomon Getawa 13,307/19 ED5CS1

Mulugeta Ergette 13,130/19 ED5CS1
Gebre Egziabher Abebe 13,343/19 ED5CS1
Hailemariam Shitaw 14,207/19 ED5CS2
Yididiya Tizazu 14,139/19 ED5CS1
Advisor:
Ephraim Tilahun
29 July 2023
Revision History
Student Attendance Management System
Date Version Description Author
29/July/2023 1.0 Student Attendance Management Solomon, Mulugeta,

System Hailemariam,
Yididiya &
G/Egziabher
Final Project MicroLink IT College, 2023 Page ii

Acknowledgments
We would like to thank a Big Habesha and our advisor Ato Ephraim Tilahun who monitored and
inspected our documents as well as the project coding process. His valuable comments,
suggestions and advises were major outcomes of this project. We would also like to express our
thankful message to all those who helped us to complete this project.
Addis Ababa, July 2023
Final Project MicroLink IT College, 2023 Page iii

Table of Content
ACKNOWLEDGMENTS............................................................................................................iii
TABLE OF CONTENT...............................................................................................................iv
1. INTRODUCTION...................................................................................................................1
1.1 BACKGROUND........................................................................................................................1
1.2 THE EXISTING SYSTEM..........................................................................................................2
1.2.1 Overview of the Existing System....................................................................................3
1.2.2 Problems of the Existing System....................................................................................3
1.3 THE PROPOSED SYSTEM........................................................................................................3
1.3.1 General Objective..........................................................................................................4
1.3.2 Specific Objective..........................................................................................................4
1.3.3 Significance of the Project.............................................................................................4
1.3.4 Scope of the Project.......................................................................................................4
1.4 METHODOLOGIES AND TECHNIQUES.....................................................................................5
1.4.1 Data Collection Methods and Techniques.....................................................................5
1.4.2 System Analysis and Design and Development Tools...................................................5
2. SYSTEM ANALYSIS.............................................................................................................6
2.1 INTRODUCTION....................................................................................................................6
2.1.1 Purpose..........................................................................................................................6
2.1.2 Scope..............................................................................................................................8
2.1.3 Overview......................................................................................................................10
2.2 CURRENT SYSTEM................................................................................................................10
2.3 PROPOSED SYSTEM..............................................................................................................11
2.3.1 Overview........................................................................................................................11
2.3.2 Functional requirements...............................................................................................11
2.3.3 Nonfunctional requirements..........................................................................................13
2.3.4 Constraints (“Pseudo requirements”)..........................................................................26
2.3.5 System models...............................................................................................................26
3. SYSTEM DESIGN................................................................................................................35
3.1 INTRODUCTION....................................................................................................................35
3.1.1 Purpose..........................................................................................................................35
3.1.2 Scope.............................................................................................................................36
3.2 GOALS AND TRADE-OFFS.....................................................................................................37
3.3 SYSTEM DECOMPOSITION....................................................................................................40
3.3.1 Layers and Partitions....................................................................................................42
Final Project MicroLink IT College, 2023 Page iv

3.3.2 System Topology............................................................................................................43

3.4 CONCURRENCY IDENTIFICATION.........................................................................................45
3.5 HARDWARE/SOFTWARE ALLOCATION.................................................................................45
3.5.1 General system performance.........................................................................................47
3.5.2 Connectivity...................................................................................................................47
3.5.3 Network architecture.....................................................................................................48
3.6 DATA MANAGEMENT...........................................................................................................49
3.7 GLOBAL RESOURCE HANDLING...........................................................................................51
3.8 SOFTWARE CONTROL IMPLEMENTATION.............................................................................52
3.8.1 External control flow (between subsystems).................................................................52
3.8.2 Concurrent control........................................................................................................52
3.8.3 User Interface................................................................................................................53
3.9 BOUNDARY CONDITIONS..................................................................................................54
3.9.1 Initialization..................................................................................................................54
3.9.2 Termination...................................................................................................................56
3.9.3 Failure...........................................................................................................................57
3.10 DESIGN RATIONALE..........................................................................................................57
4. IMPLEMENTATION..........................................................................................................59
4.1 OVERVIEW...........................................................................................................................59
4.2 TOOLS AND TECHNOLOGY UTILIZED FOR IMPLEMENTATION.............................................59
4.3 SYSTEM IMPLEMENTATION..................................................................................................59
4.3.1 System Interfaces.......................................................................................................59
5. CONCLUSION AND FUTURE WORK............................................................................76
5.1 CONCLUSION........................................................................................................................76
5.2 FUTURE WORK....................................................................................................................76
REFERENCES............................................................................................................................78
GLOSSARY..................................................................................................................................79
Final Project MicroLink IT College, 2023 Page v

1. INTRODUCTION
1.1 Background
Attendance management is an important to every single organization; it is giving an advantage to
maximize the Organizations management system in the proper manner as well as well it will
have a big contribution of the productivity of organization. Organization will have to keep a
track of people within the organization such as employees and students to maximize their
performance. Managing student attendance during lecture periods has become a difficult
challenge. The ability to compute the attendance percentage becomes a major task as manual
computation produces errors, and wastes a lot of time.
The research will address one the primary school that is called Kelem Amba primary school
which is found in Gulele, Addis Ababa. The school was established by Saint Ruphael in Shih
Hojele Palace, was named after Mr. Abay Tefera since 1984G.C. The school’s name renewed as
Kelem Amba primary school.
Geographical conditions of the school
Kelem Amba High School is located at Gulele sub-city, District 09
 In the north, of Belay Zeleke, No.2 primary school
 In the South, Medihanalem Preparatory School
 In East, Gulele Sub-district
 In West, Wondim Gashe School
 Village 7 is located near Raphael Church and Shih Hojele Palace.
 The area of the school is 7193 square meters.
Around 653 students are served, 39 teachers are employed and it has 17 numbers of classes.
Final Project MicroLink IT College, 2023 Page 1

School Management Hierarchy
School Director
Key:
Targeted system
Assistant Director
Head of the Department
Subject Teachers Home-room Teacher
Administration
Staffs
Attendance
Figure 1: Chart of the school management
1.2 The Existing System

The Existing system is a manual entry for the students. Here the attendance will be carried out in
the hand written registers. It will be a tedious job to maintain the record for the user. The human
effort is more here. The retrieval of the information is not as easy as the records are maintained
in the hand written registers. This application requires correct feed on input into the respective
field. Suppose the wrong inputs are entered, the application resist to work. So, the user will find
it difficult to use.
This how they handle attendance using manual system, in the morning the home-room teacher
come to the class, and greeting his students after greeting, he takes out the attendance sheet and
call their name for five to 10 minutes. The manual attendance system is usually operated on

paper and it requires a lot of manpower to maintain the records. There are many drawbacks of
this kind of manual attendance system, such as low efficiency, poor accuracy, and high cost.
Therefore, the manual attendance system has been replaced by electronic devices that can record
the employee's work hours automatically.
There is no technology to solve a problem of attendance management for school right now in this
year today we are going to end this stressful old fashion method.
1.2.1 Overview of the Existing System

The manual attendance system is usually operated on paper and it requires a lot of manpower to
maintain the records. Here is how the teacher handle,
As we know the common attendance taking system is the teacher or attendance taker by
checking attendance paper list it will decide absent, present and permission.
1.2.2 Problems of the Existing System

Recording attendance manually is very time-consuming. Because the following reason, each
minutes has a value in the class, whenever the teacher meets their students, teacher expected to
finished within 45 minutes, such as class room management, give notes, teaches, ask questions,
answering questions, stabilization, telling the next lesson this all things within fourth five
minutes, but calling attendance as usual may take ten to fifteen minutes the remaining thirty
minutes cannot perform all activities.
Other drawback of manual attendance system; it can easily be manipulated, human error
possibility and time consuming.
For the stated reason, an efficient application for attendance management system is designed to
track student's activity in the class. This application takes attendance electronically and the
records of the attendance are storing in a database. To take attendance using our application, it
will take few minutes.
1.3 The Proposed System

The traditional attendance tracking method includes attendance list or some other sort of manual
system. However, this method requires consistent human supervision. But fortunately, the
evolving technology has led to the introduction of the automated attendance system that provides
much better results.

The purpose of this application is to simplify teachers and school administration barrier and
gives to this application to do the rest of things.
It will manage the all-school department such as students, teachers, sanitarian, security and
administration staff arriving and leaving time for their duties.
1.3.1 General Objective

This project intends to develop simple and accessible attendance tracker application system at
Kelem Amba primary school.
1.3.2 Specific Objective

With this in mind the specific objectives of this project lie in that: -
 To control the timing of an arrival and leaving.
 To avoid too much manual paper work and minimize repetition of work load.
 It is trouble free to use
 To save time and space in storing files.
 To increase the rate of retrieving data.
 To have attractive and Secure Login page to access
 Search easily the student and other stuff
 Efficient reports
1.3.3 Significance of the Project

 Records all the data automatically
 Easily track the student attendance.
 Provides accurate results
 Have a great opportunity to manage attendance
 Saves money, improves the productivity of the student
1.3.4 Scope of the Project

This study will develop the school attendance system at Kelem Abma primary school that makes
the efficient, productive, easy use, accessible in school attendance system. And will not address
other school systems because of the resource limit.

1.4 Methodologies and Techniques
1.4.1 Data Collection Methods and Techniques

The designers will use direct and indirect methods of collecting system requirements which
includes interviews with the research and questionnaires for the teachers and students. Additional
cumulative of documents review and system observations will be used in order to design the
system.
1.4.2 System Analysis and Design and Development Tools

An intended system will be developed that helps to extract the accurate data in time of manner.
In order to design this system, object-oriented analysis (OOA) method is used because it enables
us to comprehensively model the system before we develop it. A unified modeling language
(UML) which is a standard modeling language is used to analyze the software systems. Use case
diagram, class diagram, state chart and activity diagrams will be used.
In order to develop this system, a number of Technologies must be studied and understood.
These include Operating system such as Microsoft Windows 10 as a platform, a windows

programing Python, JavaScript and MySQL relational database (DBMS), Frameworks, notepad+
+ and other related application tools.

2. SYSTEM ANALYSIS
2.1 Introduction
The Introduction section of a Requirements Analysis Document (RAD) provides an overview of

the purpose and scope of the document. It explains the context of the project, the problem or
need that is being addressed, and the objectives that the software system must achieve.
This section serves as a high-level introduction to the document, and should provide enough
information for the reader to understand what the software system is supposed to do and why it is
being developed. It should also provide a clear and concise overview of the rest of the document,
including what information will be covered in each section.
This document provides an outline of the requirements analysis phase for the development of the
Student Attendance Management System. This system aims to automate the process of tracking
student attendance, managing student information, and generating reports for academic
institutions. The purpose of this document is to gather and analyze the requirements and provide
a comprehensive description of the system's functional and non-functional requirements.
Object oriented analysis (OOA) looks at the problem domain with the aim of producing a
conceptual model of the information that exists in the area being analyzed. Analysis models do
not consider any implementation constraints that might exist, such as concurrence, distribution,
persistence, or how the system is to be built. Implementation constraints are dealt during object-
oriented design (OOD). Analysis is done before the design.
2.1.1 Purpose
The purpose of the requirement analysis document of a student attendance management system
is to provide a comprehensive overview of the requirements that the system must fulfill in order
to meet the needs of stakeholders such as students, teachers, and principal or Administrator. The
purpose of this document is to ensure that all stakeholders have a clear understanding of the
system's goals and objectives, as well as the functional and non-functional requirements that
must be met for the system to be considered a success.

The external behavior of the system includes:
 Recording and updating student attendance: The system allows teachers to mark
attendance for each class, and the attendance data will be stored in the system database
for future reference.
 Reporting student attendance: The system generate reports on student attendance, such
as daily, weekly, or monthly attendance reports, and allow administrators to view and
download the reports.
 Integration with other systems: The system is able to integrate with other systems,
such as student information systems or teacher evaluation systems, to exchange data and
avoid duplication of data entry.
 User access control: The system has security controls to regulate who can access the
system and what actions they can perform. This includes user authentication, user roles,
and permissions.
The student management system should have a user-friendly interface that allows teachers and
administrators to easily record student attendance, view attendance records, and generate reports.
The system should be able to handle large amounts of data and support multiple users accessing
the system simultaneously.
Nonfunctional requirements:
The system has high availability and reliability to ensure that it is always available when needed.
The system also has strong security measures in place to protect sensitive student information.
Additionally, the system will be scalable to accommodate future growth and changing
requirements. The system also has a fast response time and be able to handle large amounts of
data.
Design constraints:
The design of the student management system should be modular, allowing for future expansion
and modification of the system. The system also has a compatible with the existing
infrastructure, including hardware and software, to minimize the cost of implementation. The
system also is easy to maintain and have low operational costs.

In addition to the above requirements, the student management system have also consider
accessibility and usability for different users, including teachers and administrators with varying
levels of technical proficiency. The system also is able to generate reports and provide access to
relevant information in a timely and efficient manner. The system should also be designed with
future growth and changing requirements in mind.
2.1.2 Scope
The scope of the requirement analysis document of a student attendance management system
includes defining the system's purpose, goals, and objectives, identifying the stakeholders who
will be impacted by the system, and defining the functional and non-functional requirements that
must be met for the system to be considered a success. Additionally, the scope of the document
should include a description of the system's intended users, the operating environment in which
the system will be used, and any constraints or limitations that will impact the system's
development or deployment.
The software product to be produced is called "Student Attendance Management System
The desktop and web-based application of student attendance management system or SAMS in
scope:
 Attendance Recording: Allows teachers to record student attendance for each class,
either in real-time or at a later time.
 It will send automatic SMS notifications to Student’s family about their attendance
status.
 Attendance Reports: Generates reports on student attendance, including attendance
percentage, number of absences and tardiness, and class-wise attendance reports.
 Student Information Management: Stores and manages student information,
including personal details, enrollment information, and attendance history.
 Absence Management: Allows teachers and administrators to manage student
absences and tardiness, including the ability to approve or reject requests for absence,
and track attendance exceptions.
 Integration with other systems: Integrates with other school systems, such as
student information systems, to provide a seamless transfer of data and to avoid data
duplication.

The desktop and web-based application of student attendance management system or SAMS out
of scope:
 Will not able to integrate with existing school systems, such as student information
systems or learning management systems.
 It will not provide educational content or resources, beyond the attendance data and
reports generated by the system.
 It cannot determine grades or academic progress, as this is outside the scope of the
attendance management system.
 Automatically enforce attendance policies or penalize students for poor attendance, as
this is the responsibility of the school administration.
The Student Attendance Management System is designed to assist schools in tracking student
attendance efficiently and accurately. The primary objective of the system is to provide a
streamlined, centralized platform for attendance tracking and reporting, which can help schools
to improve their attendance management processes.
1. Benefits: The use of the Student Attendance Management System can provide several
benefits for schools, including:
 Increased accuracy and efficiency in tracking attendance.

 Improved data security and confidentiality.
 Enhanced communication between teachers, students, and administrators.
 Real-time access to attendance data from any location.
 Automated notifications and reminders for students and teachers.
 Better visibility into attendance trends and patterns.
 Customization options to meet the specific needs of individual schools.
1. Objectives: The main objectives of the Student Attendance Management System include:
 To simplify the process of recording and tracking student attendance.

 To improve the accuracy and reliability of attendance data.
 To increase communication and transparency between teachers, students, and
administrators or principal.
 To make attendance data accessible from any location, using any device.

 To provide real-time notifications and reminders for students and teachers.

 To support data analysis and decision-making, by generating detailed attendance reports.
 To meet the diverse needs of different schools, with customization options.
1. Goals: The key goals of the Student Attendance Management System include:
 To reduce manual errors and inaccuracies in attendance tracking.

 To increase the speed and efficiency of attendance reporting.
 To provide a centralized platform for attendance management that can be used by all
stakeholders.
 To improve attendance data security and confidentiality.
 To enhance communication and collaboration between teachers, students, and
administrators.
 To support data analysis and decision-making, with the use of real-time attendance
reports.
 To provide a flexible and scalable solution that can adapt to the changing needs of
schools.
2.1.3 Overview
Attendance Management System basically has two main modules for proper functioning. Admin
module is having rights for creating any new entry of faculty and student details. User has a right
of making daily attendance, generating report. Attendance report can be taken by given details of
student details, date, and class.
2.2 Current system

The Existing system is a manual entry for the students. Here the attendance will be carried out in
the hand written registers. It will be a tedious job to maintain the record for the user. The human
effort is more here. The retrieval of the information is not as easy as the records are maintained
in the hand written registers. This application requires correct feed on input into the respective
field. Suppose the wrong inputs are entered, the application resist to work. So the user will find it
difficult to use.
This how they handle attendance using manual system, in the morning the home-room teacher
come to the class, and greeting his students after greeting, he takes out the attendance sheet and

call their name for five to 10 minutes. The manual attendance system is usually operated on
paper and it requires a lot of manpower to maintain the records. There are many drawbacks of
this kind of manual attendance system, such as low efficiency, poor accuracy, and high cost.
2.3 Proposed system

To overcome the drawbacks of the existing system, the proposed system has been evolved. This
project aims to reduce the paper work and saving time to generate accurate results from the
student’s attendance. The system provides with the best user interface.
The efficient reports can be generated by using this proposed system.
Advantages of Proposed System
 It is trouble-free to use.
 It is a relatively fast approach to enter attendance
 Is highly reliable, approximate result from user
 Best user Interface
 Efficient reports
2.3.1 Overview
The existing system for student attendance management uses manual entry in hand-written
registers. This is a time-consuming and error-prone process, with difficulty in retrieving
information and correct data entry. The proposed system aims to overcome these issues by using
a computer-based system with a user-friendly interface to reduce paper work, save time, and
provide accurate results. The system also generates efficient reports. Advantages of the proposed
system include ease of use, faster data entry, high reliability, and a user-friendly interface
2.3.2 Functional requirements
Functional requirements for the student attendance management system include the following
terms.
Attendance Recording:
1. Description: The system allows teachers to record student attendance for class in real-
time or at a later time.
2. Criticality: High. The core functionality of the student attendance management system is
to track student attendance, and this requirement is critical to the overall system.

3. Technical Issues: The system have an interface that is user-friendly and intuitive to use,
and able to handle multiple teachers recording attendance simultaneously.
4. Cost and Schedule: The cost of developing this feature will be moderate, and the
schedule will depend on the complexity of the interface design.
5. Risks: The risk of this requirement not being satisfied is low, but there may be issues
with the reliability and accuracy of the attendance data if the user interface is not
designed well.
6. Dependencies with other requirements: This requirement depends on the student
information management feature, as the system have access to student information in
order to record attendance.
Attendance Reports:
1. Description: The system must be able to generate attendance reports, including

attendance percentage, number of absences and tardiest and class-wise attendance
reports.
2. Criticality: High. Attendance reports are essential for school administrators to
monitor student attendance and make informed decisions.
3. Technical Issues: The have a reporting module that can generate reports in different
formats, such as PDF or Excel.
schedule will depend on the complexity of the reporting module.
5. Risks: The risk of this requirement not being satisfied is low, but there may be issues
with the accuracy and completeness of the attendance reports if the reporting module
is not designed well.
6. Dependencies with other requirements: This requirement depends on the attendance
recording feature, as the system must have access to accurate attendance data in order
to generate reports.

Student Information Management:
1. Description: The system store and manage student information, including

personal details, enrollment information, and attendance history.
2. Criticality: High. Student information management is essential for the accuracy
and reliability of the attendance tracking system.
3. Technical Issues: The system must have a database to store student information
and must have a user-friendly interface for entering and updating student
information.
schedule will depend on the complexity of the database and user interface design.
5. Risks: The risk of this requirement not being satisfied is low, but there may be
issues with data integrity and security if the database is not designed well.
6. Dependencies with other requirements: This requirement depends on the
attendance recording feature, as the system must have access to student
information in order to record attendance.
2.3.3 Nonfunctional requirements

Non-functional requirement is a requirement that specifies criteria that can be used to judge the
operation of a system. It defines how a system is supposed to be, it is often called the qualities of
the system. It is a technical requirement pertains to the technical aspects that our system must
have fulfilled.
We will describe the non-behavioral aspects of a software system that can be quantified and
qualified, such as performance, reliability, scalability, usability, security, and maintainability.
We will define the criteria that must be met for the system to be considered acceptable, and are
used to specify the constraints on the design and implementation of the system. Nonfunctional
requirements play a critical role in the development of software systems because we determine
how well the system will meet the needs of its users and stakeholders.

2.3.3.1 User interface and human factors

The type of user that will be using the student attendance management system would typically
include school administrators, teachers. The exact user group will depend on the specific design
and purpose of the system, as well as the requirements defined for the system by stakeholders.
For example, school administrators may use the system to manage attendance records, monitor
student attendance trends, and generate reports, while teachers may use the system to track
student attendance in real-time and input attendance data.
The system will used by more than one type of user will be using the student attendance
management system. This is because attendance management systems are typically used by a
variety of stakeholders in a school, including administrators, teachers. Each user group will have
unique requirements and needs for the system, and therefore the system will be design to
accommodate multiple types of users. The system has different levels of access and functionality
for each user group, based on the specific requirements defined for the system.
The type of training required for each type of user in the student attendance management system
would depend on the specific design and functionality of the system, as well as the background
and experience of the users.
For school administrators and teachers, training would typically focus on how to use the system
to input and manage attendance data, generate reports, and use the various features and functions
of the system. They may also need to be trained on how to use the system securely and protect
sensitive information.
The training will be designed to be as intuitive and user-friendly as possible, to minimize the
time and effort required for users to become proficient in using the system. We will include
providing documentation, tutorials, and hands-on training sessions, as well as ongoing support
and resources for users as needed.
It is particularly important that the student attendance management system be easy to learn. This
is because the system will be used by a wide range of users, including school administrators,
teachers. If the system is difficult to use or understand, it can result in increased training costs,
lower user adoption rates, and decreased efficiency in using the system.

Additionally, if the system is complicated or difficult to use, users may be more likely to make
mistakes, input incorrect data, or overlook important features. This can compromise the accuracy
and reliability of the attendance data, which is critical for tracking student attendance and
making informed decisions regarding student attendance patterns and trends.
Therefore, designing the system to be as intuitive and user-friendly as possible is an important

consideration for ensuring the success of the student attendance management system. This may
involve conducting user research and testing to understand the needs and preferences of different
types of users, and using that information to inform the design of the system and its various
features and functions.
It is important that users of the student attendance management system be protected from making
errors. This is because errors in attendance data can have serious consequences, such as
inaccurately tracking student attendance, making incorrect decisions based on inaccurate
information, and even impacting the academic performance and overall success of students.
Errors can occur for a variety of reasons, such as incorrect data entry, system malfunctions, or
user misunderstandings of the system's functionality. To minimize the risk of errors, the system
will be designed with robust error-checking mechanisms, such as validation rules, input masks,
and built-in error messages.
The input/output devices that we will use the following common input output devices.
Keyboard and Mouse: These are traditional input devices that are commonly used for entering
data, navigating menus, and performing various action within the system.
QR Scanners: QR scanners will be used to track attendance by scanning QR on student ID

cards, which can be linked to each student's attendance records.
2.3.3.2 Documentation
Documentation is an essential part of any software development project, and the student
attendance management system is no exception. The following is a list of some of the types of
documentation that we will require for a student attendance management system:
1. Requirements Document: A document that outlines the functional and non-functional

requirements of the system, including the system's purpose, goals, and expected

outcomes.
2. Design Document: A document that describes the overall design of the system, including
the architecture, system components, and interfaces.
3. User Manual: A manual that provides step-by-step instructions for using the system,
including how to enter and retrieve student attendance information.
4. Technical Documentation: Documentation that provides technical information about the
system, such as the software and hardware requirements, the database schema, and the
software development process.
5. Training Materials: Materials that provide training and support for users of the system,
such as instructional videos, tutorials, and training manuals.
Maintenance Documentation: Documentation that provides information about ongoing

maintenance and support for the system, including procedures for resolving technical issues,
updating the system, and backing up data.
The audience for a document on an attendance management system in a primary school we will
include:
 Teachers - to ensure that they understand how to use the system and mark attendance
accurately
 School administrators - to communicate the benefits and goals of using the system.
2.3.3.3 Hardware considerations

The system requires different hardware and software to properly function. And some of the
requirements are stated below.
 Client computers each with the following minimal specification.
 Processor speed 3.0 GHz dual core or above;
 Hard disk 120 or above
 Memory 1 GB or above and upgradeable;
 Network interface card 10/100 network card;
 Backup storage external 160 GB USB HD;
 Stabilizer
 QR Scanner or Camera for data input and output.
 Laser Jet Printer for attendance report print

2.3.3.4 Performance characteristics
The speed, throughput, and response time constraints on a student attendance management
system would depend on the specific requirements and specifications of the system. However,
some general consideration will include:
 Response time: The system responds quickly to user input, such as marking attendance,
to minimize wait time for users.
 Throughput: The system is able to handle a high volume of attendance transactions
during peak usage times, such as the start or end of a class period.
 Speed: The system process and store attendance data in a timely manner to ensure that
the information is up-to-date and accurate.
These constraints are considered during the design and implementation of the attendance
management system to ensure that it meets the needs of the users and provides a smooth and
efficient user experience.
The size or capacity constraints on the data to be processed by a student attendance management
system will depend on the specific requirements and specifications of the system. However,
some general considerations could include:
 Data storage: The system has enough storage capacity to store the attendance data for
a sufficient amount of time, such as a school year or longer.
 Data processing: The system able to handle a large volume of attendance data
efficiently, such as for a large school with many students and classes.
 Data retrieval: The system provides quick and efficient data retrieval capabilities,
such as generating attendance reports.
It is important to consider these constraints when designing and implementing the
attendance management system to ensure that it can meet the needs of the users and
provide accurate and up-to-date information.
2.3.3.5 Error handling and extreme conditions
The response of a student attendance management system to input errors could depend on our
system. However, some general considerations could include:

 Validation: The system validates user inputs, such as student names and IDs, to minimize
the risk of errors.
 Error messages: The system provides clear and descriptive error messages to inform the
user of any input errors and suggest corrective actions.
 Correction: The system provides an efficient method for correcting input errors, such as
allowing the user to edit the incorrect information.
 Logging: The system log input errors for tracking and analysis purposes.
It is important to consider the response to input errors when designing and implementing the
attendance management system to ensure that it provides a smooth and efficient user experience
and minimizes the risk of incorrect information being recorded.
Some general considerations could include:
 Robustness: The system be designed to handle unexpected conditions, such as hardware
failures or network disruptions, to minimize the risk of data loss or corruption.
 Backup and recovery: The system implements backup and recovery procedures, such as
regular data backups, to minimize the risk of data loss in the event of an extreme
condition.
 Error logging: The system log errors and extreme conditions for tracking and analysis
purposes.
 Alerts: The system provides alerts, such as notifications or emails, to inform
administrators of extreme conditions and potential issues.
 Resilience: The system has built-in resilience features, such as redundant components or
failover mechanisms, to minimize downtime and ensure continuity of service.
2.3.3.6 System interfacing
The presence and nature of input from systems outside the proposed student attendance
management system would depend on the specific requirements and specifications of the system.
However, some general considerations could include:
1. Integration with other systems: The attendance management system may need to
integrate with other systems, such as a student information system or a scheduling
system, to obtain or share data.

2. Data import/export: The system needs to import data from external sources, such as a
CSV file or another database, or export data to other systems.
It is important to input from systems outside the attendance management system when designing
and implementing the system to ensure that it meets the needs of the users and provides a
seamless and efficient user experience.
The presence and nature of output from the proposed student attendance management system to
systems outside the system depend on the specific requirements and specifications of the system.
However, some general considerations could include:
1. Integration with other systems: The attendance management system need to integrate
with other systems, such as a student information system or a scheduling system, to
share or provide data.
2. Data export: The system needs to export data to external systems, such as a reporting
system or a data analytics tool.
It is important to consider the output from the attendance management system to systems outside
the system when designing and implementing the system to ensure that it meets the needs of the
users and provides a seamless and efficient user experience.
2.3.3.7 Quality issues
The requirements for reliability for a student attendance management system will be include the
following:
1. Uptime: The system has a high availability and minimal downtime to ensure that it is
available when needed by users.
2. Data accuracy: The system provides accurate and up-to-date information to ensure that
decisions based on the data are correct.
3. Data security: The system protects sensitive data, such as student records, from
unauthorized access, tampering, or loss.
4. Backup and recovery: The system implements backup and recovery procedures, such as
regular data backups, to minimize the risk of data loss and ensure business continuity in
the event of an extreme condition.
5. Error handling: The system handles errors in a consistent and predictable manner to

minimize the risk of data loss or corruption.

6. Performance: The system has sufficient performance and scalability to meet the needs of
the users and handle increasing amounts of data over time.
It is important the requirements for reliability when designing and implementing the student
attendance management system to ensure that it provides a secure and reliable service to the
users and meets the needs of the organization.
Whether the student attendance management system must trap faults depend on the specific
requirements and specifications of the system. Fault trapping is a common technique used to
identify and handle errors and exceptions in a software system.
If fault trapping is a requirement for the system, it will be necessary to implement error handling
mechanisms, such as try-catch blocks or exception handling, to detect and respond to faults in
the system. This can help to prevent the system from crashing or producing incorrect results, and
can also provide information that can be used to diagnose and resolve problems.
If fault trapping is not a requirement, the system may still need to implement error handling
mechanisms to respond to errors in a consistent and predictable manner. However, in this case,
the focus may be more on providing a smooth user experience and recovering from errors rather
than on trapping faults specifically.
2.3.3.8 System modifications

What parts of the system are likely candidates for later modification?
The parts of a student attendance management system that are some common parts of such
systems that are often subject to later modification include:
1. User interface: The user interface of the system, including the forms, screens, and reports
used to enter, view, and manipulate data, is often a candidate for modification as the
needs of the users evolve over time.
2. Data storage: The data storage components of the system, including databases, file
systems, and data warehousing, are often subject to modification as the size and
complexity of the data grows over time.
3. Business logic: The business logic of the system, including the algorithms and rules used
to process and manipulate data, is often subject to modification as the needs of the users

and the organization change over time.

4. Security: The security components of the system, including access controls, encryption,
and authentication, are often subject to modification as the security requirements of the
system evolve over time.
It is important to consider the potential for later modification when we designing and
implementing the student attendance management system to ensure that it is flexible and can be
adapted to changing needs over time. It is also important to consult with a IT specialist to
determine the best practices for ensuring modular and scalable design, which can facilitate later
modification.
What sorts of modifications are expected? The sorts of modifications that can be expected for a
student attendance management system would depend on the specific requirements and
specifications of the system, as well as the evolving needs of the users and the organization over
time. Some common modifications that are often made to such systems include:
Adding new features: New features can be added to the system to meet the evolving needs of the
users and the organization, such as new reports, forms, screens, or business logic.
Improving performance: Performance improvements can be made to the system to increase its
speed, throughput, and response time, as the size and complexity of the data grows over time.
Enhancing security: Security enhancements can be made to the system to improve its resistance
to attacks and ensure the confidentiality, integrity, and availability of the data, as the security
requirements of the system evolve over time.
Integrating with other systems:
The system can be integrated with other systems and services over time to enable data exchange
and collaboration between systems.
Updating to new hardware and software:
The system can be updated to run on new hardware and software over time to take advantage of
new technologies and improve its performance and reliability.
It is important to consider the potential for later modification when designing and implementing
the student attendance management system to ensure that it is flexible and can be adapted to

changing needs over time. It is also important to consult with a system administrator or IT
specialist to determine the best practices for ensuring that the system can be easily and efficiently
modified over time.
2.3.3.9 Physical environment

It is not specified where the target equipment for the student attendance management system will
operate. This information may be included in the requirements and specifications of the system,
or it will be determined based on the needs of the users and the organization. If this information
is not specified, it may be necessary to consult with the stakeholders or project team to determine
the operating environment for the target equipment. This information is important for
determining the hardware and software requirements for the system, as well as the security and
regulatory requirements that may apply.
The target equipment for a school attendance management system can be settled at the gate in
one or several locations. It depends on the specific requirements and design of the system.
This would depend on the specific implementation of the student attendance management system
and the environment it will be used in. If barcode technology is used, it is important to consider
the operating conditions and if they may affect the barcode scanning accuracy and functionality.
Factors such as temperature, humidity, light, vibration, and other physical factors can impact the
performance of barcode technology. It's crucial to assess these conditions and ensure that the
system and hardware can operate within the specified range for the environment it will be used
in.
2.3.3.10 Security issues

Access control is a critical aspect of the student attendance management system. It ensures that
only authorized users can access sensitive data and perform specific actions within the system.
There are different ways to implement access control in a system, and it depends on the specific
requirements of the student attendance management system. Some common methods include
using passwords, usernames, and roles-based access. It's important to define who will have
access to the system and what actions they can perform within the system. This helps to maintain
the security and confidentiality of the data, and prevents unauthorized access and manipulation.
Physical security refers to the protection of equipment, facilities, and data from theft, damage,

and unauthorized access. In the context of a student attendance management system, physical
security could be a concern if the system includes hardware components such as computers or
servers that store sensitive data. It's important to consider the physical security of these
components and implement measures to prevent unauthorized access and tampering. This could
include installing locks, using security cameras, and restricting access to specific areas where the
hardware is stored. It's important to assess the specific physical security requirements of the
student attendance management system and implement appropriate measures to ensure the
protection of the data and hardware components.
The security of a student attendance management system should be implemented using a

combination of technical and non-technical measures.
Technical measures: This includes the implementation of data encryption, firewalls, access
controls, and security audits. Data encryption ensures that sensitive data is protected and
unreadable to unauthorized users. Firewalls control the incoming and outgoing network traffic,
while access controls restrict access to the system to authorized users. Regular security audits
help to identify potential vulnerabilities and to address them proactively.
Non-technical measures: This includes the implementation of security policies, training

programs, and regular security awareness campaigns. Security policies define the standards and
guidelines for the secure use of the system, while training programs educate users on the proper
use and security of the system. Regular security awareness campaigns help to keep users
informed about potential security threats and how to avoid them.
It's important to continuously review and update the security measures in place to ensure that the
student attendance management system remains secure and protected against emerging security
threats.
 Yes, it is likely that users and groups will be created in the student attendance
management system. This is a common practice in order to control access to the
system and to ensure that sensitive data is only accessible by authorized users.
 Users may be assigned different roles and permissions based on their job
responsibilities and needs. For example, teachers may have the ability to record
student attendance, while administrators may have the ability to manage user
accounts and reports.

 Groups can be used to group together users with similar responsibilities or privileges.
This makes it easier to manage access to the system and to ensure that all users have
the appropriate level of access based on their role.
 It is important to carefully consider the user and group structure of the student
attendance management system in order to ensure that access to sensitive data is
properly controlled and that all users have the appropriate level of access to perform
their job responsibilities.
 Encrypting data while it is stored is a common security practice that helps to protect
sensitive information from unauthorized access. The use of encryption can help to
ensure that even if data is stolen or accessed by unauthorized individuals, the
information cannot be easily read or understood.
 Whether or not data will be encrypted in the student attendance management system
depends on the specific requirements of the system and the security needs of the
organization. If the data being stored contains sensitive information, such as personal
or financial information, then it may be necessary to encrypt the data while it is stored
in order to ensure the privacy and security of that information.
 If encryption is required, it is important to carefully consider the encryption algorithm
and key management practices to ensure that the encrypted data can be properly
secured and that the system is able to access the encrypted data as needed.
 If encryption is not required, it is still important to implement other security
measures, such as access control and user authentication, to help protect sensitive data
from unauthorized access.
2.3.3.11 Resources and management issues

Resources and management issues refer to the allocation of resources such as personnel, budget,
and time, as well as the development and implementation of plans and procedures for managing
the student attendance management system. This can include aspects such as project planning,
risk management, quality assurance, maintenance and support, and user training. It is important
to consider these factors in the development of the student attendance management system in
order to ensure that the system is developed and maintained effectively, and that it meets the
needs of the users and stakeholders.

 The frequency of backups for the Student Attendance Management System will depend
on the specific requirements and needs of the school or organization using the system.
However, as a best practice, it is recommended to perform backups regularly, such as
daily or weekly, to ensure that data is protected in the event of a system failure or other
unexpected issue. The frequency of backups can be discussed and determined during the
implementation and deployment phase of the system, taking into account the volume of
data being stored, the criticality of the data, and the organization's preferred level of risk
tolerance.
 The responsibility for performing backups of the Student Attendance Management
System can be assigned to the IT or technical support team within the school or
organization. This team would be responsible for setting up and maintaining backup
procedures, monitoring backup jobs, and ensuring that backup data is stored securely. In
some cases, the vendor or supplier of the Student Attendance Management System may
also provide backup and recovery services as part of their support and maintenance
package. Ultimately, the responsibility for backups should be clearly defined and
communicated to all relevant parties, to ensure that data is protected and available in the
event of a system failure or other issue.
 The responsibility for installing the Student Attendance Management System will
typically be assigned to the IT or technical support team within the school or
organization. This team would be responsible for setting up the necessary infrastructure,
configuring the system, and ensuring that it is properly integrated with any other existing
systems. In some cases, the vendor or supplier of the Student Attendance Management
System may provide installation and implementation services, including on-site support,
to assist with the setup of the system. The responsibility for installation should be clearly
defined and communicated between the school or organization and the vendor, to ensure
that the system is installed and configured correctly and in a timely manner.
 The responsibility for maintaining the Student Attendance Management System will
typically be assigned to the IT or technical support team within the school or
organization. This team would be responsible for ensuring that the system is operating
optimally, fixing any issues that arise, and making any necessary updates or upgrades to

the system. In some cases, the vendor or supplier of the Student Attendance Management
System may provide ongoing maintenance and support services, including bug fixes,
updates, and other technical assistance. The responsibility for system maintenance should
be clearly defined and communicated between the school or organization and the vendor,
to ensure that the system is maintained effectively and any issues are resolved in a timely
manner.
2.3.4 Constraints (“Pseudo requirements”)
 We developed using Python 3.7 and Django 3.2 or higher for the web application
framework.
 Use SQLite as the database, stored locally on each windows machine.
 Run on Windows 7, Windows 10 and Windows 11 Operating Systems even phone.
 And we used visual studio code for text editor purpose and there built-in terminal.
2.3.5 System models
2.3.5.1 Scenarios
Visionary Scenarios: In software engineering, a vision scenario refers to a high-level
description or narrative that outlines the desired future state or vision of a software system or
product.
This sub-section mentions the narrative description of what the users do to perform a certain task
and description of the system procedure.
Scenario 1: The user wants to check their attendance record.
Participant Actor: Student Flow of events
1. The student logs in to the web-based system with their username and password.
2. The student selects “View Attendance” link in the dashboard.
3. The student sees a table showing their attendance percentage, total days, and missed days
in the week or monthly.
4. The student can also download or print their attendance report as a PDF file.
5. The student logs out or navigates to another page.
Scenario 2: The user wants to mark the attendance of a class.

Participant Actor: Teacher Flow of events
1. The Teacher logs in to the web-based system with their username and password.
2. The Teacher selects “Attendance list” link in the dashboard.
3. The Teacher sees a list of students enrolled in the profile by clicking the navigation
arrow.
4. The Teacher checks the boxes for the students who are present, and leaves the boxes for
the absent students unchecked.
5. The Teacher clicks the “Submit” button to save the attendance data.
6. The Teacher gets a confirmation message and can view the attendance summary for the
session.
Scenario 10: The user wants to view the attendance report
Participant Actor: Principal Flow of events

1. The principal logs in to the web-based system with their username and password.
2. The principal selects “View Attendance report” link in the dashboard.
3. The principal sees a chart showing the average attendance percentage of each class
offered by the institution.
4. The principal can also filter the data by date range, department, or level.
5. The principal can download or print the attendance statistics report as a PDF file.

2.3.5.2 Use case model
Use Case Documentation
Use cases_01
Use Case Name: Login
Actors: Teacher, Admin and Student
Entry Condition: The system user should be authenticated.
Flow of Events:
1. 1. The user opens the website and enters his username and password then press
login “Login” button.
2. The admin can view the attendance sheet submitted by the teacher
3. The system checks the validity of the entered data.

4. The system displays profile home page for the user

Exit Condition:
 The teacher receives confirmation that attendance has been marked
 The marked attendance sheet is saved in the system
Use cases_02
Use Case Name: Take Attendance,
Actors: Teacher, Admin

Entry Condition: The teacher activates the "Take Attendance" function in the system
Flow of Events:
1. The system responds by presenting an attendance sheet or the camera to scan QR
ID of the student
2. The teacher marks attendance status for each student (present/absent) or he can
take (mark) attendance by PC’s camera.
3. The admin can view the attendance sheet submitted by the teacher
Exit Condition:
 The teacher receives confirmation that attendance has been marked
 The marked attendance sheet is saved in the system
Use Case_03
Use Case Name: View Attendance Report

Actor: Admin or Principal, Teacher and Student
Entry Condition: user logs into the system and navigates to the attendance report page
Flow of Events:
1. User specifies filters like date range, class, grade level, etc.
2. System generates summary attendance report with metrics like absence percentage,
tardiness, etc.
3. User reviews the report
Exit Condition: Attendance report is displayed to a user
Use Case_04
User Case Name: Automated Parent Notification
Actor: Administrator or Principal

Entry Condition: Student is marked absent for class

Flow of Events:
1. Administrator check absence status for student
2. Administrator looks up parent's email address in student profile
3. Administrator generates absence email to parent
4. Administrator sends email to parent
Exit Condition: Notification email sent to parent
2.3.5.3 Object Model

Name Description
Student Represents a student in the system. Contains information like Student ID, First
Name, Last Name, Email, Phone, etc.
Attendance Represents the attendance record of a student for a specific course. Contains
information like Attendance ID, Student ID (Foreign Key), Course ID (Foreign
Key), Date, Status (Present/Absent/Tardy), etc.
Teacher Represents an instructor or teacher. Contains information like Instructor ID, First
Name, Last Name, Email, Phone, etc.
Classroom Represents a physical classroom where courses are conducted. Contains
information like Classroom ID, Room Number, Capacity, Location, etc.
Semester (Optional) Represents an academic semester. Contains information like Semester
ID, Semester Name, Start Date, End Date, etc.
Attendance (Optional) Represents statistics related to attendance, like the percentage of
Statistics attendance for a particular course within a given date range. Contains information
like Course ID (Foreign Key), Attendance Percentage, Date Range, etc.
It includes the use case diagram and the documentation of each of the use cases
Object model: The fundamental objects that must be modelled within the Student Attendance
Management System are:
1. Student: Represents a student enrolled in a course.

2. Teacher: Represents a teacher who teaches a course.
3. Attendance Record: Represents a record of attendance for a student in a specific class on
a specific date.

4. Attendance Report: Represents a report that provides a summary of the attendance

records for a specific student or class.
These objects will be modeled to provide a structural view of the system and to satisfy its
requirements. Each object will have specific attributes and behaviors that will be used to fulfill
the functional and non-functional requirements of the system. For example, the Student object
might have attributes such as "Name," "ID Number," and "Enrollment Date," while the
Attendance Record object might have behaviors such as "Mark Attendance" and "Generate
Report."
Modeling these objects is an important step in the development process because it provides a
clear understanding of the system's structure and helps to identify any potential issues or design
challenges. By defining these objects, the system's architecture can be designed and built in a
more efficient and effective manner.
2.3.5.4 Data dictionary

Class: Student
Object Attribute Description
Student student_id Unique identifier for each student
first_name First name of the student
last_name Last name of the student
date_of_birth Date of birth of the student
Email Email address of the student
phone_number Phone number of the student
address Address of the student
Class: Attendance
Object Attribute Description

Attendance attendance_id Unique identifier for each attendance record
student_id References the student associated with attendance
course_id References the course associated with attendance
date Date of the attendance record
status Attendance status (e.g., present, absent, late)
Object Operations:

1. Add Student: Add a new student to the system with relevant attributes.
2. Update Student: Modify the information of an existing student (e.g., name, contact
details).
3. Delete Student: Remove a student and all associated records from the system.
4. Add Course: Create a new course and define its attributes.
5. Update Course: Modify course details (e.g., instructor, schedule) for an existing course.
6. Mark Attendance: Record the attendance of a student for a particular date and course.
7. Update Attendance: Modify the attendance status of a student for a specific date and
course.
8. View Student Attendance: Display the attendance records of a particular student.
9. View Course Attendance: Display the attendance records for a specific course.

2.3.5.5 Class diagrams

2.3.5.6 Dynamic models

3. SYSTEM DESIGN
3.1 Introduction
Student attendance is a crucial aspect of any educational institution. It helps educators keep
track of student progress, identify areas of improvement, and ensure that students are meeting the
necessary requirements to succeed academically. However, managing attendance manually can
be a tedious and time-consuming task for teachers and administrators.
To address this issue, a student attendance management system can be implemented. This system
automates the attendance tracking process, making it more efficient and accurate. It enables
teachers to record attendance electronically and access attendance reports in real-time.
Administrators can also monitor attendance patterns across classes and identify students who
may require additional support.
In this system design, we will explore the key features and components of a student attendance
management system. We will also discuss the technologies used to develop the system and the
benefits it offers to students, teachers, and administrators. With this system in place, educational
institutions can streamline attendance management, improve student outcomes, and enhance the
overall educational experience.
3.1.1 Purpose
The purpose of the system to which this document applies is to provide an automated solution for
student attendance management in educational institutions. The system aims to simplify and
streamline the attendance tracking process for teachers and administrators, while also improving
accuracy and reducing the likelihood of errors or fraud. The system will allow teachers to mark
attendance electronically, access attendance reports in real-time, and monitor attendance patterns
across classes. Administrators will also have access to attendance data, which can be used to
identify areas of improvement and provide additional support to students who require it. The
system is intended to improve student outcomes and enhance the overall educational experience
by enabling educators to make informed decisions based on attendance data.

3.1.2 Scope
The scope of a system design refers to the boundaries of the system, defining what is included
and excluded from the system. It also defines the objectives and requirements of the system, and
outlines the features and functionalities that will be developed.
In the case of a student attendance management system, the design scope would include the
following:
I. Objectives: The primary objective of the system is to provide an automated solution for
tracking and managing student attendance. This will enable educators to monitor
attendance patterns, identify areas of improvement, and provide support to students who
require it. The system will also improve efficiency by reducing the time and effort
required for attendance tracking.
II. Requirements: The system must be capable of recording attendance electronically,
generating attendance reports, and providing real-time access to attendance data. It must
also be secure and reliable, with appropriate measures in place to prevent errors and
fraud.
III. Features and functionalities: The system will include features such as attendance
tracking, attendance reporting, and data analysis tools. It will also include user
management functionality, enabling administrators to add or remove users and define
user roles and permissions. The system may also include additional features such as SMS
or email notifications, integration with other systems, and the ability to export attendance
data.
The Web based application of student attendance management system or SAMS out of scope:
 It will not accessible from any device with an internet connection, allowing students
and teachers to access attendance data from anywhere.
 Will not able to integrate with existing school systems, such as student information
systems or learning management systems.
 It will not provide educational content or resources, beyond the attendance data and
reports generated by the system.
 It cannot determine grades or academic progress, as this is outside the scope of the
attendance management system.

 Automatically enforce attendance policies or penalize students for poor attendance, as

this is the responsibility of the school administration.
 Exclusions: The system will not include features such as grading or assessment
functionality, as these fall outside the scope of attendance management.
The reason we minimizes the scope that will get complexity because of other subsystem
functionalities and also it cost to add up other functionalities.
3.2 Goals and Trade-offs

Goals
Design goals describe the qualities of the system that developers will optimize. Such goals are
normally derived from the non-functional requirements of the system. Design goals are grouped
into four criteria. These are:
o Performance Criteria:
 Response time: The system will respond quickly and efficiently to user requests, with
minimal delay or lag.
 Dependability: The system will be reliable and dependable, with minimal downtime or
system failures.
 Maintenance: The system will require minimal maintenance, with updates and fixes
delivered seamlessly and with minimal disruption to system performance.
o Security Criteria:
 Security: The system will be secure, with appropriate measures in place to prevent
unauthorized access, data breaches, or cyber-attacks.
o End User Criteria:
 Usability: The system will be user-friendly, with an intuitive interface that is easy to use for
teachers, administrators, and other stakeholders.
 Customization: The system will be customizable to meet the unique needs of different
educational institutions, including the ability to define user roles and permissions, set
attendance policies, and generate custom reports.

o Functionality Criteria:
 Attendance tracking: The system will accurately track attendance for all students in
all classes and provide real-time access to this data for teachers and administrators.
 Reporting: The system will generate custom reports and analytics to enable educators
to identify attendance patterns and trends and make informed decisions based on this
data.
Non-functional requirements such as performance, security, usability, reliability, and

maintainability can significantly influence the functional requirements (use cases) of a system.
For example, if the performance requirement is to have a system that responds within 2 seconds
for a particular use case, then the functional requirement of that use case would be to ensure that
the system can deliver the desired response time. Similarly, if the security requirement is to have
a system that prevents unauthorized access, then the functional requirement would be to ensure
that the system has appropriate security controls in place.
Trade-offs may need to be made between the non-functional and functional requirements of a
system. For instance, if the security requirement is high, it may cause additional authentication
steps, which could affect the usability of the system. In this case, the usability requirement may
need to be adjusted to balance the security requirement. Similarly, if the performance
requirement is high, it may lead to more complex system design, which could impact the
maintainability of the system. In this case, the trade-off could be between performance and
maintainability.
Trade-offs
Trade-offs are inevitable in trying to achieve a particular design goal. The following are
examples of trade-offs that are relevant to the Student Attendance Management System:
 Extensibility versus Cost: While the system will be designed to allow for new features
to be added, doing so may increase the development and deployment costs for both users
and developers.
 Delivery Time versus Functionality: As the Student Attendance Management System is
a course project with a specific deadline, there may be some compromise on functionality

to ensure that the system is completed on time.

 Security versus Response time: While it is important to ensure the security of the
system by requiring user authentication, doing so may create a response time overhead
that could affect system performance.
 Usability versus Functionality: While the system will be user-friendly, there may be
some compromise on functionality due to the limited scope of the system and the fact that
it is designed for a specific section of the college.
 Response time versus Quality: While the system will generate attendance reports and
registration confirmation in a timely manner, doing so may require some trade-off with
quality or accuracy.
 Portability versus Efficiency: While the system will be designed to be compatible with
different infrastructures, making it fully portable may require additional cost and effort.
 Cost versus Reusability: The proposed Student Attendance Management System will be
developed using python programming language and PostgreSQL as the database. By
using a centralized system, only the server needs to have the database software installed,
which eliminates the need for the installation of the database software on individual client
computers. This approach reduces the cost of the system and the complexity of
maintenance as most maintenance work can be done on the server-side. However, in a
decentralized system, each client computer will require the installation of the database
software, which can be a complex and costly task. The trade-off here is between the cost
and reusability of the system.
 Reliability versus Cost: In order to ensure a high level of reliability in the Student
Attendance Management System, the organization may need to invest in high-quality
hardware, software, and network infrastructure. This will increase the cost of the system,
but it is important to ensure that the system is reliable and available to users at all times.
The trade-off here is between the reliability and the cost of the system.
The design priority for the Student Attendance Management System (SAMS):
Design Priority:
 Usability: The system will be user-friendly, with an intuitive interface that is easy to use
for teachers, administrators, and other stakeholders. The system will have a consistent
and well-designed user interface, with clear navigation, intuitive workflows, and

contextual help.
 Reliability: The system will be reliable and dependable, with minimal downtime or
system failures. The system will be designed to handle high traffic volumes, with
appropriate failover and recovery mechanisms in place to ensure that the system remains
available.
 Security: The system will be secure, with appropriate measures in place to prevent
unauthorized access, data breaches, or cyber-attacks. The system will be employ
encryption and secure communication protocols, and user access will be controlled
through role-based access controls and other security mechanisms.
 Functionality: The system will provide the necessary functionality to meet the needs of
educational institutions, including attendance tracking, reporting, and integration with
other educational systems. The system will be customizable to meet the unique needs of
different educational institutions.
 Performance: The system will respond quickly and efficiently to user requests, with
minimal delay or lag. The system will be designed to handle high traffic volumes, with
appropriate load balancing and performance tuning mechanisms in place.
 Maintenance: The system will be require minimal maintenance, with updates and fixes
delivered seamlessly and with minimal disruption to system performance. The system
will be designed with modularity and scalability in mind, making it easy to add or modify
functionality as needed.
By prioritizing usability, reliability, security, functionality, performance, and maintenance, the
Student Attendance Management System will be provide an effective and efficient solution for
attendance tracking and management.
3.3 System Decomposition

Subsystem decompositions will help reduce the complexity of the system. The subsystems can
be considered as packages holding related classes/objects. The SAMS which is designed for the
Kelem Amba primary school under the consideration is decomposed into subsystem.
Some of the major subsystems that could be identified for the Student Attendance Management
System (SAMS) are:
 Registration Management: This subsystem manages the registration of students and

maintains their personal and contact information. For capturing attendance data and
storing it in the database. It includes components for taking attendance, handling
exceptions, and generating reports.
 Database Management System: This subsystem is responsible for managing the
database that stores all the attendance data. It includes components for data storage,
retrieval, and management.
 Reporting System: This subsystem is responsible for generating various types of reports,
such as attendance reports, summary reports, and exception reports. It includes
components for data aggregation, filtering, and visualization.
 Communication System: This subsystem is responsible for facilitating communication
between different components of the system, as well as with external systems or services.
It includes components for scanning Student ID by Barcode reader, printing for
attendance report and other device also considered.
Registration Attendance
Tracking DB Management
Management Sys
Sys.
Student Attendance
Management System (SAMS)
Reporting Communicatio
System n System
Figure: 2 Representation of system Topology of SAMS

The major subsystems are interrelated and interact with each other to achieve the overall goal
of the system.
The "Registration Management" subsystem registers a student and the "Report Management"
subsystem also interacts with each other. Therefore, the subsystems are interconnected and
rely on each other to function properly. Any changes made to one subsystem may affect the
others, and it is essential to consider the interdependencies of the subsystems when designing
or modifying the system.
In the case of SAMS, the subsystems may need to call on each other's services, such as the
"Registration Management" subsystem needing to verify a student's enrollment in a specific
course with the "Course Management" subsystem. However, it's also possible that each
subsystem could operate independently without direct communication with other subsystems.
Ultimately, it depends on the design of the system and the specific requirements for each
subsystem.
3.3.1 Layers and Partitions

Layered and Partitioned architecture Organizes the system into layers with related functionality
associated with each layer. A layer provides services to the layer above it so the lowest-level
layers represent core services that are likely to be used throughout the system. Partitioning
allows replacement of entire layers so long as the interface is maintained. Redundant facilities
(e.g., authentication) can be provided in each layer to increase the dependability of the system.
Layered approach supports the incremental development of systems. As a layer is developed,
some of the services provided by that layer may be made available to users.
In a software system, dependencies between subsystems represent how one subsystem relies on
another subsystem's services or functionality to perform its own tasks. In the case of the Student
Attendance Management System, we can identify several dependencies between the subsystems:
1. The attendance tracking system depends on the registration subsystem to obtain
information about students and their schedules.
2. The attendance tracking system depends on the database management subsystem to store
and retrieve attendance data.
3. The reporting system depends on the attendance tracking system to obtain attendance
data and generate reports.

4. The reporting system also depends on the database management subsystem to retrieve
additional information to include in reports.
5. The communication subsystem depends on the registration system to obtain contact
information for students and instructors.
Figure:3 The Layered architecture of SAMS

The top layer is responsible for implementing the user interface. In this case, the UI has been
implemented using a Windows form. The second layer provides the user interface functionality
that is delivered through the UI. It includes components to allow users to log in to the system and
checking components that ensure that the operations they use are allowed by their role. This
layer includes form and menu management components that present information to users, and
data validation components that check information consistency.
The third layer implements the functionality of the system and provides components that
implement system security, students, Attendance, report and updating, import and export of these
data from databases, and report generators that create and management reports. Finally, the
lowest layer, which is built using a database management system, provides transaction
management and persistent data storage.
3.3.2 System Topology

The system topology which shows the component and deployment diagrams are generated using
Microsoft Visio UML model. The Component diagram depicted on Fig 4 shows the software
components of an SAMS system and how they are related to each other.

Figure 4: Component diagram of the SAMS System
The deployment diagram show how software components are physically deployed on processors;
that is, the deployment diagram shows the hardware and software in the SAMS system and the
middleware used to connect the different components in the system.
Figure 5: Deployment diagram of the SAMS System

3.4 Concurrency Identification

The objects that are independent for a student attendance management system would typically be
those that have their own independent existence and do not depend on other objects to function.
Some examples of such objects in a student attendance management system could include:
Student: This object represents a student and can store information such as the student's name,
ID number, and contact details.
Attendance record: This object represents a single instance of attendance for a particular
student and can store information such as the date, time, and attendance status (present, absent,
etc.) for the student.
Attendance report: This object represents a summary of attendance for a particular student or
course and can be generated based on the attendance records stored in the system.
The division of the student attendance management system into different subsystems has been
designed so that the dependency among the subsystems is at the minimum. First of all, many of
the operations performed by subsystems require read-only access to files in the system through
which data management activities achieved, which does not bring any dependency between
objects since read-only accesses can be performed concurrently. Secondly, the report
management, student management, email management and discussion board management
subsystems are independent from each other. And these mentioned subsystems are dependent on
the data submitted by the user management, registration management, assessment management
and course management subsystem. In the system design of the student attendance management
system, usage of threads has not been employed because users access the system from different
locations and the operations requested by these users are handled individually on the user basis
as independent processes. In addition, the operations requested are simple Query operations
which do not require the usage of additional threads within processes.
3.5 Hardware/Software Allocation
In order to develop this system, a number of Technologies must be studied and understood. This
includes hardware and software platform for the client environment and development.

The Hardware platform chosen for development of the system

Laptop computer RAM 8GB
(for HDD 640 GB
portability) CPU Core i5
The Software platform chosen for development of the system
Operating system Microsoft
Windows 10
Programming Python
language
Databases Postgresql
In this project, a programming language python and relational databases (such as Postgre SQL)
as back-end tool which runs on Windows will be used.
PostgreSQL is used because it is a relational database management system. Python are best
matches for developing Web application.
Table 10: The existing hardware platform of the client environment
Hardware Minimum Requirement

Requirement
Personal RAM 1 GB or larger
Computer HDD 320 GB or more
(client computer) CPU Dual Core, Pentium IV 2.8 GHz or
higher, or
Compatible. (for a better performance to
run other
programs concurrently)
Interface USB 2.0 (480 Mb/s)
Monitor 15” CRT or LCD monitor
Keyboard Normal or multimedia (USB/PNP)
Mouse Compatible mouse (USB/PNP)
QR code OS Window
Cable USB-2.0
RAM OS Windows 7
HDD USB 2.0
Server (optional)
CPU RAM
Back up HDD

3.5.1 General system performance
The system provides an access to the database without any delay and this period must not exceed
5 seconds depending on the computer speed. The system can support up to 15 simultaneous users
against the central database at any given time.
3.5.1.1 Input/output Performance

Inputs come to the system from authorized users and the system analyzes and provides with
different out puts for the users based on their demand. The status of database must be updated
right after any of the actors in the system make any change. The system doesn’t need extra piece
of hard wares to handle the data generation rate at the current situation.
3.5.1.2 Processor allocation

The system is not supposed to handle heavy arithmetic operations or long computations. It will
be dealing with simple database queries, so it is not crucial for the system to manage a multiple
processor environment. But since other programs may also run concurrently it would be better to
use multiple processors for a better performance.
3.5.1.3 Memory allocation

The operations performed in the system do not desire large memory allocation, even if it can be
accessed by multiple users at a time, with different or similar kind of request. So a memory
allocation of 4 GB is enough for the system to run properly but we will define the memory size
of for the SAMS, this is due to the expandable property of the education
3.5.2 Connectivity
Data base
Client server
Figure: 6 Connectivity Diagram

The connectivity between a client computer and a server/database typically involves a client-
server architecture. The client computer connects to the server over a network, sends requests for
information or services. The server then processes the requests and sends back responses to the
client.
In terms of the database, the server is responsible for managing the database and responding to
queries made by the client. The client can send database queries to the server to retrieve or
modify data. The server then executes the queries and sends back the results to the client. This
communication between the client and server over a network forms the basis of client-server
architecture.
3.5.3 Network architecture

Network architecture is the design of a computer network, including the physical and logical
components that make up the network, the protocols and algorithms used to send data, and the
network's topology. The network architecture defines the rules and standards that govern how
devices on the network interact and communicate with each other, as well as how data is routed
across the network. It is important to design a network architecture that is reliable, secure, and
scalable, as it will need to be able to handle increasing amounts of data and traffic as the network
grows.
The proposed system is expected to replace the existing manual system by an automated system
in all facets. It is mainly based on the Requirement Analysis document. Here is a sample
description of the connection channels, communication protocols, and interaction mechanisms
for a student attendance management system:
Connection Channels
The system uses a combination of wired and wireless connections. Wired connections via
Ethernet are used between servers, routers, and wired client machines located in classrooms and
offices. Wireless WIFI connections are used by mobile devices like laptops, tablets, and
smartphones.
The wired connections consist of Cat5e or Cat6 Ethernet cabling providing 1Gbps or faster
bandwidth between devices. This forms the campus wired LAN spanning different buildings.
The WIFI connections use the 802.11n standard with dual-band 2.4GHz/5GHz and bandwidth up
to 300Mbps. Access points are distributed throughout the campus to maximize wireless
coverage.

Communication Protocols
For wired networking, TCP/IP is used with common protocols like HTTP, HTTPS, FTP, SSH,
and SNMP for device management.
For wireless, TCP/IP is also used with standard encryption like WPA2 for secure connections.
The WIFI network has multiple redundant SSIDs and uses VLANs to segment user traffic.
Interaction Mechanisms
The system uses synchronous request-response interactions between the student mobile apps and
backend servers. Requests use HTTP/HTTPS protocols with REST APIs.
The mobile apps send attendance information to the servers which validate and process the data.
The synchronous nature allows the apps to receive real-time feedback.
Latency is generally low within the LAN. The wired connections provide reliable high-
throughput channels. The WIFI network provides solid coverage across campus with seamless
roaming and redundancy to mitigate any potential wireless disruptions. The synchronous
protocols allow real-time student attendance tracking with minimal delays
3.6 Data Management

The internal and external data stores in a system provide clean separation points between
subsystems with well-defined interfaces. In general, each data store may combine data structures,
files and databases implemented in memory or on secondary storage devices.
The system also uses main memory to store data temporarily during processing, such as when
taking attendance or generating reports. The attendance tracking system component of SAMS
records and maintains the attendance records of students. This information is then stored in the
database, which can be accessed by other subsystems for generating reports or checking student
performance.
The communication subsystem is responsible for facilitating communication between the client
computer and the server, as well as between subsystems. It uses a variety of protocols to ensure
reliable and secure data transfer between different components of the system.
Overall, the system efficiently manages data using a combination of database management
systems, main memory, and communication subsystems.
The SAMS is designed as a centralized system, then the data will be stored on a central server

and accessed by client devices through a network connection. In this case, the data is not
distributed.
It may be desirable to have a database that is extensible to allow for future growth and changes in
the system.
For example, if the system needs to be scaled up to accommodate more students, courses, or
data, an extensible database can make it easier to add new fields, tables, or other elements to the
database structure without having to overhaul the entire system. Additionally, an extensible
database can make it easier to integrate new features or modules into the system as needed.
However, it's important to balance the need for extensibility with other factors such as
performance, security, and maintainability. If the database becomes too complex or unwieldy, it
can impact the overall performance and reliability of the system. Therefore, careful consideration
and planning should be done before deciding to make a database extensible.
Top of Form
The average request (query) rate and worst-case scenario would depend on various factors such
as the number of students, the frequency of attendance tracking, the number of queries made by
the system users, and the system design. In our case we think the average request is 4mb/s and
the worst case is 8mb/s.
Mostly the database accessed when the student come to school in the morning and leave the
school in the afternoon. Sometime the teacher or the school administrator checking the system.
For example, a query to retrieve a single student's attendance record may be smaller in size
compared to a query to retrieve attendance records for an entire class or a specific date range.
In general, the size of the queries may not be very large and can be considered relatively small in
terms of data transfer. However, in worst case scenarios where large amounts of data are being
requested or the query is complex, the size of the request (query) may become much larger and
require more resources to process. This could lead to slower response times or even system
crashes if not properly managed.
In a student attendance management system, it may be necessary to archive certain data for
future reference and auditing purposes. This may include attendance records, student information
and report data. The database will archive the records after 6 months of Storage in the database.

Yes, the system will encrypt the database and transmission communication protocols unit they
are delivered to the database in the server
The files in the set have a relational nature because they are organized and indexed within a
structured database. Even though the method of accessing them is object-oriented, they are not
stored as objects.
3.7 Global Resource Handling

Yes, we provide a python-based Student Attendance Management System (SAMS),
authentication is an important component that ensures the security and privacy of the system.
Python provides several ways to authenticate users.
Windows Authentication is a secure and widely used authentication method in Windows-based

systems. It uses Windows credentials to validate users and allows them to access system
resources based on their assigned permissions.
The user interface will prompt the user to enter their login credentials, which typically consist of
a username and password. These credentials are then verified against a database or other
authentication source, such as Active Directory or LDAP, to determine whether the user is
authorized to access the system.
A server-class machine or cluster of machines is used to handle the load of global resource
management, including tasks such as load balancing, failover, and synchronization. This may
involve using specialized hardware such as network load balancers, dedicated storage devices,
and redundant power supplies to ensure high availability and reliability.
In a distributed system, other subsystems can discover the subsystem service using a service
discovery mechanism. This mechanism involves a registry or a directory where subsystem
services can be registered and other subsystems can look up these services. The registry can
provide information about the service, such as its endpoint or address, protocol, and other
metadata.

3.8 Software Control Implementation
3.8.1 External control flow (between subsystems)

A centralized control flow can simplify the system design and management, but may create a
single point of failure or bottleneck. Ultimately, the choice between distributed and centralized
control flow depends on the specific needs and constraints of the system, and should be carefully
evaluated and balanced. Is there a single control flow residing within a single program?
This class firstly listens the login subsystem, when login subsystem informs the Control System
about any of the users start working, Control System wants the users to store the data in the
database, Control System informs the current subsystem user about start working.
Procedures do not wait for input. Instead, they typically expect input parameters to be passed to
them when they are called. Once the input parameters have been passed, the procedure will
execute its logic and return a result or output.
In a dispatcher-based system, there is typically a single control flow residing within the
dispatcher component. The dispatcher receives requests from clients and dispatches them to the
appropriate subsystems or components within the system. The control flow of the dispatcher
determines how requests are processed and how subsystems interact with each other.
Yes, a dispatcher can wait for events and dispatch them to the appropriate procedure that will
handle the event. This is known as the callback mechanism, where the procedure provides a
callback function or procedure to the dispatcher, which is called when the event occurs. The
dispatcher then passes the event to the callback procedure for processing, allowing the program
to respond to the event asynchronously and without blocking other operations. This approach is
often used in event-driven programming and can be implemented using various programming
languages and frameworks.
3.8.2 Concurrent control

In a student attendance management system, there are several subsystems or components that can
be run concurrently, including:
Attendance tracking subsystem: This subsystem can run concurrently with other subsystems,
such as registration or reporting, as it records attendance data in real-time.

Reporting subsystem: This subsystem can be run concurrently with other subsystems, as it
generates reports based on attendance data stored in the database.
Database management subsystem: This subsystem can run concurrently with other subsystems,
as it manages the storage and retrieval of attendance data and user information.
User authentication subsystem: This subsystem can run concurrently with other subsystems, as it
authenticates users' credentials when they log in to the system.
In a student attendance management system, both procedure calls and threads can be used to
implement process control. Procedure calls can be used to coordinate the actions of different
subsystems, while threads can be used to handle incoming requests and perform tasks
concurrently.
Procedure calls can be used to coordinate the actions of different subsystems and components in
the system. For example, a subsystem responsible for attendance tracking may call a procedure
in the database management subsystem to retrieve student information or update attendance
records.
Threads can also be used to implement process control in a concurrent system. Each thread
represents a separate execution context that can perform tasks concurrently with other threads.
For example, a thread can be created to handle incoming requests for attendance data, while
another thread can be responsible for updating attendance records in the database.
3.8.3 User Interface
Distributed Control Flow: In a distributed control flow, different subsystems or components of

the system have their own control flow, and they communicate with each other to coordinate
their actions and exchange data. This approach can provide more flexibility and scalability in the
system design, as different subsystems can evolve independently and communicate
asynchronously. For example, the attendance tracking subsystem have its own control flow and
communicate with other subsystems through messaging protocols or other mechanisms.
 Is the control centralized? Yes, the IT administrator is responsible for managing the database
control, and a central IT support manages the server administration.
b) Do subsystems have individual user interfaces and event loop management? Yes, each
subsystem uses its own interface and event loop handlers.

3.9 Boundary Conditions
3.9.1 Initialization
As soon as the SAMS deployment setup finished the system will be initialized. When we come
to the system at start up the system requires authenticated user to provide the required
information to get access. Then the server populates the client machine with what the client
machine has asked for.
While the server starts at first, it will load all the necessary database files with their related pages
and student information. User friendly approach is considered while designing the UI so that
there will not be any ambiguity and complication while trying to access the system.
The dynamic model of the system start-up describes the behavior of the student attendance
management system as it goes from an uninitialized state to a fully operational state. The
following is a general description of the dynamic model of the system start-up:
 System Initialization: The system initializes when the user or system administrator starts the
system. This involves starting up the system software and hardware and loading the
necessary configuration files.
 Database Initialization: Once the system is initialized, the database is initialized by creating
necessary tables, indexes and views. The database is also populated with relevant data such
as student information, course information, and faculty information.
 User Login: After the database is initialized, the system prompts the user to login. The user
must enter their credentials to access the system. The system verifies the user's credentials
and grants access if they are valid.
 User Interface: Once the user logs in, the system displays the user interface. The user
interface allows the user to interact with the system, such as entering attendance data,
generating reports, and managing student records.
 Attendance Tracking: The system continuously tracks attendance data as it is entered by
faculty members or other users. The system updates the database with this information in
real-time.
 System Shutdown: When the user is finished using the system, they can log out, which will
initiate the system shutdown process. The system saves any unsaved data and safely shuts
down the system software and hardware.

 During the start-up of the student attendance management system, several types of data must
be accessed to ensure that the system is initialized correctly and ready for use. Configuration
data, which includes system settings and parameters, is crucial for the system to operate
correctly. This data may include database connection settings, time zones, and other
configuration parameters. User data, such as usernames, passwords, and authentication
information, must also be accessed to authenticate the user during the login process. The
student data is critical for the system to display student information and track attendance.
This data may include student names, ID numbers, and contact information.
The student attendance management system's user interface is a vital tool that enables the user to
interact with the system and manage student attendance. Upon successful login, the user
interface displays on the screen, presenting a dashboard that gives the user an overview of their
attendance data and records. Navigation options are also provided, allowing the user to move
seamlessly between different sections of the system. For example, the user can navigate to the
attendance tracking section to view or input attendance data or navigate to the student records
section to manage student information.
One of the significant features of the user interface is its capability to allow the user to input
attendance data. The user can select the relevant course and student and enter the attendance
information. The system provides several input options, such as checkboxes or dropdown menus,
to make the input process more manageable.
Another feature of the user interface is its ability to generate reports. The user can generate
attendance reports or course progress reports, which can be used to monitor student performance
and attendance. The user interface also provides a way to manage student records, including
adding or removing students from courses, updating student information, and viewing attendance
records.
The user interface also allows the user to configure system settings, such as changing the time
zone or adjusting user permissions. The system aims to make attendance management as
efficient and straightforward as possible by providing an intuitive and user-friendly interface.
 How does the system present itself to the user?
 As the user logs into the student attendance management system, the system presents
itself through its user interface. The user interface is the primary way for the user to
interact with the system and manage student attendance. At start-up time, the user

interface displays a dashboard that provides an overview of the user's attendance data
and records.
 In addition, the user interface offers navigation options, allowing the user to move
between different sections of the system with ease. For example, the user can
navigate to the attendance tracking section to view or input attendance data, or to the
student records section to manage student information.
 Overall, the system presents itself to the user in a user-friendly and intuitive way,
providing the necessary tools and options to manage student attendance effectively.
The user interface is designed to make attendance management as efficient and
straightforward as possible.
3.9.2 Termination
The main reason to termination on the system is finishing the activity. On termination the overall
activity including any updating on the database will be save.
 Are single subsystems allowed to terminate?
Yes, single subsystems are allowed to terminate within a larger system. In fact, termination of
subsystems is a common occurrence in many systems. When a subsystem terminates, it typically
means that it has completed its task or is no longer needed, and the resources it was using can be
released for use by other subsystems. However, it's important to ensure that the termination of a
subsystem does not cause any adverse effects on the rest of the system. Proper design and testing
of the system can help ensure that subsystem termination occurs in a safe and controlled manner.
 Are other subsystems to be notified if only a single subsystem terminates?
NO.
 Are local updates communicated to the database when the system or a subsystem
terminates?
Yes. Local updates are communicated to the database when a subsystem terminates to ensure
that all changes made during the subsystem's operation are saved to the database. For example, if
a subsystem is responsible for updating student attendance records, it may communicate these
updates to the database when it terminates so that the changes are saved and can be accessed by
other subsystems.

3.9.3 Failure
It is essential to consider potential failure scenarios when designing a system, especially in a
distributed environment where communication links between nodes are critical. In the case of
node or communication link failures, the system should have mechanisms in place to handle the
situation and maintain its overall functionality.
To handle hardware and the software failures, the user’s errors should be handled by using error
handling mechanisms and the system will use permanent storage database. This increases the
accuracy of the maintenance activities of the system. The system will use backup database. In
case of database failure, we use this backup to restore. Thus, Backup policy and procedures
should be enforced.
3.10 Design Rationale

When we designing the various subsystems of the student attendance management system,
several design issues were considered to ensure the system's robustness, scalability, and ease of
maintenance. One of the critical design issues that were addressed was performance. The system
is expected to handle a large number of users simultaneously, and as such, the subsystems were
designed to handle multiple requests concurrently without affecting the overall system
performance.
Reliability was also taken into account, and measures were put in place to ensure that subsystems
are fault-tolerant, and system downtime is minimized. This means that the system must be
reliable and available 24/7. To guarantee the security of the system, the subsystems were
designed with security in mind. User authentication, access control, and encryption were
implemented to prevent unauthorized access to sensitive information such as student data and
attendance records.
Scalability was also a major design issue that was addressed. The system should be able to
handle an increasing number of users and data over time. Therefore, the subsystems were
designed to be scalable and flexible, allowing for easy addition of new features and
functionalities.

To address these design issues, certain design decisions were made. For instance, a distributed
architecture was chosen to improve system performance and scalability. The subsystems were
designed to communicate asynchronously to minimize communication overhead and reduce
system latency.
Several proposals were considered but rejected during the design process. For example, using a
centralized database to store all student data and attendance records was deemed impractical, as
it would result in a single point of failure and poor system performance. Instead, a distributed
database was used, with each subsystem having its own database to improve reliability and
performance.
The main arguments for the design decisions made were the need for scalability, fault-tolerance,
and security. On the other hand, the main argument against some proposals was the potential
impact on system performance and reliability.
Important issues that are still unresolved include improving system availability in the event of
node or communication link failures and addressing potential security vulnerabilities that may
arise in the future. These issues are still being actively researched, and solutions will be
implemented as they are discovered.

4. IMPLEMENTATION
4.1 Overview
This section briefly lists the tools and technology utility, source code, conclusion and future
work of the system. It also considers the major interface that can describe the implementation of
the proposed system. This system entitles Student attendance management implemented on
windows environment on which it supports network infrastructure. It should be first installed on
server and accessed through a network.
4.2 Tools and Technology Utilized for Implementation

The system is composed of front-end and back end. Both layer work together to provide the
desired functionality of the system. For system analysis and design draw.io will be used. Draw.io
is a diagramming tool that uses vector graphics to create diagrams.
For front-end we used bootstrap framework and back-end development we used Django
framework, visual studio code will be used for text editor. The system will implement also
PostgreSQL as data. PostgreSQL is a full-featured relational database management system that
offers much functionality. In addition, the target platform must be Intel based machine. During
Implementation the operating environment that can be appropriate for our system is windows 10
that support network facility.
4.3 System Implementation
4.3.1 System Interfaces

The major system interfaces of our system Student Attendance Management system is presented
here under.
Login Template
{% extends "base.html" %}
{% load static %}
{% load crispy_forms_tags %}
{% block title %}
KAPS | Login
{% endblock %}
{% block login %}
<div class="container mt-3">

<div class="row">
<div class="col-sm-10">
<img src="http://127.0.0.1:8000/media/logo/logo.jpg" width="190" height="150">
</div>
<img class="rounded-circle" src="http://127.0.0.1:8000/media/logo/school-house.jpg " width="200"
height="150">
</div>
<hr>
</div>
<hr>
<div class="row justify-content-center bg-light">
<div class="col-md-4">
<form class="card p-3" method="post" enctype="multipart/form-data" style="background-color:
rgb(235, 229, 229);">
<h3 class="font-weight-bold text-monospace text-success text-center">Login</h3>
<hr>
{% csrf_token %}
<div class="form-group ">
{{ form|crispy }}
</div>
<button type="submit" class="btn btn-light text-light" style="background-color:
#21D192">Login</button><br>
<a href="#Not configuring" class="btn btn-light text-light" style="background-color:
#21D192">Change Password</a>
</form>
</div>
</div>
<hr>
<div class="container my-2">

<footer>
</section>
<div
class="text-center p-3"
style="background-color: rgba(0, 0, 0, 0.2)"

>
© 2023 Copyright:
<a class="text-dark" href="https://mdbootstrap.com/"
>KAP School</a
>
</div>
</footer>
</div>
</body>
</html>
{% endblock %}
Registration Template
{% extends "base.html" %}
{% load static %}
{% load crispy_forms_tags %}
{% block title %}
KAPS | Registration
{% endblock %}
{% block registration %}
<div class="container mt-3">
<div class="row">
<img src="http://127.0.0.1:8000/media/logo/logo.jpg" width="190" height="150">
</div>
<img class="rounded-circle" src="http://127.0.0.1:8000/media/logo/school-house.jpg " width="200"
height="150">
</div>
<hr>
</div>
<hr>
<div class="row justify-content-center bg-light">
<div class="col-md-5">

<form class="card p-3" method="post" enctype="multipart/form-data" style="background-color:

rgb(235, 229, 229);">
<h3 class="font-weight-bold text-monospace text-primary text-center">Registration</h3>
<hr>
{% csrf_token %}
<div class="form-group ">
{{ form|crispy }}
</div>
<button type="submit" class="btn btn-light text-light" style="background-color:
#21D192">Register</button><br>
</form>
</div>
</div>
<hr>
<div class="container my-2">

<footer>
</section>
<div
class="text-center p-3"
style="background-color: rgba(0, 0, 0, 0.2)"
>
© 2023 Copyright:
<a class="text-dark" href="https://mdbootstrap.com/"
>KAP School</a
>
</div>
</footer>
</div>
{% endblock %}
Register, Login and Logout View Functions

from django.contrib.auth import authenticate, login
from django.shortcuts import render, redirect
from accounts.forms import UserProfileRegistrationForm, LoginForm

from django.contrib.auth.models import Group

from django.core.exceptions import ObjectDoesNotExist
from django.contrib.auth import authenticate, login
from django.contrib.auth.forms import AuthenticationForm
from .models import UserProfile
from django.contrib.auth import logout
def registration_view(request):
if request.method == 'POST':
form = UserProfileRegistrationForm(request.POST, request.FILES)
if form.is_valid():
user_profile = form.save()
user = user_profile.user
group_name = user_profile.user_type.lower() + 's'
try:
group = Group.objects.get(name=group_name)
except ObjectDoesNotExist:
pass
else:
group.user_set.add(user)
return redirect('accounts:login')
else:
#form = UserProfileRegistrationForm(user=request.user)
form = UserProfileRegistrationForm()
return render (request, 'accounts/registration.html', {'form': form})
def login_view(request):
if request.method == 'POST':
form = AuthenticationForm(request=request, data=request.POST)
if form.is_valid():
username = form.cleaned_data.get('username')
password = form.cleaned_data.get('password')
user = authenticate(request, username=username, password=password)
if user is not None:
user_profile = UserProfile.objects.filter(user=user).first()

if user_profile is not None:

print (user_profile.user_type)
login(request, user)
if user_profile.user_type == 'Principal':
return redirect('attendance:principal')
elif user_profile.user_type == 'Teacher':
return redirect('attendance:teacher')
else:
return redirect('attendance:student')
else:
form.add_error(None, 'Invalid login credentials.')
else:
form.add_error(None, 'Invalid login credentials.')
else:
form = AuthenticationForm()
return render(request, 'accounts/login.html', {'form': form})
def logout_view(request):
logout(request)
return redirect('accounts:login') # redirect to your desired page after logout
Registration, Login Form

from django import forms
from django.contrib.auth.forms import UserCreationForm, AuthenticationForm
from django.contrib.auth.models import User
from django.contrib.auth.forms import AuthenticationForm
from crispy_forms.helper import FormHelper
from crispy_forms.layout import Submit
from accounts.models import UserProfile
class UserProfileRegistrationForm(forms.ModelForm):
username = forms.CharField(max_length=255)
firstname = forms.CharField(max_length=255)
fathername = forms.CharField(max_length=255)

email = forms.EmailField(max_length=255)
phone = forms.CharField(max_length=255)
password = forms.CharField(widget=forms.PasswordInput)
confirm_password = forms.CharField(widget=forms.PasswordInput)
profile_image = forms.ImageField()
user_type = forms.ChoiceField(choices=UserProfile.USER_TYPE_CHOICES)
grade = forms.ChoiceField(choices=UserProfile.ANOTHER_USER_TYPE_CHOICES)
home_room = forms.ChoiceField(choices=UserProfile.ASSIGN_HOME_ROOM)
#user = forms.ModelChoiceField(queryset=User.objects.none(), widget=forms.HiddenInput())
class Meta:
model = UserProfile
fields = ['username', 'firstname', 'fathername', 'email', 'phone', 'password', 'confirm_password',
'profile_image', 'user_type','grade', 'home_room']
#def __init__(self, user, *args, **kwargs):

def __init__(self, *args, **kwargs):
#self.user = user
super().__init__(*args, **kwargs)
#self.fields['user_type'].initial = UserProfile.objects.get(user=user).user_type
#if not self.fields['user_type'].initial == 'Student':
#self.fields['grade'].widget = forms.HiddenInput()
self.helper = FormHelper()
self.helper.form_method = 'post'
self.helper.add_input(Submit('submit', 'Register'))
def clean(self):
cleaned_data = super().clean()
password = cleaned_data.get('password')
confirm_password = cleaned_data.get('confirm_password')
username = cleaned_data.get('username')
phone = cleaned_data.get('phone')
if password != confirm_password:
raise forms.ValidationError("Passwords do not match.")
if User.objects.filter(username=username).exists():

raise forms.ValidationError("Username is already taken.")
if UserProfile.objects.filter(phone=phone).exists():
raise forms.ValidationError("Phone Number is already taken.")
return cleaned_data
def save(self, commit=True):

user = User.objects.create_user(
username=self.cleaned_data['username'],
password=self.cleaned_data['password']
)
user_type = self.cleaned_data['user_type']
grade = self.cleaned_data['grade']
home_room = self.cleaned_data['home_room']
user_profile = UserProfile(
firstname=self.cleaned_data['firstname'],
fathername=self.cleaned_data['fathername'],
email=self.cleaned_data['email'],
phone=self.cleaned_data['phone'],
profile_image=self.cleaned_data['profile_image'],
user=user,
user_type=user_type,
grade = grade,
home_room=home_room
)
if commit:
user_profile.save()
return user_profile
class LoginForm(AuthenticationForm):
username = forms.CharField(label='Username', max_length=100)
password = forms.CharField(label='Password', widget=forms.PasswordInput)
General UserProfile Model (Database)

from django.db import models

import qrcode # additional imports
from io import BytesIO
from django.core.files import File
from PIL import Image, ImageDraw
from django.utils import timezone
class UserProfile(models.Model):
USER_TYPE_CHOICES = (
('Principal', 'Principal'),
('Teacher', 'Teacher'),
('Student', 'Student'),
)
ANOTHER_USER_TYPE_CHOICES = (
('1', '1'),
('2', '2'),
('3', '3'),
('4', '4'),
('5', '5'),
('6', '6'),
('7', '7'),
('8', '8'),
)
ASSIGN_HOME_ROOM = (
('1', '1'),
('2', '2'),
('3', '3'),
('4', '4'),
('5', '5'),
('6', '6'),
('7', '7'),
('8', '8'),
)
user = models.OneToOneField(User, on_delete=models.CASCADE)

firstname = models.CharField(max_length=255)
fathername = models.CharField(max_length=255)
email = models.EmailField(max_length=255, unique=True)
phone = models.CharField(max_length=255)
profile_image = models.ImageField(upload_to='profiles/')
timestamp = models.DateTimeField(default=timezone.now)
user_type = models.CharField(max_length=50, choices=USER_TYPE_CHOICES)
grade = models.CharField(max_length=50, choices=ANOTHER_USER_TYPE_CHOICES)
home_room = models.CharField(max_length=50, choices=ASSIGN_HOME_ROOM)
qr_code = models.ImageField(upload_to='QRCodes/', blank=True)
def __str__(self):
return self.user.username
def save(self, *args, **kwargs):

qrcode_img = qrcode.make(self.phone)
canvas= Image.new('RGB',(290, 290), 'white')
draw = ImageDraw.Draw(canvas)
canvas.paste(qrcode_img)
fname = f'phone-{self.phone}'+'.png'
buffer = BytesIO()
canvas.save(buffer, 'PNG')
self.qr_code.save(fname, File(buffer), save=False)
buffer.close()
canvas.close()
super().save(*args, **kwargs)
Attendance Model
from django.db import models
from accounts.models import UserProfile
from django.utils import timezone
# Create your models here.
class Attendance(models.Model):

qr_code = models.CharField(max_length=255)
attended_user = models.OneToOneField(UserProfile, on_delete=models.CASCADE,
related_name='attendance')
registered_by = models.ManyToManyField(UserProfile, related_name='registration')
attended_date = models.DateTimeField(default=None, blank=True)
def __str__(self):
return self.attended_user.user.username
Urls (Uniform Resource Locators)

from django.urls import path
from .views import registration_view, login_view, logout_view
app_name = 'accounts'
urlpatterns = [
path('registration/', registration_view, name='registration'),
path('login/', login_view, name='login'),
path('logout/', logout_view, name='logout'),
]
from django.urls import path

from attendance.views import(
PrincipalListView,
TeacherListView,
StudentListView,
PrincipalAttendanceListView,
TeacherAttendanceListView,
StudentAttendanceListView,
AttendanceListView,
PrincipalUpdateView,
TeacherUpdateView,
StudentUpdateView,
UserProfileDeleteView,
chart,

app_name = 'attendance'
urlpatterns = [
path('principal/', PrincipalListView.as_view(), name='principal'),
path('teacher/', TeacherListView.as_view(), name='teacher'),
path('student/', StudentListView.as_view(), name='student'),
path('principal-attendance/', PrincipalAttendanceListView.as_view(), name='principal-attendance'),

path('teacher-attendance/', TeacherAttendanceListView.as_view(), name='teacher-attendance'),
path('student-attendance/', StudentAttendanceListView.as_view(), name='student-attendance'),
path('dashboard/', AttendanceListView.as_view(), name='dashboard'),

path('principal/edit/<int:pk>/', PrincipalUpdateView.as_view(), name='principal-edit'),
path('teacher/edit/<int:pk>/', TeacherUpdateView.as_view(), name='teacher-edit'),
path('student/edit/<int:pk>/', StudentUpdateView.as_view(), name='student-edit'),
path('profile/delete/<int:pk>/', UserProfileDeleteView.as_view(), name='profile-delete'),

path('chart/', chart, name='chart'),
]

Sample Generated QR Code
User Interface

Students Profile

Edit
Delete

Principals
Dashboard Adim panel
Taking Attendance

Displaying

5. CONCLUSION AND FUTURE WORK
5.1 Conclusion
This document presented a comprehensive analysis of requirements for the proposed Student
Attendance Management System.
The current manual attendance tracking process is inefficient, error-prone, and hinders analyzing
trends. The system aims to automate attendance tracking through an intuitive platform.
Teachers can record attendance electronically which gets stored securely in a database. Key
functional requirements include attendance marking, reporting, student profiles, and integration.
Non-functional requirements like usability, security and performance were discussed. An object-
oriented approach was used for modeling. Hardware, software and infrastructure needs outlined.
The design focuses on modularity, scalability and maintainability for flexibility. This analysis
provides foundation for next stages of system design and implementation.
Further requirement refinements can be made during design phase. Overall, this document
analyzed requirements for the Student Attendance System to serve as basis for design and
implementation.
5.2 Future Work

Several potential enhancements have been identified that can be incorporated into the Student
Attendance Management System in future iterations:
Analytics and Visualizations
More advanced analytics and visualizations can be added to the reporting module to gain deeper
insights into attendance patterns. Features like integrating predictive analytics to identify
students at risk of low attendance or adding interactive charts and graphs for data visualization
can be implemented.

Notifications and Alerts
Automated notifications and alerts can be incorporated to inform parents, teachers, and
administrators about attendance issues in real-time via SMS, email, or push notifications.
Configurable rules can trigger alerts based on conditions.
Biometric Attendance
Biometric integration can enhance accuracy and security of attendance marking using
fingerprint, face recognition or iris scanning devices. This module can be integrated with the
attendance tracking component.
Mobile and Tablet Support
Dedicated mobile and tablet apps can be developed to allow students and teachers to access the
system conveniently via handheld devices. This will make attendance management possible from
anywhere.
Role-based Access Control
More advanced role-based access control can be implemented to manage permissions and access
levels, ensuring teachers, students, and admin have appropriate system access.
API Integration
API support can be provided to integrate with third-party applications like learning management
systems, student information systems, and other administrative software systems used by
schools.
By continually enhancing the Student Attendance Management System with new features, it can
become an indispensable tool for automating and streamlining critical school administration
processes. The system can be evolved to suit the changing needs of academic institutions.

References
Books References
1. Requirements Engineering: Fundamentals, Principles, and Techniques
WEBSITES
1. https://www.coursehero.com/file/145528685/MicroLink-Information-
Technology-Collegepdf/
2.https://www.academia.edu/23694177/
Software_Requirements_Specification_for_Automated_Attendance_Syste
m_Release_1_0
3. http://www.w3schools.com/asp.net/
4. http://www.cramerz.com/aspdotnet
5. http://www.dotnetspider.net/
6. http://www.stackoverflow.com

GLOSSARY
A I
Architecture: The organization structure Input: Data entered into a system

for
and associated behavior of the system [3] processing. [4]
B Interface: The external (public) view of

a
Boundary Conditions: part of design system or class. This can refer

that to an Application Programming
Interface (API) or to a user interface.
defines how the system is started,
[4]
initialized, and shut down, and deals with
how to deal with major failures, such as L
data corruption. [4]
C Log: A record of all of the user’s major
interactions.
Class diagram: UML notation
representing
R
the structure of the system in terms of

Relational Database: Data are
objects, classes, attributes, operations, and
stored in tables that comply with a
association. Class diagrams are used to
predefined type called schema. It

represent object modelsduring

provides an abstraction of data that is higher than
flat files.
development D
.
Server: A computer that serves

information
Data Dictionary: A collection of
to connected computers.
descriptions of the data objects or items in

a Subsystem: Part of the main system
that
data model for the benefit of
software developers [4]. deals with specific group of tasks
that are related, interacting with one
H another. [4]
System: Any interactions performed

Hardware: The electrical and
by the application are considered to
mechanical
be performed
devices that make up a computer system. [4] by the system.

Declaration
We, the undersigned, declare that this project is our original work and
has not been presented for degree in any other university or college,
and that all sources of materials used for the project have been
acknowledged.
Declared By:
No. Student Name Signature Date
1. Solomon Getawa _____________

_____________ 2. Mulugeta
Erigette _____________
_____________ 3.
Hailemariam Shitaw _____________
_____________ 4. Yididiya
Tizazu _____________
_____________
5. G/Egziabher Abebe _____________
_____________


Microlink Information Technology College Department of Computer Science

Uploaded by

Copyright:

Available Formats

Microlink Information Technology College Department of Computer Science

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Microlink Information Technology College Department of Computer Science

Uploaded by

Copyright:

Available Formats

MicroLink Information Technology College

Department of Computer Science

<Project Name>For Kelem Amba Primary School

Solomon Getawa 13,307/19 ED5CS1

Date Version Description Author

29/July/2023 1.0 Student Attendance Management Solomon, Mulugeta,

Final Project MicroLink IT College, 2023 Page ii

Addis Ababa, July 2023

Final Project MicroLink IT College, 2023 Page iii

Final Project MicroLink IT College, 2023 Page iv

3.3.2 System Topology............................................................................................................43

Final Project MicroLink IT College, 2023 Page v

Final Project MicroLink IT College, 2023 Page 1

School Management Hierarchy

Head of the Department

Subject Teachers Home-room Teacher

Figure 1: Chart of the school management

1.2 The Existing System

Final Project MicroLink IT College, 2023 Page 2

1.2.1 Overview of the Existing System

1.2.2 Problems of the Existing System

1.3 The Proposed System

Final Project MicroLink IT College, 2023 Page 3

1.3.1 General Objective

1.3.2 Specific Objective

1.3.3 Significance of the Project

1.3.4 Scope of the Project

Final Project MicroLink IT College, 2023 Page 4

1.4 Methodologies and Techniques

1.4.1 Data Collection Methods and Techniques

1.4.2 System Analysis and Design and Development Tools

These include Operating system such as Microsoft Windows 10 as a platform, a windows

Final Project MicroLink IT College, 2023 Page 5

The Introduction section of a Requirements Analysis Document (RAD) provides an overview of

Final Project MicroLink IT College, 2023 Page 6

The external behavior of the system includes:

Final Project MicroLink IT College, 2023 Page 7

Final Project MicroLink IT College, 2023 Page 8

 Increased accuracy and efficiency in tracking attendance.

 To simplify the process of recording and tracking student attendance.

Final Project MicroLink IT College, 2023 Page 9

 To provide real-time notifications and reminders for students and teachers.

 To reduce manual errors and inaccuracies in attendance tracking.

2.2 Current system

Final Project MicroLink IT College, 2023 Page 10

2.3 Proposed system

2.3.2 Functional requirements

Final Project MicroLink IT College, 2023 Page 11

1. Description: The system must be able to generate attendance reports, including

Final Project MicroLink IT College, 2023 Page 12

Student Information Management:

1. Description: The system store and manage student information, including

2.3.3 Nonfunctional requirements

Final Project MicroLink IT College, 2023 Page 13

2.3.3.1 User interface and human factors

Final Project MicroLink IT College, 2023 Page 14

Therefore, designing the system to be as intuitive and user-friendly as possible is an important

QR Scanners: QR scanners will be used to track attendance by scanning QR on student ID

1. Requirements Document: A document that outlines the functional and non-functional